evaluator-write-qa

Stars13

Forks1

UpdatedApril 6, 2026 at 02:32

Internal Auto-Harness evaluator skill for sprint QA and QA report writing. Use only inside the Evaluator subagent during qa mode.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

redker56

redker56/auto-harness

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

File Explorer

8 files

SKILL.md

readonly

name	evaluator-write-qa
description	Internal Auto-Harness evaluator skill for sprint QA and QA report writing. Use only inside the Evaluator subagent during qa mode.
user-invocable	false

Evaluator Write QA

This skill governs Evaluator qa mode and the sprint QA report.

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

.harness/status.md
.harness/intake.md
.harness/spec.md
.harness/design-direction.md
.harness/runtime.md
.harness/contracts/sprint-XX-contract.md
.harness/contracts/sprint-XX-review.md when a review exists for the sprint.
.harness/qa/sprint-XX-self-check.md when Generator produced a self-check.
.harness/qa/sprint-XX-qa-report.md when rewriting the QA report.

Then inspect the current project implementation relevant to this action:

Read the source files, routes, components, services, tests, and config that implement the sprint you are validating.
Use running-app evidence first, and use the codebase to explain, verify, or localize what you observe.

Then read these skill references:

references/protocols/file-ownership.md
references/templates/qa-report.md
references/rubrics/default-grading.md
references/rubrics/product-depth.md
references/rubrics/bug-severity.md
references/rubrics/visual-design.md
references/rubrics/code-quality.md

Follow these rules:

Before issuing PASS or FAIL, complete the main end-to-end user flow promised by the current sprint contract against the running app.
If the target is a web application, use Playwright MCP and operate the UI like a real user by opening pages, clicking, typing, navigating, submitting forms, and observing visible results.
If the target is not a web application, use the most direct real-user interaction path available from the runtime contract and named tools.
If you cannot complete the main contracted user flow from the running app, do not pass on file inspection alone; record the verification gap and fail conservatively.
Use the QA report template exactly.
Score against the bundled grading rubric and hard-fail gates, not against Generator intent.
Use the rubric severity vocabulary, not ad hoc labels or alternate grading systems.
Include a Deduction Ledger that traces every actual deduction or hard-fail trigger used to derive the final scorecard.
Make the Scorecard derivable from the rubric baselines and the rows in Deduction Ledger.
For web applications, browser-action evidence should describe exactly what was clicked, entered, navigated, submitted, or visibly observed.
Always cite concrete evidence such as routes, browser actions, commands, visible UI text, network behavior, or source locations.
When a hard-fail gate triggers, cite the exact files, boundaries, or locked decisions that were violated.
Recompute the report from evidence when rewriting; do not patch formatting only.

More from this repository

same repository

evaluator-review-contract-parallel

redker56/auto-harness

Internal Auto-Harness evaluator skill for parallel sprint contract review before implementation. Use only inside the Evaluator subagent during review mode.

2026-05-0213

evaluator-write-final-parallel

redker56/auto-harness

Internal Auto-Harness evaluator skill for parallel final QA report aggregation. Use only inside the Evaluator subagent during evaluator_final_parallel.

2026-05-0213

evaluator-write-qa-parallel

redker56/auto-harness

Internal Auto-Harness evaluator skill for parallel sprint QA and QA report writing. Use only inside the Evaluator subagent during evaluator_qa_parallel.

2026-05-0213

evaluator-write-retest-parallel

redker56/auto-harness

Internal Auto-Harness evaluator skill for parallel sprint retest and retest report writing. Use only inside the Evaluator subagent during evaluator_retest_parallel.

2026-05-0213

generator-build-integrator

redker56/auto-harness

Internal Auto-Harness generator skill for worktree-merge build integration. Use only inside the parallel Generator integrator during build mode.

2026-05-0213

generator-build-worker

redker56/auto-harness

Internal Auto-Harness generator skill for one build dependency-graph node in a dedicated worktree.

2026-05-0213

Evaluator Write QA

This skill governs Evaluator qa mode and the sprint QA report.

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

.harness/status.md

.harness/intake.md

.harness/spec.md

.harness/design-direction.md

.harness/runtime.md

.harness/contracts/sprint-XX-contract.md

.harness/contracts/sprint-XX-review.md when a review exists for the sprint.

.harness/qa/sprint-XX-self-check.md when Generator produced a self-check.

.harness/qa/sprint-XX-qa-report.md when rewriting the QA report.

Then inspect the current project implementation relevant to this action:

Read the source files, routes, components, services, tests, and config that implement the sprint you are validating.

Use running-app evidence first, and use the codebase to explain, verify, or localize what you observe.

Then read these skill references:

references/protocols/file-ownership.md

references/templates/qa-report.md

references/rubrics/default-grading.md

references/rubrics/product-depth.md

references/rubrics/bug-severity.md

references/rubrics/visual-design.md

references/rubrics/code-quality.md

Follow these rules:

Before issuing PASS or FAIL, complete the main end-to-end user flow promised by the current sprint contract against the running app.

If the target is a web application, use Playwright MCP and operate the UI like a real user by opening pages, clicking, typing, navigating, submitting forms, and observing visible results.

If the target is not a web application, use the most direct real-user interaction path available from the runtime contract and named tools.

If you cannot complete the main contracted user flow from the running app, do not pass on file inspection alone; record the verification gap and fail conservatively.

Use the QA report template exactly.

Score against the bundled grading rubric and hard-fail gates, not against Generator intent.

Use the rubric severity vocabulary, not ad hoc labels or alternate grading systems.

Include a Deduction Ledger that traces every actual deduction or hard-fail trigger used to derive the final scorecard.

Make the Scorecard derivable from the rubric baselines and the rows in Deduction Ledger.

For web applications, browser-action evidence should describe exactly what was clicked, entered, navigated, submitted, or visibly observed.

Always cite concrete evidence such as routes, browser actions, commands, visible UI text, network behavior, or source locations.

When a hard-fail gate triggers, cite the exact files, boundaries, or locked decisions that were violated.

Recompute the report from evidence when rewriting; do not patch formatting only.