Edge case coverage

Skill viktorbezdek/skillstack/edge-case-coverage/skills/edge-case-coverage

Skills I use and develop to deliver better outcomes faster and with less effort.

Install

npx -y skills add viktorbezdek/skillstack --skill edge-case-coverage

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

10 stars10 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Identify and document boundary conditions, corner cases, error scenarios, and validation requirements that implementations must handle. Use when the user asks to find edge cases, identify corner cases, specify validation rules, enumerate error scenarios, harden a function against bad inputs, or think through what can go wrong at the boundaries of a system. NOT for writing the actual tests (use testing-framework or test-driven-development). NOT for structured risk registers around project-level risks (use risk-management). NOT for security vulnerability scanning (use code-review).

SKILL.md

4.2 KB, as published. Nobody here has run it

Edge Case Coverage

Systematically identify and handle boundary conditions.

Decision Tree: Which Edge Case Category?

What kind of edge case are you looking for?
├─ Input validation? → Check null, wrong type, empty, overflow, malformed
├─ Boundary values? → Check 0, 1, min, max, just-above, just-below
├─ State transitions? → Check uninitialized, concurrent, stale, partial
├─ Resource limits? → Check timeout, OOM, disk full, connection pool exhaustion
├─ Network failures? → Check offline, slow, partial failure, retry exhaustion
├─ Permission issues? → Check unauthorized, expired, revoked, insufficient scope
└─ Multi-system interaction? → Check race conditions, ordering, idempotency

Edge Case Categories

Category	Examples	Detection Heuristic
Boundary	0, 1, max, min, empty	Any numeric or size parameter
Input	null, undefined, wrong type	Any external-facing function
State	uninitialized, concurrent, stale	Any stateful operation
Resource	timeout, no memory, disk full	Any I/O or long-running operation
Network	offline, slow, partial failure	Any remote call
Permission	unauthorized, expired, revoked	Any auth-gated operation

Boundary Analysis

Numeric Boundaries

Value: age
├── Below min: -1
├── At min: 0
├── Just above min: 1
├── Normal: 25
├── Just below max: 119
├── At max: 120
└── Above max: 121

String Boundaries

Value: username
├── Empty: ""
├── Single char: "a"
├── Max length: "a" * 255
├── Over max: "a" * 256
├── Special chars: "user@#$"
└── Unicode: "user"

Error Scenario Template

## Scenario: [Name]

**Trigger**: [What causes it]
**Symptoms**: [What user sees]
**Root cause**: [Why it happens]
**Prevention**: [How to avoid]
**Recovery**: [How to fix]

Validation Checklist

Input Validation

State Validation

Coverage Matrix

Input	Valid	Empty	Null	Overflow	Malformed
Name	[x]	[x]	[x]	[x]	[x]
Email	[x]	[x]	[x]	[x]	[x]
Age	[x]	[x]	[x]	[x]	[x]

Anti-Patterns

Happy path only — designing and testing only the expected flow; every production failure starts as an edge case someone assumed would not happen
Ignoring nulls — null is the most common edge case in production; always handle explicitly
Assuming valid input — external input is never trustworthy; validate at the boundary
Missing timeout handling — every network or I/O operation must have a timeout; without one, the system hangs indefinitely
Silent failures — swallowing errors without logging or surfacing hides bugs until they cascade
Testing only one layer — edge cases at the integration boundary (API + DB, UI + API) are the most common production failures
Forgetting idempotency — retries on failed operations cause duplicates if endpoints are not idempotent

When to Use

Before implementing a feature — identify edge cases in the spec
During code review — check for unhandled boundaries
When hardening an existing system — systematic enumeration of failure modes
When writing error handling — ensure all categories are covered

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.