From ironflow
Orchestrates multi-phase gated review after feature/fix implementation: parallel spec compliance, code quality, reuse checks; serial regression/smoke tests. Gates integration until verified.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ironflow:serial-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are the orchestrator agent responsible for driving the review process. You dispatch reviewer subagents, collect their findings, coordinate fixes with the implementer, and gate progression between phases.
You are the orchestrator agent responsible for driving the review process. You dispatch reviewer subagents, collect their findings, coordinate fixes with the implementer, and gate progression between phases.
Phase 1 — Parallel Code Review
1A Spec Compliance ──┐
1B Code Quality ──┼── dispatch simultaneously, merge results
1C Reuse (large only)──┘
→ issues found? → implementer fixes → run tests → re-review
→ all pass? → proceed
Phase 2 — Serial Verification
2A UT Full Regression → 2B Smoke Test
Dispatch all applicable reviewers simultaneously using the coding-agent skill or sessions_spawn. They examine the same code independently — their concerns don't overlap, so results don't conflict.
Dispatch the ironflow:spec-compliance-reviewer subagent.
Parameters:
spec_path (string, required): path to the spec document or bug reportchanged_files (list[string], required): file paths that were changed or createdsummary (string, required): one-paragraph description of what was implementedFor new features, spec_path points to the spec document. For bug fixes without a spec, point to the bug report or issue description.
The reviewer verifies by reading actual code, not by trusting the implementer's report. Implementers may report optimistically — finish quickly and claim everything works. The reviewer reads the code independently and compares against requirements line by line.
Dispatch the ironflow:code-quality-reviewer subagent.
Parameters:
changed_files (list[string], required): file paths that were changed or createdfile_structure (string, optional): the plan's file structure, if availableconcerns (string, optional): any areas of concern to focus onThe reviewer checks:
Only for large projects (monorepo, modular-packages, enterprise codebase). Skip for small or personal projects.
Dispatch the ironflow:reuse-reviewer subagent.
Parameters:
new_items (list[string], required): new files, functions, or classes introducedkey_directories (list[string], required): key directories and packages in the projectnew_dependencies (list[string], optional): any new dependencies addedThe reviewer checks:
Wait for all dispatched reviewers to complete. Collect all issues into a single list, deduplicate, and prioritize by severity (Critical > Important > Minor).
If all reviewers pass with no issues: proceed to Phase 2.
If any reviewer found issues: fix all issues in a single pass, then apply the Fix-then-Retest Rule.
Review-stage code changes happen outside TDD discipline and can introduce regressions. After fixing any issues found during Phase 1:
Never skip the test run between fixing and re-reviewing — this is how review-stage regressions slip through undetected.
Only after all Phase 1 reviewers pass. This phase runs sequentially — each gate depends on the previous one.
Run the complete test suite — not just tests related to changed files, but the entire suite.
Why: TDD during implementation ensures tests exist and pass for new code. But Phase 1 review fixes happen outside TDD discipline — a reviewer might flag an issue, the implementer fixes it without writing a new test, and that fix silently breaks something elsewhere. A full regression run catches this.
Only after Stage 2A passes. This is not about unit tests passing — it's about real-world verification.
Why: pytest passing doesn't mean the feature works end-to-end. A real user would hit the endpoint, open the page, or run the actual command. You need to do that too.
Subagents report one of four statuses:
Ignoring an escalation or retrying without changes leads to the same failure — address the underlying issue first.
Before claiming any task is complete:
Phrases like "should work", "probably fine", or "seems good" indicate unverified assumptions. State claims with evidence from actual command output.
When all stages pass and work is ready for delivery, compile a workaround summary listing any non-ideal solutions used during implementation. Include workarounds from the plan and any discovered during the build. For each one, state what it is, why it was needed, and what the ideal fix would be. Present this to the user as part of the final delivery.
If there are no workarounds, skip this section.
After all review stages pass and the workaround summary is presented, invoke the ironflow:finishing-branch skill to create the integration branch and prepare for merge.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub zhijiang-li1111/ironflow --plugin ironflow