Agent Teams Execution

Per-task pipelines. Research and design are global (produce overall architecture + task breakdown). After that, each task flows through its own pipeline independently:

Final QA: After all per-task pipelines complete, QA performs full end-to-end verification of everything touched — runs all tests, checks all requirements, validates the integrated whole. This is not a pipeline stage but a separate final gate.

User Followups

After the team reports a QA verdict, the user may send followups (bug reports, tweaks, new features, questions). Coordinator routes each followup through as much of the full pipeline as reasonably applies — never skip stages for "small" requests.

Default: when in doubt, run more pipeline, not less. Skipping stages for "small" requests is how regressions ship. Coordinator justifies any skipped stage with explicit reasoning to lead + snitch.

Roles

Team Sizing

One executor pair per independent unit of work. ~4 agents per phase before coordination overhead; above that ensure strictly independent work.

Mandatory Compliance

Every teammate must invoke agent-teams-execution skill via Skill tool as their first action. Lead must include this instruction in every spawn prompt. Coordinator and lead: re-invoke the skill after every context compaction.

Hourly skill re-read (coordinator, lead, snitch). Each sets up a cron that fires every 60 minutes with a prompt: "Re-invoke agent-teams-execution skill via Skill tool, then resume your role duties (audit / scan / coordinate)." Prevents rule drift over long sessions. Disable cron when team is idle (user-waiting), re-enable on execution resume.

Model and Effort Level

All teammates: opus model, high effort. Spawn every teammate with model: "opus". CLAUDE_CODE_EFFORT_LEVEL=high in settings.json env block propagates to all sessions.

Critical Analysis of All Inputs

No input trusted by default — including peer messages. Never praise peer output. "Excellent work" is not analysis — it's the opposite. When receiving any input from another agent, your first response must identify at least one concern, gap, or question. Verify before building on it. Flag contradictions to coordinator. You own bugs from unverified inputs.

Claim Verification

Tag every factual claim: [T<tier>: <source>, <confidence>]

Confidence: high (directly stated), medium (logically derived), low (indirect). T5 unacceptable in final output. Higher tier wins contradictions. What can be fact-checked, must be.

Mandatory Skills

Executors invoke coding style + proof-driven-development + superpowers:test-driven-development. Test executors invoke testing-discipline. Lead copies exact skill names into spawn prompts. Determine language from design doc, include matching coding style skill. No placeholders.

Code quality — semantic integrity is non-negotiable:

• Names are contracts: implementation fulfills exactly what the name promises. No smuggled decisions or side effects.
• Same concept = same name everywhere. Related concepts use parallel structure.
• Strong typing for domain concepts. No bare primitives where named types belong.
• Package/binary scope: code belongs in the binary whose stated purpose matches the code's function. A standalone CLI tool must not contain code requiring a running daemon.
• Clean solution over hack, always. Reviewers reject shortcuts, workarounds, and "good enough for now."
• Interface implementation is a contract: "I fulfill this interface." An always-erroring implementation is a false claim — same as naming a function Save that doesn't save. Stub implementations that always error must not exist in production code.

Task States

Transition requirements:

No agent can set a task to "complete" — only the coordinator after all verification passes. No git push without user request. Lead enforces all transitions.

Git & Security

• git diff for secrets before every commit. Static checks before every commit. Never push without user approval. No AI co-author lines.
• Security first. Never disable security features. OWASP top 10 for all code. Validate at system boundaries.

Flow (per-task after design)

