Map edge cases before building

Ask Claude Code to list the error states, empty states and edge cases a feature must handle, so the design covers them before anyone builds it.

Task: Map edge cases before building · Other tasks

Fill in the details

Feature or flow (required)

Name it the way the team and the code name it, so Claude can find the related code if it exists.

Where the feature stands

Design notes or spec

Optional. With a spec, Claude can mark which cases it already covers and which it misses.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

List the error states, empty states, and edge cases for [fill in: Feature or flow] that the design needs to cover.

Where it stands: still in design, with no code for it yet.

Only read. Do not create, change or delete any files.

Go beyond the happy path. Consider at least: no data yet, too much data, invalid or unexpected input, slow or failed network and server errors, missing permissions or an expired session, repeated or simultaneous actions, a user who leaves halfway, and limits on size, length or count.

Report:
1. Three groups: error states, empty states, other edge cases. For each case give one line each for what triggers it, what the user should see or be able to do next, and whether the spec or code already covers it (yes, no, partly, or unknown if you have neither).
2. The five cases to design first, and why.
3. Open questions. When the right behavior is a product decision, list it here instead of choosing for me.

Mark which cases you found in the code and which you inferred.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

A designer or product manager has a happy-path design for a feature and wants to know which failure and empty screens are still missing before handoff.
The feature is partly built and you want the list of states grounded in what the code does today, such as which errors the server can actually return.
You are writing acceptance criteria or a test plan and want a structured list of cases to start from instead of a blank page.

When not to use it

You do not yet know what the feature should do at all. Work out the requirements first, for example with the spec interview template, then map the edge cases.
You want the edge cases handled in code right away. This prompt only produces a list; use the test-first template to turn agreed cases into tests and code.
The work is in a plain chat without access to the repository. Claude can still list generic cases from your notes, but it cannot check them against the code.

Why this structure

The opening request asks for what is missing rather than what is there. A design review naturally follows the happy path; naming error states, empty states and edge cases as separate targets points attention at the screens that are usually skipped.
Pasted design notes go first inside <spec> tags and are labeled as material to analyze. That keeps your notes apart from the instructions and lets the report mark each case as covered or not.
The stage setting tells Claude whether to read the code. When the feature is partly built, the list is based on what the code can actually do, not only on what the design implies.
The checklist of situations, from no data to a user who leaves halfway, gives Claude a minimum set of angles so the list does not stop at the two or three obvious failures.
The read-only line keeps this a planning step. Nothing in the repository changes while you decide which cases matter.
The open questions section asks Claude to return unresolved product decisions to you as questions, and the found-or-inferred marking shows which items come from the code and which are Claude's reading of it.

Example input (fictional)

Feature or flow

the file upload flow on the project settings page

Where the feature stands

still in design, with no code for it yet

Design notes or spec

Users can drag a file onto the page or pick one with a button. Supported types are PDF, PNG and JPG. After upload the file appears in a list with its name, size and upload date.

Follow-ups to send Claude

Turn the five cases to design first into acceptance criteria, one short Given/When/Then block each.
For each error state, draft the message the user sees: one sentence on what happened and one on what to do next.
Which of these cases does the current code not handle at all? Show me where each one would need to be added.

Common mistakes

Naming the feature too broadly, such as "the app". The list becomes long and generic; one flow or screen at a time gives cases you can act on.
Accepting every case as a requirement. Some are unlikely or cheap to ignore. Use the top-five ranking and decide which ones the first release needs.
Leaving out the spec when you have one. Without it, Claude cannot tell you which cases the design already covers, so you review cases you have handled.

Write a spec by interview: Let Claude Code interview you about a feature, covering implementation, UX, edge cases and tradeoffs, then write a self-contained spec to a file.
Write tests first, then implement: Have Claude Code write tests that describe a feature before any implementation, confirm they fail, then write code until they all pass.
Turn a mockup into a working prototype: Attach a mockup image in Claude Code and get a clickable prototype that follows its layout and states, built in its own folder with fake data.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
How Anthropic teams use Claude Code (Anthropic documentation)
Claude Code best practices: Explore first, then plan, then code (Anthropic documentation)