Use when an adversarial code review is needed after implementation. Reviews with fresh context and no shared conversation history to prevent self-evaluation bias. Produces a hard-gating verdict — REQUEST CHANGES blocks shipping. Example triggers — "review my changes", "code review the implementation", "check this PR…
Use after research is complete to draft the approach before any code is written. Drafts a 200-line design document covering current state, desired end state, patterns to follow, and decisions made. Resolves its own open questions autonomously, recording each as an explicit, auditable assumption in the design.
Use when you need to locate files in a codebase relevant to a specific area. Maps conceptual goals to actual file locations even when exact names are unknown. Operates from questions.md only, never the original task description.
Use when the implementation plan needs to be executed slice by slice. A seasoned coding expert that reads the plan, follows TDD discipline, executes one vertical slice at a time, and commits each slice atomically when its tests pass. Dispatched during the Implement phase.
Use after the structure is produced to create the tactical implementation plan. Translates each vertical slice in structure.md into precise file-level steps with acceptance test mappings. The plan is a tactical artifact for the implementer — neither the structure nor the plan is human-reviewed (the design passed…
Use as the first agent of the QRSPI pipeline. Decomposes a user's task description into a full task record (task.md) and neutral research questions (questions.md), plus conditional artifacts — a prd.md when the PRD criteria apply, and a repos.md listing the repos the topic touches when the description names more than…
Use when codebase facts need to be gathered before any design or implementation work. Reads code, traces dependencies, documents patterns. Receives only the path to questions.md, never the original task description.
Use when a security review is needed after implementation. Applies OWASP-style checks with fresh context. Critical findings are a hard gate — they block shipping until resolved. Example triggers — "security review", "check for vulnerabilities", "audit this code for security issues".
Use after the design review passes to break the work into vertical slices with verification checkpoints. Each slice is end-to-end (touches every layer needed to deliver one piece of functionality), independently testable, and atomically committable. Produces a 2-page document that the planner and implementer consume…
Use after implementation to review whether project documentation needs updating. Reads the diff and compares against existing docs to identify gaps and stale content. Produces a structured report — does not rewrite docs itself. Example triggers — "check if docs need updating", "documentation review", "are the docs…
Use after the worktree is prepared to write all failing acceptance tests from the structure. Tests form the immutable scope fence for implementation. Operates inside the implement phase as a sub-step before the implementer runs.
Use when live application verification is needed after implementation. Boots the application, interacts with it as a user would, and evaluates the experience. For API-only projects, sends real HTTP requests. Example triggers — "verify the app works", "test the UI", "check the user experience", "smoke test the…
Use when comprehensive verification checks need to run before completion. Runs all available checks (format, lint, type check, build, tests) in speed order and produces an evidence-based report. Example triggers — "run all checks", "verify the build", "pre-flight checks", "does everything pass".