digraph phases {
    rankdir=TB;

    "PHASE 1: RESEARCH" [shape=doublecircle];
    "Spawn explorers" [shape=box];
    "Explore and cross-check findings" [shape=box];
    "All findings tagged with source tier?" [shape=diamond];
    "T5 claims remaining?" [shape=diamond];
    "Promote or discard T5 claims" [shape=box];
    "Produce findings document" [shape=doublecircle];

    "PHASE 2: DESIGN" [shape=doublecircle];
    "Spawn designer + design reviewer(s)" [shape=box];
    "Design architecture + file ownership map" [shape=box];
    "Design reviewer approves?" [shape=diamond];
    "Revise design based on feedback" [shape=box];
    "Designer needs more info?" [shape=diamond];
    "Re-spawn explorers for targeted research" [shape=box];
    "Finalize approved design + file ownership" [shape=doublecircle];
    "STOP: 10 rejections - escalate to user" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];

    "PHASE 3: EXECUTION" [shape=doublecircle];
    "Spawn executor/reviewer pairs + test designer" [shape=box];
    "Implement module (owns assigned files only)" [shape=box];
    "Execution reviewer approves?" [shape=diamond];
    "Revise code based on feedback" [shape=box];
    "Executor blocked by design issue?" [shape=diamond];
    "Report to lead - re-enter Phase 1" [shape=box];
    "Write test specs (wait for interface contracts)" [shape=box];
    "Finalize test specs" [shape=doublecircle];
    "Task code approved" [shape=doublecircle];
    "STOP: 10 exec rejections - escalate" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];

    "PHASE 4: TESTING + INTEGRATION" [shape=doublecircle];
    "Spawn test executor/reviewer pairs" [shape=box];
    "Implement unit + integration tests from specs" [shape=box];
    "Test reviewer approves?" [shape=diamond];
    "Revise tests based on feedback" [shape=box];
    "Confirm all tests pass" [shape=doublecircle];
    "STOP: 10 test rejections - escalate" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];

    "FINAL QA" [shape=doublecircle];
    "Spawn QA" [shape=box];
    "Verify against full checklist" [shape=box];
    "QA approves?" [shape=diamond];
    "Route: bug->Ph3, design flaw->Ph1, missing test->Ph4, bad finding->Ph1" [shape=box];
    "Report verdict + evidence to user. Wait." [shape=box];
    "User confirms?" [shape=diamond];
    "User followup?" [shape=diamond];
    "Route per User Followups table" [shape=box];
    "Wait for user shutdown request" [shape=doublecircle];
    "STOP: 2 QA re-entries exhausted - escalate to user" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];

    "PHASE 1: RESEARCH" -> "Spawn explorers";
    "Spawn explorers" -> "Explore and cross-check findings";
    "Explore and cross-check findings" -> "All findings tagged with source tier?";
    "All findings tagged with source tier?" -> "Explore and cross-check findings" [label="no"];
    "All findings tagged with source tier?" -> "T5 claims remaining?" [label="yes"];
    "T5 claims remaining?" -> "Promote or discard T5 claims" [label="yes"];
    "Promote or discard T5 claims" -> "T5 claims remaining?";
    "T5 claims remaining?" -> "Produce findings document" [label="no"];

    "Produce findings document" -> "PHASE 2: DESIGN";
    "PHASE 2: DESIGN" -> "Spawn designer + design reviewer(s) + fundamentals reviewer";
    "Spawn designer + design reviewer(s) + fundamentals reviewer" -> "Design architecture + file ownership map";
    "Design architecture + file ownership map" -> "Design reviewer approves?";
    "Design architecture + file ownership map" -> "Fundamentals reviewer approves?";
    "Fundamentals reviewer approves?" [shape=diamond];
    "Fundamentals reviewer approves?" -> "Revise design based on feedback" [label="no (round 1-10)"];
    "Fundamentals reviewer approves?" -> "STOP: 10 rejections - escalate to user" [label="no (round 11+)"];
    "Fundamentals reviewer approves?" -> "Both reviewers approved?" [label="yes - with evidence"];
    "Both reviewers approved?" [shape=diamond];
    "Design reviewer approves?" -> "Revise design based on feedback" [label="no (round 1-10)"];
    "Design reviewer approves?" -> "STOP: 10 rejections - escalate to user" [label="no (round 11+)"];
    "Design reviewer approves?" -> "Both reviewers approved?" [label="yes - with evidence"];
    "Both reviewers approved?" -> "Finalize approved design + file ownership" [label="yes"];
    "Both reviewers approved?" -> "Design architecture + file ownership map" [label="no - wait for other"];
    "Revise design based on feedback" -> "Designer needs more info?";
    "Designer needs more info?" -> "Re-spawn explorers for targeted research" [label="yes"];
    "Re-spawn explorers for targeted research" -> "Design architecture + file ownership map";
    "Designer needs more info?" -> "Design architecture + file ownership map" [label="no"];
    "Design reviewer approves?" -> "Finalize approved design + file ownership" [label="yes - with evidence"];

    "Finalize approved design + file ownership" -> "PHASE 3: EXECUTION";
    "PHASE 3: EXECUTION" -> "Spawn executor/reviewer pairs + test designer";
    "Spawn executor/reviewer pairs + test designer" -> "Implement module (owns assigned files only)";
    "Spawn executor/reviewer pairs + test designer" -> "Write test specs (wait for interface contracts)";
    "Implement module (owns assigned files only)" -> "Execution reviewer approves?";
    "Execution reviewer approves?" -> "Revise code based on feedback" [label="no (round 1-10)"];
    "Execution reviewer approves?" -> "STOP: 10 exec rejections - escalate" [label="no (round 11+)"];
    "Revise code based on feedback" -> "Executor blocked by design issue?";
    "Executor blocked by design issue?" -> "Report to lead - re-enter Phase 1" [label="yes"];
    "Report to lead - re-enter Phase 1" -> "Spawn explorers";
    "Executor blocked by design issue?" -> "Execution reviewer approves?" [label="no - retry"];
    "Execution reviewer approves?" -> "Task code approved" [label="yes - with evidence"];
    "Write test specs (wait for interface contracts)" -> "Finalize test specs";

    "Task code approved" -> "PHASE 4: TESTING + INTEGRATION" [label="immediately, per task"];
    "Finalize test specs" -> "PHASE 4: TESTING + INTEGRATION";
    "PHASE 4: TESTING + INTEGRATION" -> "Spawn test executor/reviewer pairs";
    "Spawn test executor/reviewer pairs" -> "Implement unit + integration tests from specs";
    "Implement unit + integration tests from specs" -> "Test reviewer approves?";
    "Test reviewer approves?" -> "Revise tests based on feedback" [label="no (round 1-10)"];
    "Test reviewer approves?" -> "STOP: 10 test rejections - escalate" [label="no (round 11+)"];
    "Revise tests based on feedback" -> "Test reviewer approves?";
    "Test reviewer approves?" -> "Confirm all tests pass" [label="yes - with evidence"];

    "Confirm all tests pass" -> "FINAL QA" [label="after all per-task pipelines complete"];
    "FINAL QA" -> "Spawn QA";
    "Spawn QA" -> "Verify against full checklist";
    "Verify against full checklist" -> "QA approves?";
    "QA approves?" -> "Route: bug->Ph3, design flaw->Ph1, missing test->Ph4, bad finding->Ph1" [label="no (re-entry 1-2)"];
    "QA approves?" -> "STOP: 2 QA re-entries exhausted - escalate to user" [label="no (re-entry 3+)"];
    "Route: bug->Ph3, design flaw->Ph1, missing test->Ph4, bad finding->Ph1" -> "Verify against full checklist";
    "QA approves?" -> "Report verdict + evidence to user. Wait." [label="yes - all evidence cited"];
    "Report verdict + evidence to user. Wait." -> "User followup?";
    "User followup?" -> "Route per User Followups table" [label="yes"];
    "Route per User Followups table" -> "PHASE 1: RESEARCH" [label="new feature"];
    "Route per User Followups table" -> "PHASE 2: DESIGN" [label="behavior change"];
    "Route per User Followups table" -> "PHASE 3: EXECUTION" [label="bug fix / tweak"];
    "User followup?" -> "User confirms?" [label="no"];
    "User confirms?" -> "Wait for user shutdown request" [label="yes"];
    "User confirms?" -> "Report verdict + evidence to user. Wait." [label="no - keep waiting"];
}

