name: boss-worker-reviewer description: Use when the user wants development run through a boss-worker-reviewer loop, where a boss agent clarifies requirements, writes prompts, dispatches worker and reviewer subagents, reports progress after each review, and iterates in rounds with user checkpoints.

Boss Worker Reviewer

Overview

Run a standardized multi-agent development loop where the boss is an orchestrating agent, not the user. The boss owns clarification, prompt design, subagent dispatch, progress reporting, and round-to-round control. The worker implements. The reviewer audits independently.

Core principle: do not let the user micromanage prompts after the template has been agreed once. The boss should confirm the prompt template format the first time, then directly dispatch worker and reviewer subagents in later rounds unless the template itself needs to change.

Hard Rules

1. Treat the boss as an agent role, never as the user.
2. Start every new problem by thinking through the request and producing 0-10 confirmation questions.
3. If the correct number of questions is 0, state that internally and proceed directly into the worker/reviewer loop.
4. Use a list-first, then selective follow-up clarification style:
   • first surface the full set of uncertain points
   • then ask only the points that truly affect implementation direction
5. Confirm the prompt template format with the user once at the beginning of the relationship.
6. After template confirmation, do not dump worker/reviewer prompts to the user every round unless:
   • the template itself changes
   • the user explicitly asks to inspect the prompts
   • a new class of task requires a materially different prompt contract
7. After every reviewer pass, report progress to the user and explicitly leave room for:
   • extra requirements
   • corrections
   • next-round changes
8. Every new user change returns the loop to the boss clarification stage.
9. Every implementation round must end with:
   • a commit
   • a clean delivered workspace
10. If the current workspace is already dirty, isolate the work first with REQUIRED SUB-SKILL: superpowers:using-git-worktrees.

Workflow

digraph boss_worker_reviewer {
    "User requests BWR mode" [shape=box];
    "Boss thinks and lists\n0-10 questions" [shape=box];
    "Questions needed?" [shape=diamond];
    "Clarify with user" [shape=box];
    "Prompt template confirmed?" [shape=diamond];
    "Confirm template format" [shape=box];
    "Boss writes worker prompt" [shape=box];
    "Dispatch worker" [shape=box];
    "Worker implements" [shape=box];
    "Boss writes reviewer prompt" [shape=box];
    "Dispatch reviewer" [shape=box];
    "Reviewer audits" [shape=box];
    "Boss reports progress\nand asks for changes" [shape=box];
    "User adds changes?" [shape=diamond];
    "Round complete" [shape=doublecircle];

    "User requests BWR mode" -> "Boss thinks and lists\n0-10 questions";
    "Boss thinks and lists\n0-10 questions" -> "Questions needed?";
    "Questions needed?" -> "Clarify with user" [label="yes"];
    "Questions needed?" -> "Prompt template confirmed?" [label="no"];
    "Clarify with user" -> "Prompt template confirmed?";
    "Prompt template confirmed?" -> "Confirm template format" [label="no"];
    "Prompt template confirmed?" -> "Boss writes worker prompt" [label="yes"];
    "Confirm template format" -> "Boss writes worker prompt";
    "Boss writes worker prompt" -> "Dispatch worker";
    "Dispatch worker" -> "Worker implements";
    "Worker implements" -> "Boss writes reviewer prompt";
    "Boss writes reviewer prompt" -> "Dispatch reviewer";
    "Dispatch reviewer" -> "Reviewer audits";
    "Reviewer audits" -> "Boss reports progress\nand asks for changes";
    "Boss reports progress\nand asks for changes" -> "User adds changes?";
    "User adds changes?" -> "Boss thinks and lists\n0-10 questions" [label="yes"];
    "User adds changes?" -> "Round complete" [label="no"];
}

Role Contracts

Boss

The boss is responsible for:

• understanding the request
• deciding whether there are 0-10 questions to confirm
• writing worker and reviewer prompts
• dispatching subagents
• deciding whether a reviewer FAIL can be handled directly or requires user escalation
• reporting round status to the user
• reopening clarification when the user adds scope, corrections, or new requests

The boss must not:

• treat the user as the prompt writer
• skip clarification thinking
• skip planning before real implementation work
• keep work in an uncommitted or dirty state at round handoff

Worker

The worker is responsible for implementation only.

The worker must:

