test-gap-fill

Purpose

Shared policy: Follow instructions/coordination.instructions.md for precedence, invocation, delegation, and handoffs. Apply instructions/workflow.instructions.md for proportional work and verification.

You are filling approved test gaps with concrete, runnable tests.

Your goals are to:

• Confirm approval — generate only the gaps the user explicitly approved.
• Generate tests — add or improve tests that follow the project's framework, naming, fixtures, and assertion style.
• Verify behavior — run the generated tests and report pass/fail results.
• Surface bugs — clearly identify any real bug exposed by a generated test before touching production code.

---

When to use this skill

Use this skill whenever:

• test-gap-audit has produced a gap report and the user approved specific gaps to fill.
• The user provides an explicit list of existing coverage gaps and asks for tests to be generated.
• A production incident has an approved "what test would have caught this?" follow-up.
• You are continuing the chain: test-gap-audit → approval → test-gap-fill.

Do not use this skill for:

• Read-only coverage discovery — use test-gap-audit.
• Planning tests for new features — use test-strategy instead.
• Refactoring production code or test architecture before test generation — recommend refactor if structural cleanup is needed.
• Code review — use git-commit-review or code-reviewer agent.

---

Workflow

Phase 1: Approval Gate

Approval gate: stop until the user explicitly approves which tests to generate (all critical, critical + high, selected items, or report only).

Do not generate or edit tests until the approved gap list is clear. If the user only provides a gap report without selecting items, ask them to choose the gaps to fill.

Phase 2: Test Generation

For each gap the user approves:

1. Write the test — full arrange-act-assert structure, following the project's test conventions.
   • Arrange — build inputs, fixtures, mocks, database state, or object graphs using existing project patterns.
   • Act — execute the method, endpoint, handler, or behavior under test once.
   • Assert — verify the externally observable result, state change, emitted message, or error condition.
2. Use existing fixtures — reuse test builders, factories, or fixtures already in the project.
3. Name clearly — test name describes the scenario: {Method}_When{Condition}_Should{Expected}.
4. Add comments for context — briefly explain why this test exists (what gap it fills).
5. Run the test — verify it passes (for existing correct behavior) or fails (if it's exposing a bug).