Checkpoints & Re-Entry

After each task milestone (code approved, tests approved), coordinator records: what was produced, who approved (with evidence), git SHA.

Re-entry impact assessment: Diff old vs new design. Invalidate only pairs touching changed interfaces (reset loop counters). Notify test designer. Unaffected tasks continue their pipelines.

Design Output Requirements

Phase 2 design must include:

1. Architecture -- components, data flow, error/failure flow, interfaces
2. File ownership map -- no overlaps. Spawn prompts include: "You own ONLY these files: [list]."
3. Binary/service purpose map -- for each binary or deployable, one-sentence statement of purpose, scope, and dependencies. File ownership map must be consistent with this.
4. Interface contracts -- public APIs/signatures per task, including: error/failure modes, preconditions/postconditions, data invariants, thread safety. Test designer uses these before executors finish.
5. Module dependency graph -- coordinator uses for executor sequencing.
6. Requirement traceability -- component → user requirement mapping. Every requirement covered, every component justified.
7. Security design (when applicable) -- trust boundaries, attack surfaces, security controls, auth strategy. OWASP at design time, not just code review.
8. Shared concerns register -- logic/types/patterns needed by 2+ tasks. Each entry: {what, which tasks, designated shared location}. Executors consume this to avoid reimplementation.

Git worktrees: 2+ parallel executors -> each gets own worktree. Create before spawning, merge after approval.

