/qa-full

The per-feature QA pipeline. Where /daily-qa is the unattended, repo-wide, time-windowed background sweep that only reports, /qa-full is the present-human, branch-scoped, audit → fix → verify pipeline you run the moment a feature is done — before /finish-branch and /ship.

implement → /qa-full → /finish-branch → /ship
            (audit → fix → verify)

It reuses /daily-qa's trigger matrix (which checks to run based on what changed) with three deliberate differences:

• Scope is the branch diff (base..HEAD + working tree), not a time window.
• It fixes, not just reports. Every check runs in three phases — audit (report-only discovery is fine here), fix (apply the smallest correct fix, one atomic commit per fix — except /review's bundled output, see Hard rules), verify (re-run the same check plus the test suite and prove the fix holds). The final verdict is on the repaired branch.
• Interactive checks actually run. Because a human is present, the checks /daily-qa only recommends — /qa, /web-perf, /design-review, the dynamic /a11y pass — run here when their triggers fire.

This is not an audit skill. It is a full security pipeline, a full performance pipeline, a full correctness/test pipeline, and a full browser/design pipeline, selected per-diff and driven to green.

How sub-skills run

Each /name in the steps below is a skill. Run it by invoking it with the Skill tool (for example Skill(defense)), then follow the instructions it loads. A check counts as run only when that call is in the session; doing the check's work by hand from memory is not running it. If a skill cannot be invoked here, the check is SKIPPED with the reason. For a triggered /qa that cannot be loaded, inspect the installed gstack/superskills setup, run its available setup step, and retry the Skill call. Ask the user for any setup detail only they can provide. If /qa remains unavailable, record SKIPPED with that evidence and NOT READY.

Hard rules

• The bar is the superskills quality standard — TDD/DRY/SOLID/YAGNI (applied in every step's fix phase: test first, no duplicated logic, small single-purpose units, nothing speculative) plus the hard-gate list, which is spelled out in full in Step 10's Blocker set. The canonical written copy is ENGINEERING_STANDARDS.md in the superskills install (a plugin install exposes it at ${CLAUDE_PLUGIN_ROOT}/ENGINEERING_STANDARDS.md); it is not expected to exist in the project you're reviewing, so don't flag it as missing. Every fix you land must meet that bar too — a fix that adds untested public surface or duplicates logic is not a fix.
• Audit → fix → verify, per check. For every check whose trigger fires:
  1. Audit — run the sub-skill (its normal report-only output is the discovery pass).
  2. Fix — for each CRITICAL/HIGH finding (and MEDIUM where the fix is small and safe), root-cause it (/debug discipline: no symptom patches), write the failing test first when it's a logic bug (/tdd), apply the smallest correct fix, and commit it atomically with a message naming the check and finding.
  3. Verify — re-run the same sub-skill on the diff and re-run the test suite. A fix is only "fixed" when the re-audit no longer reports it and tests are green. Never claim a fix without this fresh evidence (/verify discipline). A finding you could not fix (needs a product decision, external service, credentials, or an architectural change beyond the diff) is an UNFIXED blocker: record what you tried and why it's out of reach. Do not quietly downgrade it to a warning.
• Fix only what the diff and the findings justify. Do not refactor untouched code, upgrade dependencies, or "improve" unrelated modules while you're in there. Scope stays on the branch diff plus the exact lines a finding points at.
• Commit, but never push or open a PR. Each fix lands as its own commit on the current branch so the user can review/revert individually. Exception: /review exposes no per-finding boundary, so its output lands as one commit per invocation (Step 3). Integration and shipping belong to /finish-branch and /ship.
• Ground every finding and every fix in concrete evidence: file:line, failing test name, log snippet, severity as the underlying tool produced it, and the commit SHA of the fix. No speculation.
• Separate blockers from warnings. Only test/build failures and CRITICAL/HIGH findings block. Everything else is a warning — fix it when the fix is cheap and safe, otherwise ship it with a follow-up note.
• Bounded loops. At most two fix rounds per check, then one final verification pass (Step 10). If something is still red after that, it's an UNFIXED blocker with the attempts documented — not a third round.
• Never claim SHIP-READY without receipts. The verdict must cite the exact checks that ran, what they found, what was fixed (with commits), what was re-verified, and what was skipped (and why).
• An unknown dev URL is a question, not a reason to refuse browser QA. When /qa is triggered, invoke it even if no URL is known. Follow the target-resolution flow below, including local setup or a question to the user, and resume the same run when the target is available. A triggered /qa check that cannot run is NOT READY, never SHIP-READY.
• No silent skips — mandatory accounting. Every check must resolve to exactly one of: RAN-CLEAN (ran, nothing to fix), FIXED(n) (ran, n findings fixed and re-verified — list commits), UNFIXED (ran, at least one blocker could not be fixed — reason), SKIPPED (stated reason — e.g. "no reachable dev server and none could be started", "scanner not authorized in this env"), NOT-TRIGGERED (its diff trigger didn't fire), or MANDATORY-FAIL (a CLAUDE.md-mandatory check that was skipped). A check whose trigger fired but that neither ran nor was explicitly skipped-with-reason is an unaccounted check ⇒ NOT READY. "Recommend-only" is not an allowed resting state for a triggered check. A RAN-CLEAN, FIXED or UNFIXED row stands on the Skill call that ran it; a row with no such call is unaccounted too. The superskills ledger hook (hooks/hooks.json for plugin installs, scripts/install-qa-full-ledger-hook.sh otherwise) checks this when the session stops and sends you back to invoke any check it can't find. Projects may mark specific checks MANDATORY in CLAUDE.md (e.g. /pentest on a payments service), and for those, SKIPPED is itself a blocker.
• Money and authorization still need a human yes. /code-review ultra is a billed cloud run, and /review's Codex passes spend OpenAI tokens — ask before launching either, never assume. /pentest's in-harness default costs nothing beyond this session, but the skill still requires the user to confirm authorization before it scans — ask, then run. Its clearwing modes bill a separate LLM provider and stay ask-first. "Ask, then run" is still running; it is not report-only.

Project configuration (CLAUDE.md)

This pipeline reads the project's root CLAUDE.md for a few optional settings. They are plain prose (CLAUDE.md is agent instructions, not a config file) — look for a ## qa-full section and honor whatever it states. Example:

## qa-full

- Mandatory checks (must RUN with evidence — a skip is a blocker): `/pentest`, `/defense`
- Hard perf gate: LCP ≤ 2.5s and INP ≤ 200ms on `/` and `/checkout` (breach blocks)
- Design: skip `/design-review` (design is owned by the design team, do not auto-fix visuals)
- Dev URL: http://localhost:3000   (for `/web-perf`, `/qa`, `/a11y`, `/fuzz`)
- Test/build: `pnpm test` and `pnpm build`
- QA tier: exhaustive

Recognized settings (all optional; absence = the defaults in the steps below):

• Mandatory checks — listed commands must read RAN-CLEAN or FIXED in the ledger; SKIPPED is a blocker (any step; Step 10 enforces it). MANDATORY overrides the check's own diff trigger: run it on the diff even when the trigger didn't fire, so NOT-TRIGGERED is not an acceptable state either. Use for compliance-critical surfaces (payments, auth, PII).
• Hard perf gate — turns a /web-perf budget breach that survives the fix round from a warning into a blocker (Step 6).
• Design: skip /design-review — opt out of the visual-fix pass (Step 8) entirely; by default it runs on any UI change. This skips the check (ledger: SKIPPED("project opt-out")) — it does not turn it into a report-only run.
• Test/build commands — feed Steps 2 and 10. Dev URL — feeds Steps 4 (/fuzz), 6, 7 and 8. QA tier — feeds Step 7; defaults to standard.

If there is no ## qa-full section, run with the built-in defaults — nothing here is required.

Resolve a dev target for browser checks

Use this flow when a triggered /fuzz, /web-perf, /qa, /design-review, or dynamic /a11y check needs a running app. Resolve the target once and reuse it; keep any server you start alive through the final browser check.

1. Read the project's CLAUDE.md Dev URL, AGENTS.md, README.md, and development/setup docs. Check the project's declared dev/start script or equivalent and probe documented local ports. A responding localhost port is usable only after you verify it serves this project, not another app.
2. If the app is not running, follow the project's setup instructions. Install its declared dependencies when needed, start its documented dev command, and wait for a reachable URL. Record the command, URL, and startup result in the ledger. Do not invent a port, command, credential, or external service.
3. If the URL or startup command is still unknown, or startup needs user-owned configuration, ask the user for the dev/preview URL or the missing setup detail. Tell them what you already checked. Let the user configure secrets locally; never request credentials in chat. Pause the affected check and resume it after their answer. An unanswered question is pending context, not a SKIPPED check or a final refusal.
4. If a documented start fails, inspect its error and attempt a bounded fix to the local setup. If it still cannot run, ask for the missing information or user action. Only record SKIPPED after documenting discovery and startup attempts and the user confirms there is no runnable target or declines the needed setup. For a triggered /qa, that SKIPPED result is a NOT READY blocker: the feature has not been browser-tested.

/qa has its own diff-aware target discovery and browser setup. Invoke it without a URL when this flow has not resolved one; follow its question or setup path rather than replacing browser testing with unit tests or curl.

Step 1: Establish the diff scope and a clean tree

1. Detect the base branch: gh repo view --json defaultBranchRef -q .defaultBranchRef.name, else git symbolic-ref refs/remotes/origin/HEAD, else fall back to main/master.
2. If $ARGUMENTS names a base branch or --scope <paths>, use it.
3. Resolve the diff ref: git fetch origin <base> and use origin/<base> when that ref exists, else local <base>. This is what /review and /qa diff against too, and it stays correct after Step 1.5 creates a working branch (local <base> would then equal HEAD and the set would be empty). Compute the changed-file set: git diff --name-only <diff-ref>...HEAD -- <scope paths> (drop the -- part when no --scope was given) plus uncommitted changes (git status --porcelain). This set drives every trigger below. Fix commits made by this pipeline extend the set — later steps and the final pass (Step 10) audit the fixes too.
4. Clean-tree precondition. The fixers (/qa, /design-review) need each fix to be its own atomic commit, so they stop on a dirty tree. Handle it once, here: if git status --porcelain is non-empty, ask the user (via AskUserQuestion) whether to commit the in-progress work now (recommended — a descriptive commit so the feature is preserved before fixes land) or stash it. Do not proceed with a dirty tree.
5. Never run on the base branch itself. The sub-skills' diff-aware modes (/review, /qa, /design-review) key off "current branch ≠ base" and diff against merge-base(origin/<base>, HEAD). If git branch --show-current equals the base and there are unpushed commits, create a working branch at HEAD first — git switch -c qa-full/<base>-<YYYY-MM-DD> (reuse it if a same-day branch already exists from an aborted run) — and run the whole pipeline there. Step 10 folds it back: fast-forward the base to the working branch (git switch <base> && git merge --ff-only qa-full/...) and delete the working branch. No history is rewritten; the base just gains the fix commits. If there are no unpushed commits either, there is nothing to QA.
6. Record at the top of the report: base branch, diff ref, working branch (if created), commit range, changed-file count, and the HEAD SHA before any fixes.

If there is no diff against base, stop and say so — there is nothing to QA.

Step 2: Tests & build (always — audit → fix → verify)

1. Find the project's test/build commands from CLAUDE.md; if absent, infer from package.json scripts, Makefile, pyproject.toml, etc. If you cannot determine them, ask rather than guess.
2. Audit: run the test suite and the build. Capture exact failures (test name + verbatim error in a code block).
3. Fix: for each failing test or build error, follow /debug — reproduce, root-cause, then fix the cause (not the assertion). Commit each fix.
4. Verify: re-run the full suite and build. Green ⇒ FIXED(n). Still red after two rounds ⇒ UNFIXED blocker with the failing test and what was tried.

If this step ends UNFIXED after two rounds, stop here and report NOT READY with the failing test. Every later step's verify phase depends on a green suite — running fixers on a red suite is fix → hope, not fix → verify. Mark every downstream ledger row SKIPPED("pipeline halted at Step 2"). A working branch from Step 1.5 stays as-is (base untouched) so the fix commits are there for the user.

Step 3: Correctness + quality — /review then /clean-code (always)

Two halves. Both sub-skills are in-tree, so they are invocable from inside any session or tool, and Step 1.5 guarantees you are on a non-base branch, which /review's own branch guard requires.

Correctness — /review. /review is not a report-only audit: one invocation reads the diff, auto-applies its mechanical (AUTO-FIX) findings to the working tree, asks you about the rest (ASK items) via its own AskUserQuestion, and never commits. Treat one call as one atomic audit + fix + ask unit:

1. Run /review against the base this pipeline resolved in Step 1. It has no argument channel, so it always diffs merge-base(origin/<base>, HEAD) — if Step 1 resolved a non-default base or a --scope, say so in the ledger evidence: /review reviewed the full default-base diff.
2. Commit what it changed as one commit attributed to /review (e.g. review: apply AUTO-FIX + approved ASK findings), so the tree is clean before /clean-code and nothing /review fixed can be lost by a later revert. If --scope was given, stage and commit only files under scope; any out-of-scope edits /review made stay uncommitted (stash them so the tree is clean, noting the stash ref) and are flagged in the ledger with that ref for the user — never silently committed. For any CRITICAL it reported but could not fix, root-cause (/debug), write the failing test first (/tdd), fix, commit atomically.
3. Verify: run /review once more. It re-scans the full base diff including the fix commits — that's the point. A CRITICAL still present ⇒ UNFIXED blocker. Commit anything this second pass auto-fixed the same way. Do not run it a third time in this step.

/review's adversarial section runs a free Claude subagent and, when the Codex CLI is installed and enabled, codex exec / codex review passes that spend OpenAI tokens. Those Codex passes are ask-first under the money rule. You are the one executing /review's instructions, so no config change is needed: when its Codex preflight says Codex would run — CODEX_MODE: ready in current gstack, CODEX_AVAILABLE with OLD_CFG not disabled in older versions — ask the user once whether to spend on Codex for this run; if declined, do not run the codex exec / codex review commands and proceed exactly as the section's disabled/unavailable branch describes (Claude adversarial subagent still runs). Record the Codex state and the user's answer in the ledger. Never flip the global codex_reviews config on the user's behalf.

CODEX_MODE: not_authed can be a false negative: gstack's preflight only recognises a Codex login, so a Codex CLI configured for a custom provider (e.g. model_provider = "azure" with an API key in the environment) reads as unauthenticated while working fine. When the preflight says not_authed but ${CODEX_HOME:-$HOME/.codex}/config.toml sets a model_provider:

1. Ask first — fold it into the one Codex question above: the probe is itself a billed call on the user's provider. Declined ⇒ skip the probe and the passes.

2. Probe the model the passes will use, bounded, so a working default model cannot hide an unusable review model and a stalled endpoint cannot hang the pipeline:

   source ~/.claude/skills/gstack/bin/gstack-codex-probe 2>/dev/null
   if ! command -v _gstack_codex_timeout_wrapper >/dev/null 2>&1 \
      || ! command -v _gstack_codex_select_model >/dev/null 2>&1; then
     echo "CODEX_PROBE: broken_install (gstack-codex-probe helper not found)"
   elif _gstack_codex_select_model exec; then
     # gstack's own resolver: GSTACK_CODEX_MODEL, then the model in config.toml,
     # then gstack's default, so the probe tests the model the passes will use.
     echo "CODEX_MODEL: $_GSTACK_CODEX_SEL ($_GSTACK_CODEX_SEL_SRC)"
     _gstack_codex_timeout_wrapper 120 codex exec -s read-only \
       -c "model=\"$_GSTACK_CODEX_SEL\"" "Reply with exactly: PONG" < /dev/null
   fi

3. Answers PONG ⇒ treat Codex as ready and run the passes with that provider and model. CODEX_PROBE: broken_install, or exit code 126/127 ⇒ treat it as broken_install (gstack's branch: reinstall advice, no model advice). Any other error, timeout or text ⇒ model_unusable: skip the passes, tell the user to set GSTACK_CODEX_MODEL (or model in config.toml) to a deployment their provider serves. A CODEX_MODEL: invalid line from the resolver means the same: no call was made.

Record the probe command, model and result in the ledger either way.

If /review is unavailable (gstack is not installed, the Skill tool cannot load review, or its preamble fails), do not skip the correctness step. Run the in-tree fallback, /basic-review <diff-ref>...HEAD, instead:

1. Audit: invoke /basic-review with the diff ref Step 1 resolved. It is read-only and reports findings as file:line with severity.
2. Fix: for each CRITICAL/HIGH (and cheap MEDIUM) finding, root-cause it (/debug), write the failing test first (/tdd), apply the smallest fix, and commit it atomically, naming basic-review and the finding.
3. Verify: run /basic-review once more on the same range; a CRITICAL still reported is an UNFIXED blocker.

Name both in the ledger row's first cell, /review (fallback: /basic-review), and put the reason /review was unavailable in its evidence. The row's status is the fallback's result (RAN-CLEAN, FIXED(n) or UNFIXED), never SKIPPED: the correctness check ran.

Quality — /clean-code. After correctness is green and committed, run /clean-code <diff-ref> [--scope <paths>] with the diff ref and scope this pipeline resolved. It audits KISS / DRY / SOLID / YAGNI against ENGINEERING_STANDARDS.md, applies the smallest safe refactor per finding under a green suite (characterization test first where none exists), commits each atomically, re-audits, and reverts a failed refactor with git checkout on only the files it touched. Its findings left UNFIXED are warnings here, not blockers — quality debt ships with a note; bugs don't.

/code-review ultra (deep multi-agent cloud review) is billed — when a /review finding is high-stakes (payments, auth, data loss, concurrency), ask the user whether to launch it. Do not launch it unasked. Claude Code's built-in /code-review and /simplify are not part of this step: /review already covers correctness here, and an optional extra pass would have no ledger row.

Step 4: Security pipeline — /defense, /iac-scan, /pentest, /fuzz

/defense (always).

1. Audit: run /defense scoped to the changed files (OWASP Top 10 / secrets / auth / crypto / data-protection).
2. Fix: remediate every CRITICAL/HIGH (and cheap MEDIUMs): remove or rotate-and-externalize hardcoded secrets, add the missing authz check, parameterize the query, escape the output, switch the weak primitive, add the validation. Each fix gets a regression test where a test can express it (e.g. "unauthenticated request to X returns 401"). Commit atomically.
3. Verify: re-run /defense on the same files; the finding must be gone.

/iac-scan (when infra/deploy config changed). Trigger on Dockerfile, docker-compose*, *.tf/*.tfvars, k8s/Helm manifests, .github/workflows/**, .gitlab-ci.yml, Jenkinsfile, nginx/cloud config (see /iac-scan's trigger section for the authoritative list). Audit with the local static linters, fix CRITICAL/HIGH misconfigs (root container → non-root user, 0.0.0.0/0 ingress → scoped CIDR, wildcard IAM → least privilege, privileged pod → dropped, untrusted CI trigger → pinned/guarded, baked-in secret → injected), re-scan to verify.

/pentest (triggered when /defense found CRITICAL/HIGH, or the diff touches auth/crypto/session/token/deserialization/file-upload paths). Its default mode hunts in this harness — the session's own model reads the code and reports findings with evidence levels; no external scanner, no spend beyond the session. Confirm authorization with the user first (the skill's own questions), then run it; the in-harness hunt is the check, not a stand-in. Fix CRITICAL/HIGH it surfaces, re-run to verify. clearwing appears only behind its ask-first gate: the user names it, asks for a network probe, or wants SARIF/CI output — and its pipeline can run agent-driven on this session via the bundled bridge (no provider, no spend) instead of provider-driven. Provider-driven runs configure their own LLM provider and bill it per run — declining clearwing means run the in-harness mode, not skip the check. If the user declines the check itself (no authorization) ⇒ SKIPPED(reason). If CLAUDE.md marks /pentest MANDATORY, SKIPPED is a blocker.

/fuzz (triggered when the diff adds or changes endpoints, input parsing, file-upload handling, or deserialization). Needs a running target: find the dev URL with the target-resolution flow, then run /fuzz against the new surface; fix crashes, injections, and auth bypasses it surfaces (with a regression test); re-fuzz to verify. If no target is possible after that flow ⇒ SKIPPED(reason). If CLAUDE.md marks /fuzz MANDATORY, SKIPPED is a blocker.

/cso backstop. If the diff crosses a new trust boundary (new auth path/endpoint/external input/deserialization) and there's no evidence a threat model was done at plan time, run /cso on that boundary and fold any CRITICAL/HIGH into the /defense fix round. Threat modeling belongs in /write-plan; this is the late catch, not a substitute.

Step 5: Database pipeline — /db-optimize (auto-run if triggered)

Trigger when changed files match ORM models, migrations, query builders (**/models/**, **/migrations/**, **/queries/**, **/*repository*, **/*.sql), raw SQL in the diff, or new ORM calls (.find, .where, .includes, .join, .preload).

1. Audit: run /db-optimize scoped to matched files (run /dbmap first if it asks for a schema map).
2. Fix: N+1s on hot paths → eager-load/batch (includes/preload/ select_related/dataloader); missing indexes on hot paths → add a migration for the index; obviously-redundant queries → dedupe. Add a test that asserts the query count where the ORM supports it. Commit atomically.
3. Verify: re-run /db-optimize; the hot-path findings must be gone and the migration must apply cleanly in the test run.

Non-hot-path suggestions are warnings (fix if trivial). No trigger ⇒ NOT-TRIGGERED.

Step 6: Frontend perf pipeline — /web-perf (+ /perf-profile)

Trigger when the diff includes frontend code (**/*.tsx, **/*.jsx, **/*.vue, **/*.svelte, **/components/**, **/pages/**, **/styles/**, **/*.css, **/*.scss), new images/fonts/assets, or bundler config (next.config.*, vite.config.*, webpack.config.*).

1. Resolve the dev URL with the target-resolution flow above; start the dev server if needed. If the flow establishes that no target is possible ⇒ SKIPPED with the startup error and the user's answer in the ledger.
2. Audit: run /web-perf against the affected routes. Record Core Web Vitals (LCP, INP, CLS) vs. any known budget.
3. Fix: address the measured regressions attributable to the diff — render-blocking imports → defer/lazy, oversized image/font → optimize or preload, layout shift → reserve dimensions, long task → split/memoize. Commit atomically.
4. Verify: re-run /web-perf on the same routes; report before/after numbers.

• A budget breach that survives the fix round is a warning by default, unless CLAUDE.md defines a hard perf gate — then it blocks.
• /perf-profile (triggered when the diff touches hot server-side paths, the change is pre-launch, or /db-optimize//web-perf point at a server-side bottleneck): run it against the affected endpoint/job, fix the localized bottleneck (cache, batch, move off the request path), re-profile to verify. Needs a representative workload — if none is available ⇒ SKIPPED(reason).

Step 7: Browser QA pipeline — /qa (auto-run if triggered)

Run /qa — the full test → fix → re-verify loop — not /qa-only. This is the check that replaces manual click-through QA, and a human is present.

Trigger when the diff includes anything a human would manually QA in a browser: UI/frontend code, pages/routes, forms, route handlers serving HTML, API endpoints the UI consumes, auth/session flows, or config that changes user-facing behavior.

1. Invoke /qa whenever this trigger fires, even if no dev URL is known. Give it the resolved URL if Step 4 or 6 found one; otherwise invoke it without a URL so its diff-aware mode can discover the app or ask. Scope it to the affected surface at the project's QA tier (CLAUDE.md, default standard: critical + high + medium). If it needs a server, follow the target-resolution flow above and resume /qa after setup or the user's answer. A missing URL alone never justifies SKIPPED, stopping the pipeline, or declaring browser QA complete. Let /qa finish its audit → fix → re-verify loop with atomic commits and before/after health scores.
2. Fold its before/after health score, fixed-bug list (with commits), and any bugs it could not fix into the ledger.

• User-facing CRITICAL/HIGH bugs that /qa could not fix ⇒ UNFIXED blocker.
• If the target-resolution flow ends without a runnable app, record SKIPPED(reason) and a NOT READY blocker. Say what setup was attempted and what the user needs to provide before browser QA can run.

Step 8: Design + accessibility pipeline — /design-review, /a11y

/design-review (when the diff includes UI changes, unless CLAUDE.md opts out). Run /design-review against the changed screens — it audits visual consistency, hierarchy, spacing, AI-slop tells and slow interactions, then fixes them with atomic commits and before/after screenshots. Let it complete. Visual findings it can't fix are warnings, not blockers. If the project opted out in CLAUDE.md, record SKIPPED("project opt-out") and move on.

/a11y (when the UI change is heavy and likely to affect assistive tech — new/changed interactive components, forms, ARIA/role/tabindex, focus/keyboard handling, images, color/contrast, motion; see /a11y's trigger section).

1. Audit: run the static pass on the diff, and the dynamic axe pass when the dev URL is reachable (it is, if Step 6/7 ran).
2. Fix: every CRITICAL/SERIOUS — native element over ARIA-on-a-div, missing label/name, unreachable-by-keyboard control, focus trap, contrast below ratio, missing reduced-motion guard. Commit atomically.
3. Verify: re-run the same pass; CRITICAL that survive ⇒ UNFIXED blocker.

Scope split: /design-review owns visual quality; /a11y owns WCAG / assistive-tech correctness. They overlap on contrast — /a11y's measured contrast finding is authoritative.

Step 9: Coverage pipeline — /test-coverage + /playwright

1. Audit: for each changed file (including this pipeline's fix commits), locate its test (sibling *.test.*, parallel tests/). Use coverage data if present (coverage/, lcov.info, .coverage); else do a structural check for new exported functions / branches / error paths without an assertion.
2. Fix: run /test-coverage on the diff — it writes and applies the missing unit tests (and integration tests where risk crosses a boundary), enforcing Google's Testing-on-the-Toilet practices. For user-facing flows with no e2e coverage, run /playwright to generate and run the e2e test so a regression test is left behind. Commit atomically.
3. Verify: run the full suite; the new tests must pass, and the structural check must show no new public surface with zero tests.

New public surface still untested after this step ⇒ UNFIXED blocker. Internal helpers without tests are warnings.

Step 9b: Prose quality pipeline — /humanize (auto-run if triggered)

Trigger: the diff adds or modifies user-facing copy: documentation, help prose, marketing pages, locale strings, or visible UI text, in any file type python3 skills/humanize/toolkit/userfacing.py classify <path> does not call none. NOT-TRIGGERED when no user-facing copy changed. Internal prompts, agent instructions, plans, and code comments are out of scope. Run the Markdown normalizer only on markdown/text files; other types get the scan on the extraction and surgical in-place edits (see /humanize).

Scope rules:

• Exclude prose the project does not own (vendored, mirrored, or generated trees) and historical records (CHANGELOG.md and the like): that wording is deliberate or upstream's, and rewriting it falsifies provenance.
• Warnings tier. A prose-slop flag is style, not correctness: it never enters the blocker set below. A flag that survives the fix rounds ships as a warning with a follow-up note.

1. Audit: run /humanize's deterministic scan (its toolkit's slop_report.py) over each in-scope changed prose file and read the report.
2. Fix: invoke /humanize and apply it surgically to flagged spans only — its own contract (deterministic fixes, subtractive edits, re-scan as the gate; never a whole-document rewrite) is the fix policy here too. Commit atomically like any other fix.
3. Verify: re-scan the edited files and re-run the test suite. Repos often pin exact doc strings in tests; a humanize edit that touched pinned prose must break here, loudly, not silently ship.

The ledger row resolves to RAN-CLEAN (no flags worth fixing), FIXED(n) (flags fixed and re-scanned), SKIPPED(reason), or NOT-TRIGGERED. Remaining flags are warnings, never UNFIXED blockers.

Step 9c: AI-behavior pipeline — /eval (ask-first if triggered)

Trigger: the diff changes AI behavior. Judge it the way human eyes would: does the change alter what a model sees, how it is instructed, or how its output is judged or used? A prompt template edited inside source code counts, not just prompt files. The obvious file signals are prompts, agent or skill instructions (**/SKILL.md, .claude/commands/**, AGENTS.md / CLAUDE.md instruction files), and LLM/RAG pipeline code or configuration (retrieval parameters, judge rubrics, agent-loop logic). Pure formatting changes to the same files do not count. NOT-TRIGGERED means "no plausible behavior change," never "no matching filename."

An eval run spends model calls (case runs plus judge votes), so it follows the money rule: ask the user first, name what it will cost, and run only on an explicit yes. A decline is SKIPPED(reason: not authorized) — a legal skip with reason, not a blocker.

1. Audit: invoke /eval; it builds or reuses the project's synthetic eval set for the changed behavior and reports the behavior's before/after system metrics (pass rate per dimension), with the judge's calibration (TPR, TNR, accuracy, precision, plus the bias reading) attached so the numbers are trusted before they are read.
2. Fix: wording first, structure second — the method's fix ladder.
3. Verify: re-run the eval. The changed behavior must be no worse than the baseline on every reported metric, and better on the dimension the change targeted. "No degradation" is the floor, not the goal.

A metric regression is a warning unless the project marks evals MANDATORY in CLAUDE.md; a MANDATORY eval that was declined or never ran is MANDATORY-FAIL.

Step 10: Final verification pass, ledger, verdict

The fix rounds changed the branch, so verify the whole result once more:

1. Fresh tests + build on the final HEAD (Step 2 commands). Stale results ⇒ NOT READY.
2. Re-audit the fix commits: run /defense scoped to the files the fix commits touched, and read the fix commits themselves (git show original-HEAD..HEAD) against /review's checklist — /review takes no commit range, and Step 3 already re-ran it twice. When /review was unavailable, run /basic-review original-HEAD..HEAD for this re-audit. The fixes must not introduce a CRITICAL/HIGH. If they did, one more fix + re-verify, then stop.
3. Diff sanity: git log --oneline <base>..HEAD — every pipeline commit should name its check/finding; nothing outside the diff scope was touched.
4. Fold back the working branch if Step 1.5 created one: `git switch<base> && git merge --ff-only qa-full/<...> && git branch -d qa-full/<...>`. If the fast-forward fails, the base moved underneath you — stop and report; never force.

Then build the accounting ledger — a row per check, each resolved to RAN-CLEAN / FIXED(n) / UNFIXED / SKIPPED(reason) / NOT-TRIGGERED / MANDATORY-FAIL. The verdict cannot be SHIP-READY while any triggered check is unaccounted or UNFIXED.

Phase-5 accounting (honest scope): /qa-full is the entry to Phase 5, so it can only enforce the pre-ship half. It cannot verify /finish-branch, /ship, or /land-and-deploy — those run after this pipeline, so do not claim they're done. A passing verdict is the hard precondition for ship: only on SHIP-READY do you hand off "Proceed to /finish-branch then /ship."

Then the verdict:

• SHIP-READY — zero blockers remaining and every triggered check accounted for and the final pass is green. List what was fixed (commits), warnings + follow-ups, then hand off to /finish-branch → /ship.
• NOT READY — one or more blockers survived the fix rounds (or a check is unaccounted / MANDATORY-FAIL). List each with its file:line/test-name evidence, what was tried, and what the user needs to decide or provide. Tell the user to resolve and re-run /qa-full.

Blocker set (any one ⇒ NOT READY — this is the authoritative list for the verdict; it mirrors the superskills ENGINEERING_STANDARDS.md hard gates, kept in sync by the maintainer). Each is evaluated after the fix rounds:

• failing test or broken build, or test/build not freshly run on final HEAD (Step 2/10)
• /review CRITICAL correctness finding still present (Step 3)
• /defense CRITICAL/HIGH security finding still present (Step 4)
• /fuzz CRITICAL/HIGH — crash, injection, or auth bypass — still reproducible (Step 4)
• /pentest CRITICAL/HIGH vulnerability still present, when it ran (Step 4)
• /iac-scan CRITICAL/HIGH infra misconfig still present (Step 4)
• N+1 / missing index on a hot path still present (Step 5)
• CRITICAL/HIGH browser-QA bug in a user-facing flow /qa could not fix (Step 7)
• triggered /qa SKIPPED because its skill could not be loaded or no runnable app was available after target resolution (Step 7); browser QA remains unverified
• /a11y CRITICAL — a control unusable by screen-reader/keyboard — still present (Step 8)
• new public surface with zero tests after /test-coverage (Step 9)
• a hard perf gate breach after the fix round, only if CLAUDE.md defines one (Step 6)
• a triggered check left unaccounted — neither run nor SKIPPED with a reason
• a CLAUDE.md-MANDATORY check that was SKIPPED rather than run

Report format

Write to qa-full-reports/<branch>-<YYYY-MM-DD>.md (create dir; add to .gitignore). Structure:

# QA-Full — <branch> @ <YYYY-MM-DD>

Base: <base>  Range: <base>..HEAD  Changed files: N (+M from fixes)
HEAD before fixes: <sha>  HEAD after: <sha>  Fix commits: K

## VERDICT: SHIP-READY ✅ | NOT READY ⛔

### Fixed (audit → fix → verify, each with its commit)
1. <check> — <file:line> — <finding> — fixed in <sha> — re-verified by <evidence>
- (or) None needed.

### Blockers remaining (must resolve before /finish-branch)
1. <file:line> — <evidence> — <what was tried> — <what's needed from you>
- (or) None.

### Warnings (ship with a follow-up note)
- …

## Accounting ledger (RAN-CLEAN / FIXED(n) / UNFIXED / SKIPPED(reason) / NOT-TRIGGERED / MANDATORY-FAIL)
| Check | Status | Evidence / fixes / reason |
|-------|--------|---------------------------|
| Tests & build (Step 2)   | RAN-CLEAN / FIXED(n) / UNFIXED | exact command + result, fix SHAs |
| /review (Step 3)         | RAN-CLEAN / FIXED(n) / UNFIXED | N findings, fix SHAs, 2nd-run result, Codex passes on/off, base used, out-of-scope stash ref if any |
| /clean-code (Step 3)     | RAN-CLEAN / FIXED(n) / UNFIXED | KISS/DRY/SOLID/YAGNI findings, fix SHAs, deferred-with-reason |
| /defense (Step 4)        | RAN-CLEAN / FIXED(n) / UNFIXED | N findings, fix SHAs |
| /iac-scan (Step 4)       | … / NOT-TRIGGERED | infra/deploy files changed? |
| /pentest (Step 4)        | … / SKIPPED(reason) / NOT-TRIGGERED | authorized? findings? |
| /fuzz (Step 4)           | … / SKIPPED(reason) / NOT-TRIGGERED | target URL, findings |
| /cso (Step 4)            | … / NOT-TRIGGERED | new trust boundary? threat-model evidence |
| /db-optimize (Step 5)    | … / NOT-TRIGGERED | N+1 / index fixes, migration |
| /web-perf (Step 6)       | … / SKIPPED(reason) / NOT-TRIGGERED | before/after LCP/INP/CLS |
| /perf-profile (Step 6)   | … / SKIPPED(reason) / NOT-TRIGGERED | bottleneck, before/after |
| /qa (Step 7)             | … / SKIPPED(reason) / NOT-TRIGGERED | tier, health before/after, fix SHAs |
| /design-review (Step 8)  | … / SKIPPED(reason) / NOT-TRIGGERED | screens, fix SHAs |
| /a11y (Step 8)           | … / SKIPPED(reason) / NOT-TRIGGERED | static + dynamic, fix SHAs |
| /test-coverage + /playwright (Step 9) | RAN-CLEAN / FIXED(n) / UNFIXED | tests added, suite result |
| /humanize (Step 9b)      | … / SKIPPED(reason) / NOT-TRIGGERED | prose files in scope, flags fixed (SHAs), warnings carried |
| /eval (Step 9c)          | … / SKIPPED(reason: not authorized) / NOT-TRIGGERED | behavior files in scope, before/after metrics or the ask-first outcome |
| Final pass (Step 10)     | RAN-CLEAN / FIXED(n) / UNFIXED | fresh test/build + re-audit of fix commits |

> No row may be blank or "recommend" for a check whose trigger fired — that is an
> unaccounted-check blocker. `CLAUDE.md`-MANDATORY checks must read RAN-CLEAN or FIXED.

## Ask-first / follow-up commands
- `/code-review ultra` — (billed; offer when a high-stakes correctness concern remains)
- `/review` Codex passes — (OpenAI tokens; ask before enabling them for a run)
- `/pentest` — (if it was SKIPPED for authorization and the user now wants it)
- `/fuzz` — (if SKIPPED for lack of a target and one is now available)
- `/perf-profile` — (if SKIPPED for lack of a representative workload)
- `/finish-branch` → `/ship` — (only if VERDICT is SHIP-READY)

Print the verdict, the fixed count, the remaining-blocker count, and a 5-line summary to the chat.

Anti-patterns (do not do)

• Stopping at the report. A triggered check that found something and did not attempt a fix has not run /qa-full.
• Running /qa-only or /design-audit where /qa / /design-review are specified. Report-only is for discovery inside a step, never the step's end.
• Claiming a finding is fixed without re-running the check that found it and the test suite (fresh evidence, not assertion).
• Pushing, opening PRs, or merging — that's /finish-branch / /ship.
• Fixing outside the diff: refactoring untouched modules, bumping deps, or "while I'm here" changes. Every commit must trace to a finding.
• Landing a fix that itself breaks the bar — untested public surface, a duplicated helper, a symptom patch over an unknown root cause.
• Looping without bound. Two fix rounds per check, one final pass, then report what's left honestly.
• Launching a billed run (/code-review ultra, /review's Codex passes, /pentest's clearwing modes) or any scan without authorization, without the user's explicit yes.
• Declaring SHIP-READY while a check was skipped without saying which and why, or while any UNFIXED blocker remains.
• Running any sub-check against the whole repo instead of the diff.
• Treating MEDIUM/LOW findings as blockers (noise) or hiding CRITICAL/HIGH in the warnings list.

Related commands

Reuses the trigger matrix from /daily-qa (see skills/daily-qa/SKILL.md Step 7 for the canonical globs). Differences: branch-scoped, present-human, and it fixes and verifies instead of recommending.

Auto-run (diff-scoped; audit → fix → verify):

• Tests & build — always; failures root-caused via /debug, proven via /verify (Step 2).
• /review — staff-level correctness review; findings fixed by the pipeline (Step 3).
• /basic-review — in-tree correctness review, run in /review's place when gstack is unavailable (Step 3).
• /clean-code — KISS/DRY/SOLID/YAGNI refactors on the diff, test-verified (Step 3).
• /defense — OWASP/secrets/auth/crypto; findings fixed by the pipeline (Step 4).
• /iac-scan — when infra/deploy config changed; misconfigs fixed (Step 4).
• /fuzz — when the diff adds endpoints/input parsing and a target is reachable (Step 4).
• /cso — backstop when a new trust boundary reached the pipeline unmodeled (Step 4).
• /db-optimize — when DB/ORM/SQL changed; N+1/index fixes applied (Step 5).
• /web-perf — when frontend changed; dev server started if needed; regressions fixed (Step 6).
• /perf-profile — when hot server paths changed / pre-launch; bottleneck fixed (Step 6).
• /qa — when anything user-facing changed; full test → fix → re-verify loop (Step 7).
• /design-review — when UI changed; fixes + commits visual issues (Step 8).
• /a11y — static + dynamic pass when heavy UI changed; findings fixed (Step 8).
• /test-coverage + /playwright — write and apply the missing tests (Step 9).
• /tdd, /debug, /verify — the discipline every fix in the pipeline follows.

Ask-first (need the user's explicit yes):

• /code-review ultra — billed multi-agent cloud review.
• /review's Codex passes — OpenAI tokens; per-run yes required (Step 3).
• /pentest — authorization confirmation, then it runs; in-harness by default, clearwing modes are the billed ask-first option (Step 4).

Follow-up (outside the pipeline):

• /code-review / /simplify — Claude Code built-ins overlapping Step 3; use them by hand, the pipeline uses the in-tree /review + /clean-code.

Hand-off (only when SHIP-READY):

• /finish-branch — choose how to integrate the work.
• /ship — sync, bump VERSION, changelog, PR.