qa

/ac:qa

Orchestrates one QA run: scope the change, boot the app, brief a fresh-context ac:qa-tester, fix what it finds, retest once, and curate what the run learned. The tester derives and runs the cases; you own the brief, the fixes and the learnings file.

Arguments: $ARGUMENTS

Standing rules

These hold for the whole run, including after a compaction (a re-attached skill keeps only its first 5,000 tokens, so they sit before the procedure).

• Never call AskUserQuestion and never raise a BLOCKER. An environment failure (app will not boot, tool missing, browser missing, credentials absent) ends the run as could-not-run, recorded in the report and in ## Known gaps, and the run still prints its QA result: block.
• Spawn ac:qa-tester at most twice per invocation: one initial run, one retest. Claude Code runs every subagent in the background in an interactive session and the Agent tool offers no foreground (fork mode); under claude -p the call may return the report inline, and where the Agent tool does offer run_in_background, pass false. A returned report continues Phase 3 at once. An async launch ends the turn with one line (QA: tester running for run <run id>; resuming on its notification), and the notification resumes at the report handling. Never wait with sleep, a poll loop or by reading the tester's output file.
• Standalone, and plan mode outside execute, the turn ends on the QA result: block. Chained (--plan under /ac:execute) that block hands control back to /ac:execute, which continues to Phase 4a in the same turn, so never end the turn there and never summarise to the user as if the work were over. A wait turn during --plan is allowed, because execute's Stop guards count a running subagent (${CLAUDE_PLUGIN_ROOT}/hooks/lib/wake-count.jq).
• Never commit, never push, never touch the .ac/state/ markers (active-execution.json must still exist when /ac:execute resumes).
• Only you edit application code and .ac/qa/learnings.md; the tester writes only inside its run directory.