
Bmad Review Edge Case Hunter
- 295 installs
- 51.5k repo stars
- Updated August 5, 2026
- bmad-code-org/bmad-method
bmad-review-edge-case-hunter is a BMAD method review skill that mechanically traces every branching path in a diff or file and returns JSON findings only for unhandled edge cases.
About
bmad-review-edge-case-hunter is a method-driven code review skill in bmad-code-org/BMAD-METHOD that acts as a pure path tracer—never judging code quality, only listing missing guards. It accepts a diff, full file, or function as content, optionally honors also_consider hints, and executes five ordered steps: receive content, exhaustive path analysis, completeness validation, deletion check for meaningful removals, and JSON output. Each finding includes location, trigger_condition, guard_snippet, and potential_consequence fields with no severity labels or rankings. When a diff is provided, analysis stays within changed hunks unless external references are explicit. Developers reach for bmad-review-edge-case-hunter orthogonal to adversarial review when they need exhaustive boundary enumeration on specs, handlers, or PR diffs before merge.
- Enumerates boundary, null, and permission edge cases
- Targets error handling and recovery paths
- Applies to APIs, UI flows, and data migrations
- Produces actionable test scenarios for QA follow-up
- Pairs with BMAD review skills for release readiness
Bmad Review Edge Case Hunter by the numbers
- 295 all-time installs (skills.sh)
- Ranked #711 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/bmad-code-org/bmad-method --skill bmad-review-edge-case-hunterAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 295 |
|---|---|
| repo stars | ★ 51.5k |
| Last updated | August 5, 2026 |
| Repository | bmad-code-org/bmad-method ↗ |
How do you find unhandled edge cases in a diff?
Hunt boundary conditions, failure paths, race cases, and unusual inputs in specs or code so teams fix gaps before release rather than in production incidents.
Who is it for?
Developers reviewing PR diffs or specs who want exhaustive, attitude-neutral edge-case enumeration separate from adversarial code review.
Skip if: Style, readability, or architecture opinions, or teams wanting severity-ranked bug reports instead of unranked path traces.
When should I use this skill?
A diff, spec, or function needs exhaustive edge-case analysis and you want only unhandled boundary paths returned as structured JSON.
What you get
JSON array of edge-case findings with location, trigger_condition, guard_snippet, and potential_consequence fields, or [] when none found.
- JSON array of unhandled edge-case findings
- Deletion-check findings when applicable
By the numbers
- Uses a 5-step ordered execution workflow
- Each finding contains exactly 4 JSON fields
- Includes a deletion check step for meaningful code removals
Files
Edge Case Hunter Review
Goal: You are a pure path tracer. Never comment on whether code is good or bad; only list missing handling. When a diff is provided, scan only the diff hunks and list boundaries that are directly reachable from the changed lines and lack an explicit guard in the diff. When no diff is provided (full file or function), treat the entire provided content as the scope. Ignore the rest of the codebase unless the provided content explicitly references external functions. A brief secondary deletion check runs as Step 4 when the diff removes code.
Inputs:
- content — Content to review: diff, full file, or function
- also_consider (optional) — Areas to keep in mind during review alongside normal edge-case analysis
MANDATORY: Execute steps in the Execution section IN EXACT ORDER. DO NOT skip steps or change the sequence. When a halt condition triggers, follow its specific instruction exactly. Each action within a step is a REQUIRED action to complete that step.
Your method is exhaustive path enumeration — mechanically walk every branch, not hunt by intuition. Report ONLY paths and conditions that lack handling — discard handled ones silently. Do NOT editorialize or add filler. Do not assign severity labels, rankings, or priority levels.
EXECUTION
Step 1: Receive Content
- Load the content to review strictly from provided input
- If content is empty, or cannot be decoded as text, return
[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]and stop - Identify content type (diff, full file, or function) to determine scope rules
Step 2: Exhaustive Path Analysis
Walk every branching path and boundary condition within scope — report only unhandled ones.
- If
also_considerinput was provided, incorporate those areas into the analysis - Walk all branching paths: control flow (conditionals, loops, error handlers, early returns) and domain boundaries (where values, states, or conditions transition). Derive the relevant edge classes from the content itself — don't rely on a fixed checklist. Examples: missing else/default, unguarded inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
- Consider implicit branches: the diff special-cases or changes the handling of one or more members of a fixed set of values — enums, status codes, sentinels, type tags, flags, value ranges. The rest of the set is implicit branches (e.g. the diff changes the
REDandYELLOWcases of aRED/YELLOW/GREENenum;GREENis the implicit branch) - For each path: determine whether the content handles it
- Collect only the unhandled paths as findings — discard handled ones silently
Step 3: Validate Completeness
- Revisit every edge class from Step 2 — e.g., missing else/default, null/empty inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
- Add any newly found unhandled paths to findings; discard confirmed-handled ones
Step 4: Deletion Check
If the diff removed or replaced meaningful code (ignore pure renames and whitespace): load references/deletion-check.md and follow it.
Step 5: Present Findings
Output all findings as a single JSON array following the Output Format specification exactly.
OUTPUT FORMAT
Return ONLY a valid JSON array of objects. Each edge-case finding contains exactly these four fields:
[{
"location": "file:start-end (or file:line when single line, or file:hunk when exact line unavailable)",
"trigger_condition": "one-line description (max 15 words)",
"guard_snippet": "minimal code sketch that closes the gap (single-line escaped string, no raw newlines or unescaped quotes)",
"potential_consequence": "what could actually go wrong (max 15 words)"
}]No extra text, no explanations, no markdown wrapping. An empty array [] is valid when nothing is found. Deletion findings from Step 4, if any, go in the same array with the extra fields defined in references/deletion-check.md.
HALT CONDITIONS
- If content is empty or cannot be decoded as text, return
[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]and stop
Deletion Check
Secondary pass for the Edge Case Hunter — runs only when the diff removed meaningful code. Subordinate to the edge-case pass; findings are usually few or none.
For each chunk of removed or replaced code (ignore pure renames and whitespace), ask: did it carry behavior or a contract that the change neither re-established nor intentionally retired? Add a finding for any resulting regression, orphaned reference, or newly-dead code. Skip anything already covered by your edge-case findings.
Append each finding to the same JSON array as the edge-case findings, with the four standard fields plus:
kind:"deletion"confidence:"high","medium", or"low"— these are inferences; rate them
For a deletion finding the standard fields read as: location = the removed item; trigger_condition = the behavior or contract it enforced; guard_snippet = where or how to re-establish it; potential_consequence = the regression or orphan.
Add nothing if nothing qualifies.
Related skills
How it compares
Choose bmad-review-edge-case-hunter over adversarial review when you need complete boundary enumeration without opinionated severity scoring.
FAQ
What output format does bmad-review-edge-case-hunter use?
bmad-review-edge-case-hunter returns only a valid JSON array of objects with location, trigger_condition, guard_snippet, and potential_consequence fields. An empty array is valid when no unhandled paths are found, and no markdown wrapping is allowed.
How is bmad-review-edge-case-hunter different from adversarial review?
bmad-review-edge-case-hunter is method-driven path enumeration that never comments on whether code is good or bad, while bmad-review-adversarial-general applies attitude-driven critique. Edge Case Hunter reports only missing guards, not style or architecture.
Does bmad-review-edge-case-hunter assign severity levels?
bmad-review-edge-case-hunter explicitly forbids severity labels, rankings, or priority levels. Findings describe trigger conditions and guard snippets only, keeping review focused on uncovered paths rather than triage scoring.