Finding Edge Cases in PRDs with Claude: 23 Missed Scenarios in One Prompt

The majority of production bugs trace back to edge cases that weren’t described in requirements. Not coding errors, not poor architecture. Missed scenarios in the PRD. Software engineering research consistently shows the cost of fixing a defect at the requirements stage is 5–10x less than at testing. At production, that gap hits 100x.

LLMs change the economics here. One prompt aimed at finding edge cases in a PRD uncovers dozens of scenarios in minutes. Not because the model is smarter than a product manager. Because it carries none of the cognitive biases that lead a document’s author to treat “obvious” scenarios as covered.

This article describes the methodology, prompts, and edge case categorization using a real PRD for a subscription management feature in a travel app.

Why PRDs Miss Edge Cases

A PRD is written by someone who knows the context. That’s both an asset and a trap. The author has the “normal” scenario in their head and unconsciously builds requirements around the happy path.

Three systemic reasons things get missed:

The curse of knowledge. The author knows how the system works internally. A new user doesn’t. The PRD says “user clicks the subscription button” and implicitly assumes the user is authenticated, has a valid payment method, and is in a supported region. None of those conditions are guaranteed.

Linear thinking. Requirements describe a sequence of steps. Real usage isn’t sequential. A user opens the payment form, switches to another app, comes back 40 minutes later. The session token has expired. What happens?

Focus on functionality, not boundaries. A PRD answers “what the system does.” Edge cases answer “what the system does when something goes wrong.” That second question requires a different mode of thinking, and switching back and forth is cognitively expensive.

LLMs don’t have any of these problems. The model has no “normal” scenario. Every path is equally likely to it.

The Base Prompt for Finding Edge Cases

Start here — this prompt works on any PRD:

Analyze the PRD below. Find all edge cases not described
in the requirements. For each edge case, specify:

1. Category (input validation / state transitions / concurrency /
   permissions / external dependencies / data boundaries)
2. Scenario — a specific situation, not an abstract description
3. Expected behavior if the edge case is not handled
4. Recommendation — what to add to the PRD

Prioritize by impact: put first any scenarios that would result
in data or money loss for the user.

PRD:
<insert PRD text>

On a subscription management feature PRD (2,400 words, 14 user stories), Claude with this prompt turned up 23 edge cases. Of those, 19 were genuine omissions; 4 were already covered elsewhere (backend spec, API contract).

23 unstructured findings are hard to prioritize. The next step is categorization.

Categorizing Edge Cases: 6 Types

Every edge case in a PRD falls into one of six categories. Each category gets its own prompt — the model finds more scenarios when it’s focused narrowly.

Input validation

What happens when input data falls outside expected boundaries — the quiet bugs that never show up in demos.

Prompt:

For each input field and parameter in the PRD, define:
- Minimum and maximum acceptable value
- Behavior for null / undefined / empty string
- Behavior for special characters and Unicode (emoji, RTL text)
- Behavior for a value exceeding storage limits

Format: table [Field | Boundary value | Current behavior
per PRD | Recommendation]

Findings on the subscriptions PRD:

Field	Boundary value	Issue
Promo code	256+ characters	PRD doesn’t specify max length. Backend accepts any string; database silently truncates to 50 characters
Name in payment form	Cyrillic + Latin mix	Payment provider rejects mixed-alphabet names; PRD doesn’t describe validation
Email for receipt	Email with + ([email protected])	Frontend validation rejects a valid RFC 5321 address

Leave any of these unhandled and you get a silent error. The user can’t figure out why the promo code “doesn’t work.” Support can’t reproduce the issue because they test with short codes.

State transitions

What happens during transitions between states — especially nonlinear and interrupted ones.

Prompt:

Build a complete state diagram for the core entity in the PRD.
For each transition between states, define:
- Is the reverse transition possible?
- What happens if the transition is interrupted (network loss,
  app close, timeout)?
- What happens when attempting a transition from an invalid state?
- Is there a race condition when transitioning simultaneously
  from two clients?

List the transitions not described in the PRD.

Findings:

Subscription in “cancellation pending” state. The PRD describes two states: active and cancelled. In practice, payment providers process cancellations asynchronously. Between pressing “cancel” and the actual cancellation, 0 to 72 hours may pass. The PRD doesn’t describe the intermediate state or what the system should do in it. Can the user change their plan during this window? Can they reverse the cancellation?

Downgrade with active premium data. A user on the premium plan has created 15 itineraries (free plan limit: 5). On downgrade, the PRD says “access to premium features ends.” It says nothing about the 15 itineraries. Are they deleted? Read-only? Does the user choose which ones to keep? Silent data loss is a straight path to churn.

Trial expiration while offline. The trial ended while the user was in the mountains with no connectivity. The app has premium content cached locally. When they reconnect, the system detects the expired trial. The PRD doesn’t say whether access gets blocked immediately or whether there’s a grace period.

Concurrency

What happens when multiple processes or users hit the same data at the same time.

Prompt:

