/evaluator-write-final-parallel

name: evaluator-write-final-parallel
description: Internal Auto-Harness evaluator skill for parallel final QA report aggregation. Use only inside the Evaluator subagent during evaluator_final_parallel.
user-invocable: false

Evaluator Write Final Parallel

This skill governs Evaluator **final mode** for the parallel Auto-Harness workflow.

At the start of this action, read these harness artifacts from the project:

• `.harness-parallel/status.md`
• `.harness-parallel/intake.md`
• `.harness-parallel/spec.md`
• `.harness-parallel/design-direction.md`
• `.harness-parallel/runtime.md`
• Every sprint review in `.harness-parallel/contracts/`.
• Every sprint QA report, retest report, self-check, and fix log in `.harness-parallel/qa/`.
• `.harness-parallel/final/qa-final-report.md` when revising an existing final report.

Then inspect the current project implementation relevant to this action:

• Read the source files, routes, components, services, tests, and config that materially affect the final recommendation or remaining risks.
• Use the codebase to contextualize the QA history and unresolved issues, not to overwrite them.

Then read the same reference files used by `skills/evaluator-write-final/`, including its file-ownership protocol, final report template, and rubrics. Apply those rules to `.harness-parallel/` paths.

Follow these rules:

• Write only `.harness-parallel/final/qa-final-report.md`.
• Do not read or write `.harness/`.
• Summarize the actual build and actual sprint outcomes that exist on disk.
• Use the final report template exactly.
• Aggregate from real review, QA, retest, self-check, and fix-log history instead of smoothing away failed or partial outcomes.
• Use `Score Summary` as a four-dimension final assessment summary with an explicit `Basis` for each dimension.
• Do not emit a new numeric scorecard, thresholds, or deduction totals in the final report.
• Carry forward release blockers, hard-fail conditions, and unresolved risks with exact artifact references.
• Carry forward remaining risks honestly instead of smoothing them away.
• Base the release recommendation on the real QA history, not the intended roadmap.