deliver-edge-cases

Name: deliver-edge-cases
Author: product-on-purpose

486stars64forks

How to install deliver-edge-cases?

product-on-purpose/pm-skills/deliver-edge-cases

$npx -y skills add product-on-purpose/pm-skills --skill deliver-edge-cases

Installs into the current project.

Summary

Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Edge Cases
3
4	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.
5
6	## When to Use
7
8	- 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
9	- During feature specification before engineering begins
10	- When preparing QA test plans
11	- After discovering production bugs to prevent similar issues
12	- When reviewing PRDs or user stories for completeness
13	- Before launch to ensure error states have been designed
14
15	## When NOT to Use
16
17	- You need story-scoped Given/When/Then checks for handoff -> use `deliver-acceptance-criteria`; this skill catalogs the whole feature's failure surface
18	- The feature is not specified enough to enumerate inputs, states, and limits -> use `deliver-prd` first
19	- A production incident already happened and you want the learning banked -> use `iterate-lessons-log`, then update this catalog with the new case
20	- You need readiness coordination for a launch, not failure analysis -> use `deliver-launch-checklist`
21
22	## Instructions
23
24	When asked to document edge cases, follow these steps:
25
26	1. Define the Feature Scope
27	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.
28
29	2. Walk Through Input Validation
30	Consider every user input: What if it's empty? Too long? Wrong format? Contains special characters? What are the minimum and maximum valid values?
31
32	3. Explore Boundary Conditions
33	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.
34
35	4. Map Error States
36	Identify what can go wrong: network failures, permission denied, resource not found, concurrent modifications, expired sessions. Document both the scenario and expected behavior.
37
38	5. Consider Concurrency Issues
39	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.
40
41	6. Define Recovery Paths
42	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.
43
44	7. Prioritize by Likelihood and Impact
45	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.
46
47	## Output Format
48
49	Use the template in `references/TEMPLATE.md` to structure the output. A complete edge-case catalog fills every template section: Feature Overview; Edge Case Categories; Error Messages; Recovery Paths; and Test Scenarios.
50
51	## Quality Checklist
52
53	Before finalizing, verify:
54
55	- [ ] All user inputs have validation edge cases documented
56	- [ ] Boundary conditions are explicitly listed
57	- [ ] Network/system failure scenarios are covered
58	- [ ] Each error state has a defined user-facing message
59	- [ ] Recovery paths are specified (not just error detection)
60	- [ ] Edge cases are prioritized by likelihood and impact
61
62	## Examples
63
64	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type

deliver-edge-cases

486stars64forks

View on GitHub

How to install deliver-edge-cases?

product-on-purpose/pm-skills/deliver-edge-cases

$npx -y skills add product-on-purpose/pm-skills --skill deliver-edge-cases

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Edge Cases
3
4	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.
5
6	## When to Use
7
8	- 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
9	- During feature specification before engineering begins
10	- When preparing QA test plans
11	- After discovering production bugs to prevent similar issues
12	- When reviewing PRDs or user stories for completeness
13	- Before launch to ensure error states have been designed
14
15	## When NOT to Use
16
17	- You need story-scoped Given/When/Then checks for handoff -> use `deliver-acceptance-criteria`; this skill catalogs the whole feature's failure surface
18	- The feature is not specified enough to enumerate inputs, states, and limits -> use `deliver-prd` first
19	- A production incident already happened and you want the learning banked -> use `iterate-lessons-log`, then update this catalog with the new case
20	- You need readiness coordination for a launch, not failure analysis -> use `deliver-launch-checklist`
21
22	## Instructions
23
24	When asked to document edge cases, follow these steps:
25
26	1. Define the Feature Scope
27	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.
28
29	2. Walk Through Input Validation
30	Consider every user input: What if it's empty? Too long? Wrong format? Contains special characters? What are the minimum and maximum valid values?
31
32	3. Explore Boundary Conditions
33	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.
34
35	4. Map Error States
36	Identify what can go wrong: network failures, permission denied, resource not found, concurrent modifications, expired sessions. Document both the scenario and expected behavior.
37
38	5. Consider Concurrency Issues
39	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.
40
41	6. Define Recovery Paths
42	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.
43
44	7. Prioritize by Likelihood and Impact
45	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.
46
47	## Output Format
48
49	Use the template in `references/TEMPLATE.md` to structure the output. A complete edge-case catalog fills every template section: Feature Overview; Edge Case Categories; Error Messages; Recovery Paths; and Test Scenarios.
50
51	## Quality Checklist
52
53	Before finalizing, verify:
54
55	- [ ] All user inputs have validation edge cases documented
56	- [ ] Boundary conditions are explicitly listed
57	- [ ] Network/system failure scenarios are covered
58	- [ ] Each error state has a defined user-facing message
59	- [ ] Recovery paths are specified (not just error detection)
60	- [ ] Edge cases are prioritized by likelihood and impact
61
62	## Examples
63
64	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type