Identify all entities in the PRD that can be accessed concurrently.
For each entity:
- Can a single user access it from multiple devices?
- Can multiple users access it simultaneously?
- What happens with concurrent editing?
- What happens with concurrent deletion and editing?

For payment operations, additionally:
- What about double-submit (two taps on the pay button)?
- What about a retry from the payment provider after a timeout?

Findings:

Double-submit payment. The user taps “pay,” the UI freezes for 3 seconds, they tap again. Two charge requests go to the payment provider. The PRD describes no idempotency key or deduplication mechanism. Result: double charge, support dispute, chargeback.

Plan change from two devices. The user has the subscription page open on their phone and tablet. On the phone they upgrade to Premium. On the tablet they tap “cancel subscription.” Both requests go out seconds apart. Without optimistic locking or versioning, the final state depends on whichever request the backend processes last.

Webhook from payment provider after timeout. A payment request was sent, the backend set a 30-second timeout, the provider took 35. The backend marked the transaction failed. Five seconds later, a webhook arrives with a success status. The PRD has no reconciliation logic.

Permissions

What happens when someone tries to act without sufficient access — or when access changes mid-flight.

Prompt:

For each action in the PRD, define:
- Which roles have access
- What a user without access sees (404 vs 403 vs redirect)
- What happens if permissions changed during an operation
- What happens to data created by a user when their role changes
- Is there a difference between "no access" and "feature doesn't exist"

Check: information leakage through error messages.

Findings:

Shared itinerary after author downgrade. User A shared an itinerary with User B using the premium sharing feature. User A then downgraded to the free plan. The PRD doesn’t say: does User B keep shared access? Can they still edit? Can they see premium elements like custom POIs and offline maps?

Team API key when the admin account is deleted. The team subscription was set up by an employee who’s since left. Their account is deactivated. API keys are tied to their account. The PRD covers subscription ownership transfer, but says nothing about migrating API keys and the integrations that depend on them.

External dependencies

What happens when external services go off-spec.

Prompt:

List all external dependencies in the PRD (APIs, payment providers,
auth providers, CDN, email, push notifications).
For each dependency:
- What if the service is unavailable (timeout 30s)?
- What if the service returns a 500 error?
- What if the service returns data in an unexpected format?
- What if the service changed its API without notice?
- Is there a fallback? Is it described in the PRD?

For payment providers, additionally:
- Which currencies are supported?
- What about currency conversion and rate discrepancies?

Findings:

Currency mismatch on region change. The user subscribed in USD, then moved to a EUR country. Apple/Google converts the currency automatically on renewal. The converted amount doesn’t match what the app shows. The PRD displays the price in “the user’s local currency” but doesn’t say which source takes priority: the App Store or the user’s profile.

Renewal push notification not delivered. Push notification services typically deliver 85–95% of messages. For users whose notifications don’t arrive, the renewal reminder won’t reach them. The PRD uses push as the only channel with no fallback to email or in-app notification.

Data boundaries

What happens at the limits of data volumes, time ranges, and formats.

Prompt:

For each entity in the PRD, define:
- Maximum number of records per user
- Behavior when the limit is reached (error, queue, delete old)
- Maximum size of a single record
- Behavior for a date in the past, far future, or February 29
- Behavior when the user's timezone changes
- Behavior during migration between data format versions

Findings:

Timezone change during an active trial. 14-day trial. The user started in UTC+12 (New Zealand), flew to UTC-10 (Hawaii) a week later. That’s a 22-hour delta. The PRD doesn’t say whether the timezone is locked at trial start or recalculated dynamically. Depending on the implementation, the user gains or loses up to 22 hours of trial time.

Annual subscription through February 29. The user signed up on February 29, 2024. The renewal date of February 29, 2025 doesn’t exist. The PRD doesn’t say: February 28 or March 1?

Advanced Prompt: Adversarial Review

After the six categories, one final prompt goes looking for what the previous passes missed:

You are an adversarial QA engineer with the goal of breaking
the system described in the PRD. Your mission is to find scenarios
where:
1. The user loses money
2. The user loses data
3. The system enters an inconsistent state
4. A security vulnerability is created
5. Compliance is violated (GDPR, PCI DSS)

For each scenario, describe the specific sequence of actions
that reproduces the problem. Don't describe abstract risks.

This prompt found two scenarios that didn’t fit any of the six categories:

GDPR deletion request + active subscription. The user requests account deletion under GDPR Article 17. They have an active annual subscription with 8 months left. The PRD doesn’t say: is the subscription cancelled? Is there an automatic refund? What does the payment provider do with a renewal scheduled for a deleted account?

Gift subscription from a banned user. User A gifted an annual subscription to User B. User A was then banned for ToS violations. The PRD doesn’t say whether User B’s gift subscription gets voided.

Methodology: Order of Applying Prompts

Order matters. Each prompt refines the context and builds on what the previous one found.

