Use when executing implementation plans with independent tasks — dispatches fresh subagents per task with two-stage review (spec compliance, then code quality)
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Execute a plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance first, then code quality.
Core principle: Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
Why subagents: Isolated context per task — subagents never inherit your session history. You construct exactly what they need. This keeps the coordinator context clean for orchestration work.
Use this after /squad-plan generates a parallel workstream plan, OR when you have any plan document with independent tasks.
vs. dispatching subagents manually: This enforces the two-stage review loop automatically — no skipping spec compliance to jump to quality.
Not suitable when tasks are tightly coupled — if task B depends on task A's exact output, execute sequentially in the main context instead.
Setup:
claude/tasks/todo.md with all task titlesPer task loop:
reviewer subagent type) → does code match the spec?
reviewer subagent type) → is code clean, tested, production-ready?
claude/tasks/todo.mdAfter all tasks:
/mr to finalize the branch| Status | Action |
|---|---|
DONE | Proceed to spec compliance review |
DONE_WITH_CONCERNS | Read concerns first — address correctness/scope concerns before review, note observations and proceed |
NEEDS_CONTEXT | Provide missing context, re-dispatch |
BLOCKED | Diagnose: context problem → provide context + re-dispatch; needs more reasoning → re-dispatch with opus model; task too large → break into smaller pieces; plan is wrong → escalate to user |
Never ignore an escalation or force the same model to retry without changes.
| Task | Model |
|---|---|
| Isolated function, clear spec, 1-2 files | haiku |
| Multi-file, integration concerns | sonnet |
| Architecture, design, review | opus |
You are implementing Task N of M in a subagent-driven development session.
**Task:** [full task text from plan]
**Context:**
- Branch: [current branch]
- Plan: [plan file path]
- Relevant files: [list key files — provide content, don't make them read]
- Constraints: [any architectural constraints]
**Requirements:**
1. Follow TDD — write failing test first, then implement
2. Run tests and verify they pass
3. Commit with a clear message
4. Self-review: check for missed requirements, edge cases, quality issues
**Report status as one of:**
- DONE: completed and committed
- DONE_WITH_CONCERNS: done but flagging [specific concern]
- NEEDS_CONTEXT: blocked on [specific missing info]
- BLOCKED: cannot proceed because [specific reason]
You are a spec compliance reviewer. Your ONLY job: does the implementation match the spec?
**Spec for this task:** [full task text]
**Implementation:** [git diff or file content]
Check:
1. Does the code implement EVERYTHING the spec requires?
2. Does the code implement NOTHING the spec did not ask for?
Report:
- ✅ COMPLIANT: all spec requirements met, no extras
- ❌ ISSUES: [list each gap or extra feature]
You are a code quality reviewer. The spec compliance gate has already passed.
**Implementation:** [git diff or file content]
Check:
1. Tests cover all branches and edge cases?
2. No magic numbers, unclear names, dead code?
3. Error handling appropriate to criticality?
4. File/function size within project limits (400 lines/file, 50 lines/function)?
Report:
- ✅ APPROVED
- ❌ ISSUES (Critical | Important | Minor): [list each issue]
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Route a codebase question to the right tool — structural graph, semantic search, or risk analysis. Use when you need to find or understand code without knowing exact file names.
The English summary is being prepared. Showing the original description.
Auto-configure CLAUDE.md and claude/ knowledge docs for a new project. Use when setting up Brain Bootstrap in a new repository. Discovers the codebase, fills in templates, and writes project-specific configuration.
The English summary is being prepared. Showing the original description.
Use before any new feature, component, or behavioral change — when you need to explore requirements and design before writing code
The English summary is being prepared. Showing the original description.
Activate safety guards for the session. Use /careful before critical operations — blocks rm -rf, DROP TABLE, git push --force, kubectl delete namespace, docker system prune via PreToolUse hook.
The English summary is being prepared. Showing the original description.
Generate a user-facing changelog from git commits — categorize, filter noise, translate to user language. Runs in isolated fork context.
The English summary is being prepared. Showing the original description.
Save session state before context gets full or before ending. Writes current task state, branch, and loaded docs to claude/tasks/todo.md so the next session can resume cleanly.
The English summary is being prepared. Showing the original description.