name: deliver-edge-cases
description: Documents edge cases, error states, boundary conditions, and recovery paths for a feature. Use during specification to ensure comprehensive coverage, or during QA planning to identify test scenarios.
phase: deliver
version: "2.0.0"
updated: 2026-01-26
license: Apache-2.0
metadata:
category: specification
frameworks: [triple-diamond, lean-startup, design-thinking]
author: product-on-purpose
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
- 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
Instructions
When asked to document edge cases, follow these steps:
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.
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?
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.
Map Error States
Identify what can go wrong: network failures, permission denied, resource not found, concurrent modifications, expired sessions. Document both the scenario and expected behavior.
Consider Concurrency Issues
What if two users act simultaneously? What if the user double-clicks? What if data changes between load and save? Race conditions often cause subtle bugs.
Define Recovery Paths
For each error, specify how users recover. What message do they see? Can they retry? Is data preserved? Good error handling turns frustration into confidence.
Prioritize by Likelihood and Impact
Not all edge cases need the same attention. High-likelihood + high-impact cases need robust handling; rare + low-impact cases might just need graceful failure.
Output Format
Use the template in references/TEMPLATE.md to structure the output.
Quality Checklist
Before finalizing, verify:
Examples
See references/EXAMPLE.md for a completed example.
1---2name: deliver-edge-cases3description: <!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->4---5
6<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
7---
8name: deliver-edge-cases
9description: Documents edge cases, error states, boundary conditions, and recovery paths for a feature. Use during specification to ensure comprehensive coverage, or during QA planning to identify test scenarios.
10phase: deliver
11version: "2.0.0"
12updated: 2026-01-26
13license: Apache-2.0
14metadata:
15 category: specification
16 frameworks: [triple-diamond, lean-startup, design-thinking]
17 author: product-on-purpose
18---
19# Edge Cases
20
21An 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.
22
23## When to Use
24
25- During feature specification before engineering begins
26- When preparing QA test plans
27- After discovering production bugs to prevent similar issues
28- When reviewing PRDs or user stories for completeness
29- Before launch to ensure error states have been designed
30
31## Instructions
32
33When asked to document edge cases, follow these steps:
34
351. **Define the Feature Scope**
36 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.
37
382. **Walk Through Input Validation**
39 Consider every user input: What if it's empty? Too long? Wrong format? Contains special characters? What are the minimum and maximum valid values?
40
413. **Explore Boundary Conditions**
42 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.
43
444. **Map Error States**
45 Identify what can go wrong: network failures, permission denied, resource not found, concurrent modifications, expired sessions. Document both the scenario and expected behavior.
46
475. **Consider Concurrency Issues**
48 What if two users act simultaneously? What if the user double-clicks? What if data changes between load and save? Race conditions often cause subtle bugs.
49
506. **Define Recovery Paths**
51 For each error, specify how users recover. What message do they see? Can they retry? Is data preserved? Good error handling turns frustration into confidence.
52
537. **Prioritize by Likelihood and Impact**
54 Not all edge cases need the same attention. High-likelihood + high-impact cases need robust handling; rare + low-impact cases might just need graceful failure.
55
56## Output Format
57
58Use the template in `references/TEMPLATE.md` to structure the output.
59
60## Quality Checklist
61
62Before finalizing, verify:
63
64- [ ] All user inputs have validation edge cases documented
65- [ ] Boundary conditions are explicitly listed
66- [ ] Network/system failure scenarios are covered
67- [ ] Each error state has a defined user-facing message
68- [ ] Recovery paths are specified (not just error detection)
69- [ ] Edge cases are prioritized by likelihood and impact
70
71## Examples
72
73See `references/EXAMPLE.md` for a completed example.
majiayu000