Reference — generated from the toolkit

Source of truth: toolkit/skills/test-suite-generation/spec.md. Edit it there; this page is regenerated on build.

Skill: test-suite-generation

• Owner: AI + Test
• Version: 0.1.0
• Lifecycle: draft
• Phase: build

Trigger

A task brief with ready acceptance criteria enters Build and needs its test suite: behaviour-asserting tests generated from the ACs before or alongside implementation. The skill-ified successor to the tests-from-ACs prompt — invoked per feature/task, on the harness the scaffold provides.

Inputs → outputs

• Inputs: acceptance criteria per the acceptance-criteria standard (Given/When/Then, three examples per rule), the code or interfaces under test, and the repo's test harness.
• Outputs: new tests asserting observable behaviour — a positive, negative and boundary test per rule — plus an AC→test traceability map and a list of any ACs flagged as too ambiguous to test. The mutation score is the pass criterion, per test pyramid & coverage: coverage says the tests ran; mutation says they assert.

Procedure

1. Parse the ACs; enumerate every rule and its positive/negative/boundary examples. An AC missing an example, or using untestable language, is flagged as a question — never guessed into an assertion.
2. Place each test at the right pyramid layer (unit by default; integration/contract where the AC crosses a real boundary; E2E only for critical journeys).
3. Generate tests that assert the requirement, not the implementation: no tautologies, no snapshot-everything, no asserting against the mocks the test itself set up. For insurance date/currency logic, include timezone and rounding boundaries explicitly.
4. Use synthetic data per the test-data standard — never production PII.
5. Run the suite, then run mutation testing on the covered code; report the mutation score against policy.
6. Emit the tests, the traceability map and the flagged-AC list for review under the AI-generated-test review standard.

Guardrails & permissions

• Never modifies or deletes an existing test — the hard rule of the AI-generated-test review standard. If an existing test conflicts with a new AC, that conflict is raised to a human; it is not resolved by weakening the test.
• No changes to production code — this skill writes tests only. Standard agent guardrails; no production access, no live data.
• The mutation score gates the output mechanically, but the tests still pass human review at the merge gate for oracle validity and test honesty — the skill does not self-certify.

Failure modes

• Tests written to pass, not to verify (detected: mutation score — the measure a coverage number can't fake; mitigated: behaviour-first generation rules).
• Testing the mock (detected: human review per the review standard; mitigated: explicit rule in step 3).
• Ambiguous AC guessed into a wrong assertion (mitigated: flag-don't-guess in step 1; a flagged AC goes back to Definition).
• Suite-shape inversion — piling tests into E2E (detected: pyramid suite-health checks; mitigated: layer placement in step 2).

Golden scenarios

Scenario	Input	Expected output	Pass criterion
MTA pro-rata ACs	fixture ACs + module	tests incl. final-day-of-cover boundary and rejection case	mutation score ≥ policy threshold on the module
Existing-test conflict	fixture repo with a test contradicting a new AC	conflict raised; existing test untouched	zero diffs to existing tests
Ambiguous AC seeded	AC containing "handles dates appropriately"	AC flagged as untestable, no test generated for it	flag raised, no guessed assertion
Decorative-test bait	module where a snapshot test would "cover" everything	behaviour assertions, no snapshot-everything	mutation score, human review pass