Superpowers Quality Gates

Superpowers Quality Gates

Adds two mandatory post-implementation gates to every task in a superpowers plan:

1. Code-reviewer subagent — spec compliance + code quality. Always.
2. QA subagent — drives the running app via preview_* tools. Only for user-observable features.

When this kicks in

Anytime you are executing a superpowers plan — via the executing-plans, subagent-driven-development, or equivalent skills. The gate applies to:

• Every implementer report of status DONE or DONE_WITH_CONCERNS.
• BLOCKED / NEEDS_CONTEXT reports skip the gates and go back to the controller.

The process per task

digraph per_task_gates {
    "Implementer reports DONE" [shape=box];
    "Spawn fresh code-reviewer subagent" [shape=box];
    "Code-reviewer APPROVE?" [shape=diamond];
    "Implementer fixes, re-review" [shape=box];
    "User-observable feature?" [shape=diamond];
    "Spawn fresh QA subagent" [shape=box];
    "QA PASS?" [shape=diamond];
    "Implementer fixes, re-QA" [shape=box];
    "Mark task complete in TodoWrite" [shape=doublecircle];

    "Implementer reports DONE" -> "Spawn fresh code-reviewer subagent";
    "Spawn fresh code-reviewer subagent" -> "Code-reviewer APPROVE?";
    "Code-reviewer APPROVE?" -> "Implementer fixes, re-review" [label="no"];
    "Implementer fixes, re-review" -> "Spawn fresh code-reviewer subagent";
    "Code-reviewer APPROVE?" -> "User-observable feature?" [label="yes"];
    "User-observable feature?" -> "Spawn fresh QA subagent" [label="yes"];
    "User-observable feature?" -> "Mark task complete in TodoWrite" [label="no"];
    "Spawn fresh QA subagent" -> "QA PASS?";
    "QA PASS?" -> "Implementer fixes, re-QA" [label="no"];
    "Implementer fixes, re-QA" -> "Spawn fresh QA subagent";
    "QA PASS?" -> "Mark task complete in TodoWrite" [label="yes"];
}

Code-reviewer dispatch

• subagent_type: "superpowers:code-reviewer" (Claude Code) or equivalent.
• Model: haiku for pure helpers / small API routes; sonnet for multi-file / integration work.
• Give the reviewer: commit SHA range (base + head), plan file path + task section, project convention summary, and the implementer's self-report.
• Ask for a combined spec-compliance + code-quality review in one pass (≤220 words) to keep iteration fast. Verdict: APPROVE / REQUEST CHANGES with file:line refs.

QA dispatch (only for user-observable features)

Skip QA for:

• Pure library helpers, utilities, pure functions
• SQL migrations and DB schema changes
• Translation-only changes (unless rendering is suspected broken)
• Non-UI server code that has no visible effect

Invoke QA for:

• Any new/modified React component, page, or layout
• API changes that materially alter a rendered flow
• New user-visible text, states, or interactions

QA subagent setup:

• subagent_type: "general-purpose" with access to preview_start, preview_snapshot, preview_eval, preview_click, preview_fill, preview_screenshot, preview_console_logs, preview_network, preview_inspect, preview_resize.
• Give the QA subagent: feature summary, URL path to test, golden path bullets, edge cases, and mobile-first verification at 390px.
• Report format: screenshots, golden-path pass/fail, edge-case pass/fail, regressions, verdict ✅ / ⚠️ / ❌.

Planning-time enhancement

When producing the implementation plan (via writing-plans), annotate each task with (QA needed) or (no QA) so the executor can dispatch the right gates without guessing.

Rationale

Self-review by the implementer catches maybe half of real issues. A fresh reviewer with no implementation context catches spec drift and quality slips the implementer's optimism hides. A QA pass on the running app catches everything that looks correct in the diff but breaks in the browser (loading states, mobile layout, console errors, network failures). Two independent gates, fast to run, cheap compared to debugging at the end of a branch.

When persistent agents are available

If the runtime exposes a SendMessage / persistent-agent continuation API, you may spawn one long-lived code-reviewer and one long-lived QA agent and send per-task requests instead of spawning fresh. Never skip the gate itself — only the spawn mechanism changes.