• follow REQUIRED SUB-SKILL: superpowers:test-driven-development
• follow REQUIRED SUB-SKILL: superpowers:executing-plans
• use REQUIRED SUB-SKILL: superpowers:systematic-debugging for any bug, failure, or unexpected behavior
• use REQUIRED SUB-SKILL: superpowers:verification-before-completion before claiming success
• commit work before handoff
• leave the delivered workspace clean

The worker must not:

• perform review duties
• silently widen scope
• stop at partial analysis when the task calls for implementation

Reviewer

The reviewer is responsible for independent audit only.

The reviewer must:

• act independently from implementation
• focus first on blockers, root causes, missing verification, behavioral regressions, and scope violations
• avoid giving PASS because code “looks close enough”
• evaluate the real acceptance conditions, not just the existence of files or tests

The reviewer must not:

• implement fixes
• soften findings because effort was high
• confuse “some tests passed” with “the workflow is correct”

Prompt Standards

Boss prompt rules

Every boss-written prompt should:

• name the current task clearly
• define the single-round goal
• define scope boundaries
• define the real acceptance standard
• require root-cause reasoning when there is any bug or review failure
• require commit plus clean workspace before declaring completion

Worker prompt rules

Every worker prompt must explicitly require:

• TDD-driven development
• systematic debugging for bugs and failures
• real verification before completion claims
• plan execution discipline rather than ad hoc hacking
• commit and clean workspace at round end

Worker prompts should also specify:

• what success looks like in this round
• what is in scope
• what is explicitly out of scope
• whether the problem is feature work, remediation, or verification hardening

Reviewer prompt rules

Every reviewer prompt must explicitly require:

• independent review
• findings-first output
• blocker-focused reasoning
• root-cause validation, not surface confirmation
• explicit PASS/FAIL logic tied to acceptance criteria

Reviewer prompts should ask:

• whether the real workflow is functional
• whether scope was kept
• whether verification is adequate
• whether anything remains that should still block closure

FAIL Handling

When reviewer returns FAIL, the boss must classify the issue:

• Directly actionable implementation or verification issue
  • boss writes next worker prompt and continues without pausing the user
• Boundary, product, or risk escalation
  • boss reports the issue and asks the user before proceeding

Examples that require user confirmation:

• changing task boundaries
• introducing destructive or high-risk migration paths
• materially changing accepted product behavior
• replacing a planned architecture with a different one

Required Skills And Boundaries

Use these skills as part of the workflow. Do not describe rarely used skills outside this list.

superpowers:brainstorming

Boss must use this when the user first requests this mode or when a new round introduces meaningful new goals. Use it to think through the task, list 0-10 confirmation questions, and converge on the right direction before dispatching work.

superpowers:writing-plans

Boss must use this before real implementation begins. Use it to produce the round or task implementation plan that worker execution will follow.

superpowers:subagent-driven-development

Boss must use this as the main orchestration discipline for worker/reviewer delegation. Use it whenever the boss is dispatching the implementation and review loop.

superpowers:dispatching-parallel-agents

Boss should use this only when there are multiple independent subtasks that can safely run in parallel without shared critical-path coupling.

superpowers:executing-plans

Worker must use this while implementing an already written plan. Use it to keep work aligned with the agreed task steps and review checkpoints.

superpowers:test-driven-development

Worker must use this for feature work and fixes. No implementation should begin without the TDD discipline this skill defines.

superpowers:systematic-debugging

Worker must use this for any bug, failing test, or unexpected behavior. No speculative fixes without root-cause investigation.

superpowers:verification-before-completion

Worker must use this before claiming completion. Evidence comes before assertions.

superpowers:requesting-code-review

Boss or worker should use this when formal review is needed and the round is ready for reviewer evaluation.

superpowers:receiving-code-review

Boss must use this when absorbing reviewer feedback, especially when deciding whether a FAIL should trigger another worker round or a user escalation.

superpowers:using-git-worktrees

Boss or worker must use this when the main workspace is dirty or the task needs isolation. This is mandatory when clean handoff cannot be guaranteed in the current workspace.

superpowers:finishing-a-development-branch

Use this when the multi-round effort is actually complete and the team needs to decide how to integrate, merge, or wrap the branch cleanly.

Progress Reporting Contract

After every reviewer pass, the boss must report:

• current round status
• whether the round is PASS or FAIL
• the most important blocker or accomplishment
• what will happen next
• an explicit opening for user corrections or new changes

The boss should keep this report concise and decision-oriented. The user should always feel they can steer the next round.