Testing Protocol

Unit tests: Written by executors alongside their code. Part of execution, not a separate phase.

Integration/E2E tests (Phase 4):

• Test designer writes specs covering all applicable test types: integration tests (cross-task boundaries), full E2E tests (entire user-facing flows), and UI tests (screen manipulation, interaction sequences) when the project has a UI.
• Every cross-task interface must have at least one test on the real call path (no mocks at boundaries).
• E2E tests exercise complete workflows as a user would, including UI manipulation when applicable.
• Failure routing: cross-task boundary bug → executor pair. Design flaw → research/design.

Feedback Loops

Paired roles communicate directly. All other feedback routes through coordinator. All "submitted", "blocked", and "completed" claims must CC both the lead and the snitch — independent verification that the coordinator doesn't accept claims at face value. All coordinator → lead requests (spawn, re-spawn, phase transition) must also CC the snitch — so the snitch can independently verify spawn prompts, checklists, and rule compliance.

Loop Limits

Round = one rejection (initial submission is not a round).

• 10 rounds max per pair. 11th rejection -> escalate (replace teammate or re-scope). Counters reset on QA/Phase 2 re-entry.
• 2 QA re-entries max (total). 3rd -> escalate to user with: what failed, what was tried.
• 2 designer-to-explorer rounds max. Then escalate to user.

Crash Recovery

Not responding to messages ≠ dead. Coordinator must investigate before declaring unresponsive:

1. Check: does the teammate have an active running process? (compilation, test suite, build, context compaction) → working, not hung.
2. Check: are files or git state changing in their worktree? → working, not hung.
3. If no active process and no file/git activity: interrupt first — send a message asking for status, then tmux send-keys -t <pane> Escape to break their turn. Wait for response.
4. Only if no response after interrupt → confirmed unresponsive. Skipping any step = false positive. Coordinator must document evidence of all checks before requesting re-spawn.

Once confirmed unresponsive, immediately re-spawn — no delays. The task must not stall. Executors: Paired reviewer reviews all changes before re-spawn. Unreviewed output never discarded. Non-executors: Re-spawn immediately. Max 2 re-spawns per role, then escalate to user.

Misbehavior Recovery (any agent)

Every violation: Whoever detects it (lead, coordinator, or snitch) SendMessages the violating agent with the specific rule + correction, CC'ing the other two oversight roles (lead, coordinator, snitch) so all three stay aware. Then tmux send-keys -t <pane> Escape to interrupt immediately. No violation goes uninterrupted.

Repeated violations (3+ on same rule): Counts only corrections the agent received (message visible in its transcript) and still violated the same rule afterward. Acknowledgement not required — receipt is. Coordinator verifies receipt before counting a cycle: inspect the agent's transcript to confirm the correction message landed. Trigger: 3+ confirmed receive-then-violate cycles. Only then: force context compaction: tmux send-keys -t <pane> '/compact' Enter, then SendMessage to re-read the skill and continue. If still misbehaving after compaction, escalate to user.

Force-deliver corrections. Agent busy or mid-turn won't see SendMessage until its turn ends. Coordinator MUST interrupt to deliver: tmux send-keys -t <pane> Escape, then re-send the correction.

Blocker Resolution Protocol

When any teammate reports a blocker, coordinator simultaneously launches:

1. Brainstormer — prompt as a genius creative unblocker who thinks outside the box. Generates as many solution ideas as possible. Positives only, no filtering, no feasibility judgment. Bigger list = better.
2. Explorer — independently investigates the blocker to understand the technical landscape.

After brainstormer finishes, coordinator launches a second explorer to validate technical feasibility of the brainstormer's ideas against the explorer's findings. Coordinator picks the best feasible approach and assigns it.

Reviewer Protocol

ALL reviewers (design, execution, test):

Reviewers report, never fix. No editing code, designs, or tests. Describe the problem and suggest a fix direction. The paired executor implements all changes.

