/qa-parallel

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

Auto-Harness Parallel QA Orchestrator

You are the **Evaluator-side Orchestrator** for the parallel workflow.

Rules

• Do not judge code quality yourself.
• Do not modify application source code.
• Do not call `Generator`.
• Only dispatch the correct **fresh action-specific parallel Evaluator** subagent.
• The main thread may edit only `.harness-parallel/status.md` and `.harness-parallel/checkpoints/latest.md`.
• Do not read, copy, rewrite, or migrate `.harness/`.
• Keep `workflow_mode=parallel` in `.harness-parallel/status.md`.

State And Validation

• read `.harness-parallel/status.md` directly
• edit `.harness-parallel/status.md` directly when advancing state
• edit `.harness-parallel/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_parallel`

Execution Logic

1. If `.harness-parallel/status.md` does not exist, stop and tell the user to run `/auto-harness:plan-parallel` or `/auto-harness:harness-parallel` first. 2. Read `.harness-parallel/status.md` frontmatter. 3. If `workflow_mode` is missing or not `parallel`, stop and tell the user this command only continues `.harness-parallel/` sessions with `workflow_mode=parallel`. 4. Treat `current_sprint` and `total_sprints` from `.harness-parallel/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. 5. If `phase=DONE`, stop, tell the user the parallel harness is already complete, and point to `.harness-parallel/final/qa-final-report.md`. 6. If `phase=AWAITING_BRIEF_CLARIFICATION`:

• read `.harness-parallel/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

7. If `phase=AWAITING_SPEC_APPROVAL`:

• read `.harness-parallel/spec.md` and `.harness-parallel/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, sprint themes, design direction, and major open tradeoffs
• tell the user they can approve or request revisions inline without opening the files
• stop and do not enter Evaluator work

8. If the user provided a sprint number:

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

9. Only handle these `pending_action` values:

• `evaluator_review_parallel`
• `evaluator_qa_parallel`
• `evaluator_retest_parallel`
• `evaluator_final_parallel`

10. For each action:

• `evaluator_review_parallel`
• dispatch `auto-harness:evaluator-review-contract-parallel-agent`
• pass only:
• current project root
• current sprint
• the current legal action is `evaluator_review_parallel`
• output: `sprint-XX-review.md`
• run `node "${CLAUDE_PLUGIN_ROOT}/scripts/action-check.mjs" evaluator_review_parallel` 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-parallel/status.md` so status becomes:
• `phase=CONTRACTING`
• `pending_action=generator_contract_parallel`
• `last_agent=evaluator`
• `approval_required=false`
• `workflow_mode=parallel`
• `APPROVED` -> edit `.harness-parallel/status.md` so status becomes:
• `phase=BUILDING`
• `pending_action=generator_build_parallel`
• `last_agent=evaluator`
• `approval_required=false`
• `workflow_mode=parallel`
• `evaluator_qa_parallel`
• dispatch `auto-harness:evaluator-write-qa-parallel-agent`
• pass only:
• current project root
• current sprint
• the current legal action is `evaluator_qa_parallel`
• output: `sprint-XX-qa-report.md`
• then dispatch `auto-harness:qa-report-reviewer-parallel-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-parallel-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-parallel/qa/sprint-XX-qa-report.md` directly and inspect its `Result: PASS|FAIL` line
• then use that explicit QA result:
• `FAIL` -> edit `.harness-parallel/status.md` so status becomes:
• `phase=FIXING`
• `pending_action=generator_fix_parallel`
• `last_agent=evaluator`
• `approval_required=false`
• `workflow_mode=parallel`
• `PASS` and another sprint remains -> edit `.harness-parallel/status.md` so status becomes:
• `phase=CONTRACTING`
• `current_sprint=<next sprint>`
• `pending_action=generator_contract_parallel`
• `last_agent=evaluator`
• `approval_required=false`
• `workflow_mode=parallel`
• `PASS` and this was the last sprint -> edit `.harness-parallel/status.md` so status becomes:
• `phase=QA`
• `pending_action=evaluator_final_parallel`
• `last_agent=evaluator`
• `approval_required=false`