agent-team

# 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.