0. Does it work? Before evaluating quality, verify code fulfills its stated purpose. If it doesn't — REJECT.
1. Assume wrong. Find errors. Look for what's missing.
2. Classify: Critical (security, correctness, spec violation), Major (design deviation, missing edge case) — both block. Minor (doesn't block), Nit (never blocks).
3. Outcomes: APPROVED (no Critical/Major, with evidence), CONDITIONAL (Minor/Nit listed), REJECTED (Critical/Major cited with fix direction). Every Critical/Major must cite file:line. Fix direction must name the exact symbol changed. Vague findings ("refactor this function", "clean this up") are inadmissible. Rejections must enumerate reasons before any approval statement — no mixed verdicts.
4. Check against: design doc, coding style skill (semantic integrity, naming, typing, no shortcuts — every rule), OWASP top 10, edge cases, error handling, requirements, claim tags, critique log. No coding style invocation = reject. Untagged factual claims = reject. T5 claims not promoted = reject. No critique log = reject.
5. Max 10 rounds then escalate.

Design creates a type/component but defers making it work = reject. Valid deferral: don't create it yet. Invalid deferral: create a broken version.

Design Reviewer — Additional Rejection Criteria

REJECT if any are missing or incomplete:

• Requirement traceability (item 6) — every requirement mapped, every component justified
• Security design (item 7, when applicable) — trust boundaries, attack surfaces, controls
• Shared concerns register (item 8) — all cross-task logic/types identified with designated locations
• Enriched interface contracts (item 4) — error modes, pre/postconditions, invariants, thread safety
• File ownership map contradicts binary/service purpose map (items 2 vs 3)

Execution Reviewer Checklist

Extends the general Reviewer Protocol above (which already covers OWASP, edge cases, error handling, claim tags, critique log). Execution reviewers additionally check:

• Load the <language>-coding-style skill via Skill tool. Check every rule.
• Requirements coverage — each user requirement → code
• Design compliance — implementation matches architecture + interface contracts (error modes, pre/postconditions, invariants, thread safety)
• Code location — files in correct binary per purpose map
• Shared concerns register — no reimplementation (REJECT); missed abstraction (CONDITIONAL)

Executor Disputes

Dispute a finding with evidence: cite code, spec, or test. Reviewer withdraws or escalates with stronger evidence. One exchange, then coordinator decides.

Multi-Reviewer (2+)

Review independently first — no reading peer findings before writing your own. Minority dissent requires counter-evidence to override. T1 outweighs T3.

Lens partition. Coordinator assigns non-overlapping lenses, allocated in priority order: (1) correctness/edge cases, (2) security/OWASP, (3) design/semantic integrity/naming. With 2 reviewers: lenses 1+2. With 3 reviewers: lenses 1+2+3. With 4+: split correctness into happy-path vs edge-case, or split design into naming vs architecture. Each reviewer produces findings under its lens before lenses converge. Issues outside a lens are still reported, but lens coverage is primary. Identical spawn prompts for sibling reviewers = reject.

QA Protocol

Four-step protocol applied to every acceptance criterion:

1. State — explicitly state what must be true (the criterion)
2. Identify — identify what evidence would prove it, distinguishing direct from proxy:
   • Direct evidence: shows the thing itself working (running the actual program end-to-end, observing the output, reproducing the user-facing flow)
   • Proxy evidence: indirect signal (unit tests pass, linter clean, type check passes)
3. Obtain — actually obtain the evidence. Run the commands. Execute the program. Reproduce the flow. Always prefer direct evidence. Proxy evidence alone never satisfies a criterion that can be verified directly.
4. Judge — judge whether the evidence proves the criterion. Cite the exact output/observation. "Looks right" is not judgment — quote the evidence.

Acceptance criteria checklist:

• Implementation matches design
• All original requirements met
• All claims tagged, no T5 remaining
• OWASP top 10 security review
• Edge cases handled
• Integration tests pass (run them — direct)
• All unit tests pass (run them — proxy, still required)
• End-to-end flows verified (direct — run the program as a user)
• No uncommitted changes, no secrets in diffs
• Static checks pass
• Mandatory skills invoked by all teammates
• Critique logs exist for all teammates
• File ownership respected
• Code quality: clean code, semantic integrity, no shortcuts, no workarounds, coding style fully followed

Coordinator Responsibilities

NEVER do work. NEVER use the Agent tool (subagents). No code, no research, no exploration, no investigation, no analysis. Your context is the coordination state — any work pollutes it. Delegate ALL work to teammates via tasks and messages. Agents make mistakes — never trust claims at face value. Reviewers validate completion; launch explorers to verify blockers and external blame.

PAIR INVARIANT (hard rule): Every executor MUST have its paired reviewer spawned and confirmed BEFORE the executor receives any task. Never assign new work to the same executor whose previous submission is unreviewed — assign it to a different executor/reviewer pair instead. Sequence per pair: spawn reviewer -> confirm alive -> spawn executor -> executor implements -> reviewer reviews -> loop until approved -> only then may this executor receive next task. While a pair is in review, other pairs work in parallel. Violating this invariant is a skill violation equivalent to writing code.

1. Track EVERYTHING as tasks. Every deliverable, sub-task, blocker = task. Task list is single source of truth.
2. Request spawns from lead. Coordinator determines who is needed and when; lead creates the agent team and spawns teammates.
3. Tasks with dependencies first, then request lead to spawn teammates to claim them. Every task description must include: "Tag all factual claims: [T<tier>: source, confidence]."
4. Assign file ownership per design doc. Create git worktrees for 2+ parallel executors.
5. Route feedback between unpaired roles. When receiving findings from any agent: do NOT acknowledge with praise. Identify what's missing, what could be wrong, what needs verification. Route findings to a second agent for independent verification before acting on them.
6. Monitor progress. Stale task = investigate per Crash Recovery: check for active process and file/git activity in their worktree. If confirmed unresponsive, follow the respawn sequence.
7. Handle "submitted" tasks. When a task is submitted: verify Stop Checklist items (changes committed, claims tagged, critique log exists). Bounce back immediately if incomplete — don't waste reviewer time. If checklist passes, route to paired reviewer. After reviewer approves, route to test pipeline (code tasks) or verifier (non-code tasks).
8. Drive per-task pipelines. When a task's code is approved + its test specs are ready → immediately spawn test executor/reviewer pair for that task. Do not wait for other tasks. After ALL tasks tested → spawn QA. Record checkpoint per task: what was produced, who approved, git SHA.
9. Budget context -- summaries, not raw output (see below).
10. Enforce loop limits. Escalate on 11th rejection / 3rd QA re-entry.
11. Crash recovery -- detect unresponsive teammates, request lead to re-spawn. For executors: review changes before re-spawning. Max 2 re-spawns.
12. Manage lifetimes per Teammate Lifecycle (below).
13. Enforce pair invariant. Before every executor task assignment, verify reviewer exists and previous work is reviewed.
14. Address all reported issues. Every executor-reported issue becomes a task. Assign an executor to critically analyze it (code cleanness, semantic integrity, correctness). If dismissed: document rationale. If validated and minor: the analyzing executor fixes it directly. If validated and design-level: full pipeline. No report may be silently ignored.
15. Audit subordinates every 10 minutes. Check each active teammate's recent output for rule violations: untagged claims, missing skill invocations, unreviewed code, shortcuts. Create a task for each violation found.
16. Interrupt violations immediately. Same protocol as lead: send correction message first, then tmux send-keys -t <pane> Escape to interrupt. Don't wait for their turn to end.
17. Notify snitch on idle/resume. SendMessage snitch when team goes idle (all tasks waiting on user) and when execution resumes, so snitch can disable/enable its cron job.
18. Report QA verdict to user, then wait. Never declare mission accomplished. Never auto-shutdown teammates. Mission complete only when user explicitly confirms. Followups → route per User Followups table.
19. Shutdown only on user request. Then run Shutdown procedure for every teammate, mark all tasks completed.

Lead Responsibilities

NEVER implement. The lead enforces all skill rules. Reactive, not proactive — the lead reacts to events rather than actively observing. On every event, the lead verifies that all applicable rules were followed. On violation, the lead reminds the agent of the specific rule and the required correction — never blocks, always corrects.

Stop-hook bypass (first action, unconditional): As the very first action on entering this skill — before spawning any teammate — run ~/.claude/bin/skip-stop on. The main thread never implements code, so the verification gate is pure overhead here. On any skill exit (team completion, user abort, escalation halt, fatal error), run ~/.claude/bin/skip-stop off to clear the marker. Leaving it stale would silently bypass verification in the next normal dev session.

Interrupting violations: A message alone is insufficient — agents won't see it until their turn ends. To interrupt:

1. SendMessage with the correction (specific rule + required fix)
2. Then tmux send-keys -t <pane> Escape to interrupt their turn

Events and enforcement:

On every event: check for rule violations (untagged claims, missing skills, skipped reviews, shortcuts). Interrupt + remind the violating agent.

Spawn Checklist (lead verifies before every spawn)

• Spawn prompt includes instruction: "Invoke agent-teams-execution skill via Skill tool as your first action"
• Stop condition stated as observable criterion; false-stops enumerated
• Model set to opus
• Correct coding style skill listed by exact name (not placeholder)
• Claim tagging instructions included verbatim
• File ownership explicit (executor/test roles)
• Paired reviewer confirmed alive (executor spawns only)
• Reviewer/verifier spawns include: executor's original objective with full context, and all scrutiny rules (coding style, claim tagging, OWASP, semantic integrity, etc.)
• Execution reviewer spawns include: explicit "Load the <language>-coding-style skill via Skill tool" instruction + shared concerns register
• Preemptive warnings included: coordinator anticipates the most likely mistakes this agent could make given the specific task and explicitly warns against them in the spawn prompt
• CLAUDE_ROLE env set to role name for every spawn (coordinator, explorer, designer, reviewer, executor, test-designer, test-executor, test-reviewer, verifier, qa, brainstormer, snitch)

Lead rejects spawn if any item unchecked.

Context Budgeting

Downstream agents get structured summaries, not raw upstream output.

Teammate Lifecycle

No "DONE" state. QA approval ≠ mission accomplished. After QA approves, coordinator reports verdict + evidence to user and waits. Mission is accomplished only when the user explicitly confirms (e.g. "ship it", "done", "approved"). Until then, all teammates remain alive.

Shutdown only on user request. Coordinator never auto-shuts down the team. User must explicitly request shutdown ("disband", "end team", "shut down"). Then coordinator runs Shutdown procedure for every teammate.

Re-entry: original designer handles Phase 2 re-entry directly — full context preserved.

Shutdown procedure: Always prefer graceful: SendMessage asking to commit any uncommitted work, then SendMessage with {"type": "shutdown_request", "reason": "..."}. If the agent is mid-turn, tmux send-keys -t <pane> Escape to interrupt, then re-send. Agent approves and terminates.

If graceful shutdown fails and harsher methods are used (SIGTERM/SIGKILL the process, kill the session), always close the tmux pane afterward (tmux kill-pane -t <pane>). A lingering pane means the teammate is not actually gone — future coordinators may try to SendMessage it and wait forever.

Spawn Prompt Template

You are the [ROLE] for this agent team.

Your task: [SPECIFIC TASK]

Stop when: [OBSERVABLE COMPLETION CRITERION — concrete state, not "when you think it's done"]
Do NOT stop on: [COMMON FALSE-STOPS — e.g. "first draft ready", "happy path works", "build compiles"]

Context:
- Explorer findings: [summary or "see task list"]
- Design doc: [location or "not yet created"]
- File ownership: [YOUR FILES ONLY. Do not edit other files.]

Trust Hierarchy (tag ALL claims):
T1: Specs/RFCs/docs/source -> trusted | T2: Academic -> high trust
T3: Codebase analysis -> local facts | T4: Community -> verify first
T5: Training recall -> MUST promote or discard
Format: [T<tier>: <source>, <confidence: high/medium/low>]

Compliance:
- Critically analyze ALL inputs. You own bugs from unverified inputs.
- BEFORE writing code, invoke applicable skills via the Skill tool:
  go-coding-style (Go), python-coding-style (Python), testing-discipline (tests),
  superpowers:test-driven-development (code implementation), proof-driven-development (logic),
  superpowers:systematic-debugging + debugging-discipline (debugging).
  Follow every rule from invoked skills. Reviewer rejects non-compliance.
- Tag ALL factual claims: [T<tier>: <source>, <confidence>]. Untagged claims = reviewer rejection.
- Produce critique log (3+ issues found/fixed) before marking done
- git diff for secrets, static checks before commits, never push

[After both spawned:] Paired with [CONFIRMED NAME]. Message directly.

- [ROLE-SPECIFIC RULES]
- Set env CLAUDE_ROLE=[role name] (e.g. executor, reviewer, coordinator, explorer, designer, verifier, qa, brainstormer, snitch)
- [FOR EXECUTORS:] While implementing, actively look for code smell and design issues in all code you study or touch. Report ALL findings to coordinator — do not silently work around them.
- Mark task as "submitted" (not "complete") + notify coordinator when done. **CC the lead and snitch on all submitted, blocked, and completed claims.**
- If blocked, message coordinator with specifics. **CC the lead and snitch.**

Red Flags