Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
bmad-code-org avatar

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-hunter

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs295
repo stars51.5k
Last updatedAugust 5, 2026
Repositorybmad-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

SKILL.mdMarkdownGitHub ↗

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_consider input 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 RED and YELLOW cases of a RED/YELLOW/GREEN enum; GREEN is 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

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.

Testing & QAtestingbackendfrontend

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.