Agent Team

TASK = the user's request

If TASK is not provided, ask the user for the task description and stop.

Coordinate an Agent Team composed of an Implementer Agent and a Reviewer
Agent. Iterate the implementation/review loop until the exit condition is
satisfied.

0. Exit Condition

The loop exits when both of the following hold in a single review round:

• 0 findings of severity high or critical.
• 3 or fewer findings of severity mid.

Findings of severity low do not affect the exit condition.

Set a hard safety cap of 10 iterations. If the exit condition is still not
met at the cap, stop the loop and report the remaining findings to the user for
manual decision.

1. Iteration Loop

Repeat the following steps until the exit condition is satisfied.

1-1. Implementation Phase

Delegate to the Implementer Agent via the Agent tool.

• subagent_type: general-purpose
• Role framing: "You are the Implementer Agent on an Agent Team."
• Inputs to pass:
  • The original TASK.
  • All Reviewer findings from the previous round (if any), grouped by
    severity.
• Instructions to include in the prompt:
  • Implement the TASK end-to-end in the current repository.
  • Address every Reviewer finding from the previous round. For each finding,
    either fix it or, if you intentionally reject it, record the reason.
  • Edit files directly; do not only describe changes.
  • Run pnpm cicheck (or the narrower pnpm cicheck:code / cicheck:content
    when appropriate) and fix any failures before returning.
  • Report: a concise summary of the changes, the list of modified files, how
    each previous finding was handled, and the result of the checks.

1-2. Review Phase

Delegate to the Reviewer Agent via the Agent tool.

• subagent_type: code-reviewer
• Role framing: "You are the Reviewer Agent on an Agent Team."
• Inputs to pass:
  • The original TASK.
  • The Implementer's summary and the list of modified files from this round.
• Instructions to include in the prompt:
  • Review the changes for correctness, design quality, tests, and adherence
    to project conventions (see CLAUDE.md, docs/**/*.md, and
    .claude/rules/feature-change-guidelines.md).
  • Also consider security concerns.
  • Produce a findings list. For each finding, include:
    • Sequential number (e.g., #1, #2).
    • Severity: low / mid / high / critical.
    • File path and line number(s).
    • Problem description and recommended fix.
  • At the end of the report, include a Severity Summary with the counts
    per severity level so the exit condition can be evaluated mechanically.

1-3. Evaluate the Exit Condition

Parse the Reviewer's Severity Summary.

• If high + critical == 0 and mid <= 3: exit the loop.
• Otherwise: feed the findings into the next Implementation Phase and
  continue.

Between iterations, emit a short status line to the user such as
Iteration N complete — high/critical: X, mid: Y, low: Z.

2. Final Report

After the loop exits, report the following to the user:

• Outcome: Converged (exit condition met) or Capped (hit iteration cap).
• Iterations: how many rounds were executed.
• Remaining findings: the final Severity Summary, plus the full list of
  remaining mid and low findings (and any high/critical findings that
  remain when the loop was capped).
• Changes: a brief summary of what was implemented and which files were
  modified.
• Next steps: suggestions for the user (e.g., create a commit / PR via
  the commit-push-pr skill).

Do not auto-commit or open a PR from this skill; leave that to the user.