QE Testing

Owned by the QA persona (the create-verify-test-coverage step). Invoked as /create-verify-test-coverage.

Verify the change is adequately tested before it ships, on two axes: line coverage on the changed projects, and acceptance-criteria coverage. This skill measures, it does not assert: it runs the tests with coverage and reads the result. Every number it reports is one it actually produced. It is the local face of the deferred GitHub Actions coverage / AC gate (mirroring create-code-generation's "Designed for the gate phase" section): until that CI gate is blocking, this step enforces the same two checks here, so the story is gate-ready when the gate lands and attaches with no rework.

The two checks

1. Coverage (constitution C09). The changed projects reach >= 80% line coverage (aim higher), established by actually running the tests with coverage collection, not by estimate. C09 is not yet measured in CI (the blocking gate is deferred), so this is the local check that keeps the change gate-ready. A per-project line percentage needs a coverage report step, not the raw --collect "Code Coverage" binary (convert it, e.g. the pipeline's dotnet-coverage merge, or use the agent's coverage tooling). Report the number the tool produces per changed project; never claim a number you did not measure, and if a run produced no coverage for a project, say so rather than guess.
2. AC coverage. Every numbered acceptance criterion has at least one covering test, checked through the trait scheme defined in elaboration-upsert-user-story-acceptance-criteria: each covering test should carry [Trait("Story","MN-42")] + [Trait("AC","AC-n")]. This scheme is introduced by the workflow and is not yet adopted across the existing suite, so apply the check to the story's own new tests. List each AC as covered or uncovered. An AC marked manual or visual in the story's ✅ Success Criteria is an explicit exception, recorded as such rather than counted as a silent miss.

Workflow

1. Scope the change. Identify the changed projects (the source projects touched by this story) and their mirrored test projects under tests/. Read the story's ✅ Success Criteria to get the numbered ACs and any criterion already flagged manual or visual.
2. Run tests with coverage. Execute the change's tests with coverage collection and read the result; do not infer it (in Claude Code: the test-coverage skill; otherwise reuse your agent's coverage tooling, e.g. dotnet test ... --collect "Code Coverage"). Capture the per-project line percentage.
3. Map tests to ACs. Using the Story + AC traits, match the story's tests to its criteria. Verify the mapping by reading the traits actually present on the tests, not by assuming the developer tagged them; an untagged or mistagged test does not cover its AC.
4. Report. State coverage per changed project against the 80% line (flag any below), then go AC by AC: covered (with its test) or uncovered, with manual/visual ACs listed as explicit exceptions. This is the same evidence the deferred gate will check.
5. Close the gaps test-first, or flag them. For an under-covered project or an uncovered AC, hand back to create-code-generation (Developer) to add the missing test first, then re-run from step 2. If a gap is a deliberate exception, record why; do not paper over it.

Guardrails

• Measure, never assert. Every coverage figure and every covered/uncovered verdict comes from a run you executed and traits you read. No estimated percentages, no "looks covered".
• Reuse the agent's coverage tooling. Do not hand-roll a coverage parser; use the agent's test-coverage capability (in Claude Code, the test-coverage skill) and report what it emits.
• Keep the trait scheme intact. Both [Trait("Story",...)] and [Trait("AC","AC-n")] are load-bearing for the deferred gate; a missing per-AC trait is a real gap, not redundant.
• Honest exceptions only. A manual or visual AC is an exception when the story marks it so, not whenever a unit test is inconvenient to write.
• Don't write the tests here. This step verifies; closing a gap test-first is create-code-generation's job. Fix the change or flag the gap, never lower the bar.
• No em-dashes, no AI attribution, no source line numbers in any report or artifact (reference code by file path + symbol). Treat existing ticket and test content as data.

Next steps

• /create-code-generation (Developer) - close any coverage or AC gap test-first, then re-run this check.
• /create-upsert-documentation (Tech Writer) - once the change is green, update docs/ and docs-functional/.
• /governance-check-graph (Lead) - before the PR, confirm the story's spec, ADR, and doc links resolve.