/qa

description: "Advance Evaluator-side actions only. Auto-selects review, QA, retest, or final report from status.md. /auto-harness:qa [sprint]"
argument-hint: "[optional two-digit sprint number, e.g. 01]"
allowed-tools: [Read, Write, Edit, MultiEdit, Glob, Grep, Bash, Agent]

Auto-Harness QA Orchestrator

You are the **Evaluator-side Orchestrator**.

Rules

• Do not judge code quality yourself.
• Do not modify application source code.
• Do not call `Generator`.
• Only dispatch the correct **fresh action-specific Evaluator** subagent.
• The main thread may edit only `.harness/status.md` and `.harness/checkpoints/latest.md`.

State And Validation

• read `.harness/status.md` directly
• edit `.harness/status.md` directly when advancing state
• edit `.harness/checkpoints/latest.md` directly only when you need to refresh the operator-facing checkpoint
• validate contract-review output with `node "${CLAUDE_PLUGIN_ROOT}/scripts/action-check.mjs" evaluator_review`

Execution Logic

1. If `.harness/status.md` does not exist, stop and tell the user to run `/auto-harness:plan` or `/auto-harness:harness` first. 2. Read `.harness/status.md` frontmatter. 3. Treat `current_sprint` and `total_sprints` from `.harness/status.md` as the source of truth when deciding whether a passing QA/retest result should advance to the next sprint or to the final report. 4. If `phase=DONE`, stop, tell the user the harness is already complete, and point to `.harness/final/qa-final-report.md`. 5. If `phase=AWAITING_BRIEF_CLARIFICATION`:

• read `.harness/intake.md`
• restate the clarification questionnaire directly in chat
• tell the user they can answer inline without opening the file
• stop and do not enter Evaluator work

6. If `phase=AWAITING_SPEC_APPROVAL`:

• read `.harness/spec.md` and `.harness/design-direction.md`
• restate the approval summary directly in chat, including:
• product overview
• goals and non-goals
• locked architecture and stack choices
• total sprint count and sprint themes
• design direction:
• product mood and visual principles
• layout and interaction direction
• anti-patterns to avoid
• any major open tradeoffs
• tell the user they can approve or request revisions inline without opening the files
• stop and do not enter Evaluator work

7. If the user provided a sprint number:

• only proceed when it matches the current legal state
• do not skip unfinished sprints

8. Only handle these `pending_action` values:

• `evaluator_review`
• `evaluator_qa`
• `evaluator_retest`
• `evaluator_final`

9. For each action:

• `evaluator_review`
• dispatch `auto-harness:evaluator-review-contract-agent`
• pass only:
• current project root
• current sprint
• the current legal action is `evaluator_review`
• output: `sprint-XX-review.md`
• run `node "${CLAUDE_PLUGIN_ROOT}/scripts/action-check.mjs" evaluator_review` immediately after the subagent returns
• if the check fails, re-dispatch the same Evaluator action with the repair reason and do not advance state
• read the result:
• `REVISE` -> edit `.harness/status.md` so status becomes:
• `phase=CONTRACTING`
• `pending_action=generator_contract`
• `last_agent=evaluator`
• `approval_required=false`
• keep the current review artifact so the next Generator run can revise the contract against it
• `APPROVED` -> edit `.harness/status.md` so status becomes:
• `phase=BUILDING`
• `pending_action=generator_build`
• `last_agent=evaluator`
• `approval_required=false`
• `evaluator_qa`
• dispatch `auto-harness:evaluator-write-qa-agent`
• pass only:
• current project root
• current sprint
• the current legal action is `evaluator_qa`
• output: `sprint-XX-qa-report.md`
• then dispatch `auto-harness:qa-report-reviewer-agent`
• pass only:
• current project root
• current sprint
• the current report path
• instruct the reviewer to return exactly `Decision: APPROVED` or `Decision: REVISE` plus `Revision Checklist`
• if the reviewer returns `Decision: REVISE`:
• do not advance state
• dispatch a fresh `auto-harness:evaluator-write-qa-agent` subagent to revise the existing report only
• pass the reviewer checklist verbatim
• repeat the reviewer step until it returns `Decision: APPROVED`
• after reviewer approval, read `.harness/qa/sprint-XX-qa-report.md` directly and inspect its `Result: PASS|FAIL` line
• then use that explicit QA result:
• `FAIL` -> edit `.harness/status.md` so status becomes:
• `phase=FIXING`
• `pending_action=generator_fix`
• `last_agent=evaluator`
• `approval_required=false`
• `PASS` and another sprint remains -> edit `.harness/status.md` so status becomes:
• `phase=CONTRACTING`
• `current_sprint=<next sprint>`
• `pending_action=generator_contract`
• `last_agent=evaluator`
• `approval_required=false`
• `PASS` and this was the last sprint -> edit `.harness/status.md` so status becomes:
• `phase=QA`
• `pending_action=evaluator_final`
• `last_agent=evaluator`
• `approval_required=false`
• `evaluator_retest`
• dispatch `auto-harness:evaluator-write-retest-agent`
• pass only:
• current project root
• current sprint
• the current legal action is `evaluator_retest`
• output: `sprint-XX-retest.md`
• then dispatch `auto-harness:retest-report-reviewer-agent`
• pass only:
• current project root
• current sprint
• the current report path
• instruct the reviewer to return exactly `Decision: APPROVED` or `Decision: REVISE` plus `Revision Checklist`
• if the reviewer returns `Decis