1. Base prompt — general scan, 5–10 minutes. Gives an overview and initial list.
2. Input validation — data boundaries. The fastest way to find “silent” bugs.
3. State transitions — state diagram. Finds nonlinear paths invisible in user stories.
4. Concurrency — concurrent access. Critical for payment features and collaborative functions.
5. Permissions — access rights. Especially important for multi-tenant and team plans.
6. External dependencies — external services. Finds single points of failure.
7. Data boundaries — edge values. Dates, timezones, limits.
8. Adversarial review — final check. Compliance, security, data loss.

A full cycle on a 2,000–3,000 word PRD takes 30–40 minutes. Claude reads it eight times from different angles. A manual review in a threat modeling workshop with 4–5 participants takes 2–4 hours on the same scope.

Integrating into the Workflow

LLM-based edge case review fits into three points in the workflow:

Before team review. Run the PRD through the full prompt cycle, then fold the found scenarios back into the document. The team gets a PRD where edge cases are already addressed. Discussion is about prioritization, not discovery.

During story estimation. A developer takes a user story, runs it through the input validation and state transitions prompts, and adjusts the estimate to account for edge cases — before work starts, not during.

When writing tests. A QA engineer takes the PRD and adversarial review results and converts them into test cases. Prompt for this step:

Based on the list of edge cases below, generate test cases
in Given-When-Then format. For each test case, specify:
- Preconditions (system state before the test)
- Steps (specific actions)
- Expected result
- Priority (P0–P3)
- Test type (unit / integration / e2e)

The approach gets even more effective when combined with context engineering — giving the LLM richer context increases how much it finds. When a prompt includes the PRD plus the API spec, state diagram, and known bug list, the model surfaces cross-system edge cases that a single-document pass misses.

For critical features, running edge case review through multi-agent analysis is worth it. Multiple LLM agents with different roles (QA, Security, Backend) analyze the same PRD independently and aggregate their findings. Overlapping findings across agents confirm validity; unique ones from each agent extend coverage.

Limitations of the Approach

LLMs don’t replace domain expertise. The model doesn’t know that GDPR deletion refunds are regulated differently in a specific jurisdiction. It doesn’t know that a particular payment provider processes webhooks with up to 72-hour delays, not 30 seconds.

Three limitations to keep in mind:

1. Hallucinated priorities. The model may flag an edge case as critical when it affects 0.001% of users in practice. Prioritization stays with the team.
2. Missing domain-specific cases. Without industry context, the model won’t find edge cases tied to travel (visa requirements affecting booking flow), fintech (settlement periods), or healthcare (HIPAA-specific state transitions).
3. False positives. 15–20% of findings turn out, on review, to be already covered elsewhere or irrelevant to the specific implementation. Filtering is mandatory.

Results

19 valid edge cases from one PRD. 7 were P0–P1 (data or money loss). 4 went into the backlog as P2. 8 were documented as known limitations with a plan for future iterations.

Two of them — double-submit payment and the downgrade-with-active-data scenario — would have surfaced only at QA, or in production. Cost to fix at the PRD stage: update the document, add acceptance criteria. Had they reached production, the cost would have been a hotfix, refunds to affected users, and negative App Store reviews.

The prompts in this article work on any PRD. Paste the text, run the cycle, get a list. Thirty minutes. No good reason to skip it.

---

Need help integrating AI into your product development workflow? I help startups build AI products and automate processes — belov.works.

FAQ

How do you prioritize which edge cases to actually fix when the full cycle returns 30+ findings?

Apply a two-axis filter: impact (does this cause data loss, money loss, or security exposure?) and probability (can this realistically happen in production, or does it require an unlikely sequence of events?). High-impact items go into the sprint regardless of probability — a double-charge edge case at 0.1% frequency still matters. Low-impact, low-probability items belong in a “known limitations” document with a note for future iterations. The adversarial review prompt helps with initial severity tagging; the final prioritization decision requires domain knowledge the model doesn’t have, particularly around actual usage patterns and regulatory exposure.

Can this methodology work on user stories or epics instead of full PRDs?

Yes, but the yield changes. On a user story (typically 1–3 sentences), the base prompt produces 3–5 edge cases versus 15–25 on a full PRD. The state transitions prompt is the most valuable for individual stories because it forces articulation of what happens before, during, and after the story’s happy path. The concurrency prompt is often the most surprising for atomic stories — it reveals that even a “simple” story like “user updates their profile photo” has concurrent access implications if the same user is logged in on two devices simultaneously. Running the full 8-prompt cycle on a story takes 10–15 minutes instead of 30–40.

How do you prevent the same edge cases from being re-discovered cycle after cycle on the same product?

Build an edge case registry: a shared document that logs every finding, its category, the PRD it came from, its resolution (fixed, accepted risk, future backlog), and the acceptance criteria added. Before running the prompt cycle on a new feature, feed the registry as context: “Here is a list of previously discovered edge cases for this product. Exclude any that are already addressed and focus on what’s new given this PRD.” This eliminates redundant findings and forces the model toward genuinely new territory, particularly at the concurrency and external dependencies levels where product-wide patterns tend to repeat.