Skill: test-generator

When to activate

• An approved spec exists at specs/<feature>/spec.md
• Implementation hasn't started (or is just starting)
• The user explicitly asks for tests generated from a spec

Why run this before implementation

The skill is designed for tests-first: tests derived from the spec represent the external contract the implementation must honor. Implementing first blurs the criterion.

Playbook

1. Load the spec

Read specs/<feature>/spec.md, especially:

• The "Use cases" section
• The "Acceptance criteria" section
• The "Out of scope" section (to generate negative tests where applicable)
• The "Security considerations" section (abuse cases → tests proving the abuse fails)

2. Load the test stack

Check AGENTS.md or package.json / pyproject.toml to identify the test framework in use. Do not introduce a new framework.

3. Map criterion → test

For each acceptance criterion, generate one or more tests:

• Happy path test (the scenario described in the main use case)
• Alternative path test (variations mentioned in the spec)
• Error test (violated preconditions, invalid inputs)
• Edge case test (numeric limits, empty strings, empty lists)
• Abuse case test (from Security considerations: the test performs the abuse — wrong user, tampered ID, expired token — and asserts it is denied; these prove what must NOT happen)

4. Test file structure

# Suggested layout (adapt to the framework):

describe/feature("<Feature name>")
  describe/context("Criterion 1: <criterion text>")
    test/it("given X when Y then Z")
    test/it("edge: ...")
  describe/context("Criterion 2: ...")
    ...

5. Confirm coverage

Before finishing, produce a traceability table:

If a criterion has no matching test → report the gap to the user.

Principles

• Each test proves one criterion. Don't bundle multiple criteria in one test.
• Readable names. Test names become executable documentation.
• No production code. This skill produces tests that will fail until the implementation happens (red-green-refactor).
• No excessive mocks. Mock only what is outside the scope of the test; code under test should actually run.

Expected output

One or more test files in the project's conventional location (tests/, __tests__/, etc.) + a traceability report.

Expected status of the tests at the end: red (failing) — because the implementation doesn't exist yet. That's the point.