deliver-edge-cases

Edge Cases

An edge cases document systematically catalogs the unusual, boundary, and error scenarios for a feature. While happy-path flows are typically well-specified, edge cases often get discovered in production - causing bugs, poor user experience, and support burden. Documenting edge cases upfront ensures engineering handles them intentionally and QA knows what to test.

When to Use

• When you need to enumerate failure modes, race conditions, timeouts, and boundary or limit scenarios - everything that can go wrong - and define a recovery path for each
• During feature specification before engineering begins
• When preparing QA test plans
• After discovering production bugs to prevent similar issues
• When reviewing PRDs or user stories for completeness
• Before launch to ensure error states have been designed

When NOT to Use

• You need story-scoped Given/When/Then checks for handoff -> use deliver-acceptance-criteria; this skill catalogs the whole feature's failure surface
• The feature is not specified enough to enumerate inputs, states, and limits -> use deliver-prd first
• A production incident already happened and you want the learning banked -> use retro, then update this catalog with the new case
• You need readiness coordination for a launch, not failure analysis -> use shipping-and-launch

Instructions

When asked to document edge cases, follow these steps:

1. Define the Feature Scope Clearly describe what feature or flow you're analyzing. Edge cases are specific to context - the same input might be valid in one feature and invalid in another.

2. Walk Through Input Validation Consider every user input: What if it's empty? Too long? Wrong format? Contains special characters? What are the minimum and maximum valid values?

3. Explore Boundary Conditions Find the edges of acceptable ranges. If a field accepts 1-100, test 0, 1, 100, and 101. Consider pagination boundaries, timeout thresholds, and rate limits.