# Deliver Edge Cases

Documents edge cases, error states, boundary conditions, race conditions, and recovery...

- Repository: https://github.com/product-on-purpose/pm-skills (780 stars)
- Category: Design
- License: Apache-2.0
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add product-on-purpose/pm-skills --skill deliver-edge-cases -g -a claude-code -y`
Codex: `npx skills add product-on-purpose/pm-skills --skill deliver-edge-cases -g -a codex -y`
Cursor: `npx skills add product-on-purpose/pm-skills --skill deliver-edge-cases -g -a cursor -y`
Gemini CLI: `npx skills add product-on-purpose/pm-skills --skill deliver-edge-cases -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add product-on-purpose/pm-skills`

## Description

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 during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# 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 `iterate-lessons-log`, then update this catalog with the new case
- You need readiness coordination for a launch, not failure analysis -> use `deliver-launch-checklist`

## 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?

The rest: https://github.com/product-on-purpose/pm-skills/blob/HEAD/skills/deliver-edge-cases/SKILL.md