| name | edge-cases |
| description | Systematic edge case discovery, test coverage, and hardening for any feature or codebase area. Spawns parallel subagents to enumerate edge cases across eight categories, writes tests for each, runs them, and fixes unhandled cases. Use after implementation to ensure robustness before shipping. |
| argument-hint | <feature, file, or area to harden> |
Edge Cases
You are running a thorough edge case audit. Work through each phase in order. Do not skip phases.
Target: {{args}}
If {{args}} is empty, ask the user which feature, file, or area to harden before proceeding.
Phase 1: Catalog
Spawn 8 parallel subagents, one per category. Each enumerates every edge case it can find in the target area. Return a numbered list of cases with a one-line description and a risk rating (LOW / MEDIUM / HIGH / CRITICAL).
Category assignments
| Subagent | Category | What to look for |
|---|
| 1 | Boundary values | min/max, zero, one, empty, off-by-one, integer overflow/underflow, float precision |
| 2 | Null / missing / undefined | null inputs, undefined fields, missing keys, unset env vars, absent config |
| 3 | Invalid input types & formats | wrong type coercions, malformed strings, bad dates/times, invalid enums, unexpected encoding |
| 4 | Error states & exception paths | network failures, timeouts, partial writes, disk full, DB unavailable, external service 500s |
| 5 | Concurrency & ordering | race conditions, double-submit, out-of-order events, stale reads after writes, cache invalidation |
| 6 | Large / adversarial data | very large payloads, deeply nested objects, extremely long strings, binary/emoji/RTL in text fields, injection attempts |
| 7 | State machine violations | calling operations in wrong order, acting on deleted/expired/cancelled resources, re-entrancy |
| 8 | Auth & permission boundaries | unauthenticated access, cross-tenant data leakage, privilege escalation, token expiry mid-request |
Each subagent must read the relevant source files before enumerating: do not guess based on category alone.
Phase 2: Prioritize & Deduplicate
Consolidate all findings into a single master list:
- Deduplicate near-identical cases (keep the more specific one)
- Sort by risk × likelihood:
- P0: CRITICAL risk or near-certain to occur in production
- P1: HIGH risk, plausible in production
- P2: MEDIUM risk, possible but uncommon
- P3: LOW risk, theoretical
Present the prioritized list to the user and confirm before writing any tests. Note which cases are already handled and which are unhandled gaps.
Phase 3: Write Tests
For each unhandled P0 and P1 case (and any P2/P3 cases the user flags):
- Write a focused test that proves the edge case is handled correctly
- Follow the existing test patterns in the repo (read the test files first)
- Name each test so its failure message clearly identifies the edge case
- Group tests by category using describe blocks or equivalent
Rules:
- Tests must be runnable without manual setup
- Do not mock behavior that the real code exercises: only mock external I/O (network, DB, filesystem) if needed
- Each test should assert the correct outcome, not just that no exception is thrown
Run the tests immediately after writing them. A failing test is the goal for unhandled cases: it proves the gap is real.
Phase 4: Harden
For every test that fails (unhandled edge case confirmed):
- Identify the minimal code change needed to handle it correctly
- Implement the fix: no speculative hardening beyond what the failing test requires
- Re-run the test: it must pass before moving on
- Verify no existing tests regress after each fix
Do not batch fixes. Fix → test → fix → test. One at a time.
Phase 5: Full Test Run & Coverage Report
Run the full test suite using the project's configured test command (check package.json scripts or the test runner the repo already uses; e.g. bun test, bun run test, npm test, pnpm test, pytest, go test ./...):
bun test
All tests, original and new, must pass. If any pre-existing test is now failing, treat it as a regression and fix it before proceeding.
Summarize:
- How many edge cases were found (by category and priority)
- How many were already handled vs. newly hardened
- How many new tests were written
- Any P2/P3 cases intentionally deferred (with rationale)
Phase 6: Document Remaining Gaps
For any edge cases intentionally not handled (deferred P2/P3 or out-of-scope), create a brief tracking comment or TODO in the relevant source file:
// Edge case not handled: <description>. Risk: LOW. Deferred because: <reason>.
Do not write TODO comments for cases that are now handled: they just add noise.
Completion Checklist
