# Superpowers Quality Gates

> Enforce per-task reviewer + QA subagents during plan execution. Use whenever the superpowers flow (brainstorming → writing-plans → executing-plans → subagent-driven-development) runs a software-engineering task. Adds two mandatory gates after every implementer — a code-reviewer subagent and, for user-observable features, a QA subagent — so spec drift and UX regressions are caught per task, not at the end of the branch.

- Skill: `jlnbuiles/superpowers-quality-gates` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jlnbuiles/superpowers-quality-gates`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jlnbuiles/superpowers-quality-gates/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: jlnbuiles (https://skillmd.com/u/jlnbuiles)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jlnbuiles/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

```dot
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.