Edge Case Finder
Given a function's spec or signature, enumerates boundary, empty, null, unicode, overflow, and concurrency cases and turns them into test cases.
What this skill does
Key features
- Enumerates edge cases by category: boundaries, empty, null, unicode, overflow
- Reasons about concurrency and ordering hazards where relevant
- Converts each identified case into a concrete, named test
- Explains why each case matters so the list is reviewable
Use cases
- Harden a function before it ships by finding untested inputs
- Expand a thin test suite that only covers the happy path
SKILL.md
The skill definition — its metadata and the exact instructions an agent follows. Copy it into a SKILL.md file in your agent's skills folder.
| name | edge-case-finder |
|---|---|
| description | Enumerate edge cases for a function from its spec or signature and turn each into a concrete named test case. |
| allowed-tools | Read, Grep, Write |
| output | edge-case list plus test stubs |
Musts
- Read the function’s signature and spec to understand each parameter’s type, range, and meaning.
- Enumerate cases across categories: boundaries, empty, null or missing, unicode and encoding, numeric overflow, and concurrency where state is shared.
- State briefly why each case matters, so a reviewer can accept or reject it.
- Turn each accepted case into a named test that asserts a specific expected outcome.
- Mark which tests assert current behavior versus which probe a suspected bug.
Guidelines
- For numeric inputs, include zero, negative, the max representable value, and just-past-boundary values.
- For strings, include empty, whitespace-only, very long, and multi-byte unicode inputs.
- For collections, include empty, single-element, and duplicate-element inputs.
- Flag concurrency hazards only when the function touches shared or external state.
- Do not invent requirements; when the spec is silent on a case, note the ambiguity rather than guessing.
Output format
## Edge cases for `split_bill(total, people)`
| Case | Category | Expected | Kind |
|-------------------------|-----------|-----------------------------|------------------|
| people = 0 | boundary | raises ValueError | current behavior |
| total = 0 | boundary | every share is 0 | current behavior |
| total not divisible | numeric | remainder handled, no loss | probes suspected |
| people is negative | boundary | raises ValueError | probes suspected |
def test_split_bill_zero_people_raises():
with pytest.raises(ValueError):
split_bill(100, 0)FAQ
Does it need the implementation or just the signature?
A signature and spec are enough to enumerate cases. Given the implementation too, it can also spot cases the code silently mishandles.
Will the generated tests pass?
Not necessarily — some are meant to expose gaps. It marks which cases assert current behavior versus which probe suspected bugs.
Before running any skill, read its instructions and the tools it's allowed to use, and test it on a safe target first. See LLM security best practices.