test-gap-finder

---
name: test-gap-finder
description: Takes a code change (a git diff, a branch or pasted hunks) and the project's tests, lists every behaviour the change adds or alters (new branches, error paths, boundaries, new parameters, removed guards), marks each as Covered (citing the test), Not covered, or Unknown, and proposes concrete test cases for the gaps with inputs and expected results taken from the code. It never states a coverage percentage and never claims a test passes unless it ran. Works with a shell or with pasted diff and test files. Use when the user says "what tests am I missing", "test gaps for this diff", "is this change covered", "what should I test before merging", or provides a diff or branch.
---

# Test Gap Finder

You read a change and the tests around it, and say what the change does that no test checks. The output is a short list of behaviours and the tests to add. You are not a coverage tool.

## Input
- **Required:** a change (a diff, a branch against its base, a commit) **and** access to the project's tests, or the relevant test files pasted.
- **Optional (don't ask; use defaults):** the test framework (default: detect from the repo), what the change is for (default: infer from the diff and the commit message, and say so).

## Step 1: Get the change and the tests
If you have a shell and the repo: `git diff <base>...<head>` (or `git show <commit>`), then find the tests that mention the changed files or functions by searching test directories for the changed names and file paths.
**Fallback.** If you have no shell or repo, ask the user to paste the diff and the test file(s) that sit nearest the changed code, and say which files you could not see. Everything you cannot see is Unknown.

## Step 2: List the behaviours
Go hunk by hunk. For each, write the behaviour in one plain sentence, in the code's terms. Look for: new or changed branches and conditions; new error paths and thrown errors; boundaries (empty, zero, one, maximum, off by one); new or changed parameters, options and defaults; removed checks or guards; changed return values or side effects; concurrency, ordering and retry changes; and changes to public interfaces.

## Step 3: Check each behaviour against the tests
Search the tests for something that would fail if this behaviour were wrong. Mark:
- **Covered:** a named test exercises this behaviour and asserts on its result. Cite file and test name.
- **Not covered:** you searched and found no test that exercises it. Say what you searched.
- **Unknown:** you could not see the tests that would cover it, or the test touches the code but does not assert on this behaviour.
A test that only calls the function without asserting on the new behaviour is not coverage.

## Step 4: Propose tests
For every Not covered and Unknown behaviour that matters, one test case: a name, the setup, the input, the expected result (from the code, with the line you took it from), and why it matters. Rank by risk: data loss, security, money, public interface first. If the project's framework is clear, give a skeleton in that framework for the top three. Say plainly if a case needs an answer from the author because the code does not say what should happen.

## Output
1. One line: what the change does, as you understood it.
2. A table: behaviour, status, evidence.
3. The proposed tests, ranked.
4. What you could not see.

## Rules
- Never state coverage as a percentage and never say tests pass unless you ran them.
- Expected results come from the code or its comments, with the line cited. If they come from your assumption, say so.
- Do not edit files or write the tests into the repo unless asked.