The Testing Prompt Pack: 18 Prompts That Catch Bugs

Here is the spec / user story for the feature I'm about to build:

[PASTE SPEC]

Before I write any code, list every assumption this spec makes, explicit and implicit. For each assumption, tell me:
- What we're assuming
- What would happen to the feature if this assumption is wrong
- A simple way to validate the assumption before building

Order them from most risky to least risky.

When to use it: At the start of any non-trivial feature. Run this before writing a single test case or a single line of code.

Here is the user flow for [FEATURE NAME]:

[DESCRIBE OR PASTE THE FLOW]

My assumption is that users will understand [SPECIFIC ASSUMPTION ABOUT USER BEHAVIOR OR MENTAL MODEL].

Challenge this assumption. What would a first-time user likely think is happening at each step? Where might their mental model diverge from what's actually happening? What would cause confusion, abandonment, or a support ticket?

When to use it: When a flow feels obvious to you. That feeling is a warning sign, not a green light.

Here is the product requirements document (or spec) for [FEATURE / PRODUCT]:

[PASTE SPEC]

Read it carefully and identify:
1. Any internal contradictions (places where two requirements conflict)
2. Any ambiguous terms or phrases that could be interpreted multiple ways
3. Any requirements that are technically impossible or very expensive to implement
4. Any edge cases the spec silently ignores

Be specific. Quote the relevant sections.

When to use it: Before engineering starts, or when a sprint is running longer than expected and nobody knows why.

I'm building [BRIEF DESCRIPTION OF PRODUCT / FEATURE]. The target users are [USER TYPE]. The data it handles includes [DATA TYPES].

What compliance, legal, or regulatory requirements might apply that a product team would commonly overlook? Cover:
- Data privacy (GDPR, CCPA, HIPAA, COPPA, whichever is relevant)
- Accessibility (WCAG)
- Industry-specific regulations
- Terms of service constraints from platforms we might integrate with

For each one, tell me what the actual risk is if we ignore it and how expensive it typically is to retrofit compliance later.

When to use it: During discovery, especially if you're entering a new vertical or handling new data types.

Here is the function / feature I just built:

[PASTE CODE OR DESCRIBE FEATURE]

Generate a comprehensive list of edge cases I should test. Think about:
- Boundary values (empty, null, zero, maximum, minimum)
- Unexpected input types or formats
- Concurrent or race-condition scenarios
- Network failure or latency at any step
- State that exists in the database that doesn't match what the UI shows
- Behavior when upstream dependencies return errors or stale data

For each edge case, describe what would actually happen with the current implementation if you know, and whether that outcome is acceptable.

When to use it: After you've written your happy-path tests. Treat this as a mandatory second pass.

Here is the test suite for [MODULE / FEATURE]:

[PASTE TESTS]

Audit this test suite. Tell me:
1. What scenarios are being tested
2. What scenarios are missing entirely
3. Which tests are testing implementation details rather than behavior (and are therefore fragile to refactors)
4. Which tests give false confidence: they pass but don't actually prevent real user-facing failures
5. The three tests I should add first, ranked by risk reduction

When to use it: When code coverage is high but bugs keep slipping through. Coverage metrics lie. This prompt finds out why.

Here is the happy path for [FEATURE]:

[DESCRIBE THE IDEAL USER FLOW]

Now be adversarial. Give me 10 realistic ways a real user (not a QA tester, a real user) could break this flow through normal behavior: misclicks, back buttons, slow connections, parallel browser tabs, session expiry, copy-pasted data in wrong formats, etc.

For each one, tell me the likely outcome and whether it's a silent failure or a visible one.

When to use it: Before any user-facing feature ships. Especially useful for flows involving payments, authentication, or multi-step forms.

I'm about to make the following change to our codebase:

[DESCRIBE THE CHANGE]

Here are the parts of the codebase it touches (or paste the diff):

[PASTE DIFF OR DESCRIBE AFFECTED MODULES]

What existing functionality is most likely to regress as a result of this change? Walk through the dependency chain and flag anywhere a side effect could surface. Be specific about what would break and how a user would experience it.

When to use it: Before merging any change that touches shared logic, database schemas, or auth flows.

Here is the list of error states our application can surface to users:

[LIST OR PASTE ERROR MESSAGES / STATES]

For each error:
1. Is the message understandable to a non-technical user?
2. Does it tell the user what to do next?
3. Does it accidentally expose information that could be a security risk?
4. Is there a case where this error fires but the user's action actually succeeded (causing them to retry unnecessarily)?

Rewrite any messages that fail these checks.

When to use it: Before any launch. Error messages are the part of your product you test last and users experience most.

Here is the API endpoint I've built:

[PASTE ENDPOINT DEFINITION / SCHEMA]

Generate a set of contract tests that verify:
- All required fields are validated and reject bad inputs with clear errors
- All optional fields behave correctly when absent
- Response shapes match the documented schema
- HTTP status codes are semantically correct (not just 200 for everything)
- The endpoint handles auth failures, rate limits, and malformed tokens correctly

Write these as concrete test cases, not just categories.

When to use it: Any time your API is consumed by another team, a mobile app, or a third-party integration.

Here is the feature / system I've built:

[DESCRIBE THE FEATURE AND ITS DATA PATTERNS]

Describe the realistic scenarios under which this would degrade or fail under load. Consider:
- What happens when the dataset grows 10x, 100x
- What queries or operations become slow first
- Where queuing or async processing would help but isn't currently used
- What a user would experience during degradation (slow, frozen, or error?)

Rank these by likelihood given our current scale, and tell me which ones I should address before launch vs. which I can defer.

When to use it: Before launching anything with real data volume expectations. Scale failures embarrass you publicly. Catch them privately.

Here is a description of our product and how it stores / handles data:

[DESCRIBE PRODUCT, DATA FLOWS, AUTH MODEL]

Build a threat model for this system. For each threat:
- Describe the attack vector
- Describe the likely attacker (not a nation-state, be realistic for a startup)
- Describe the impact if successful
- Describe the mitigation and whether we currently have it

Focus on the top 7 threats. I don't need an exhaustive list, I need the ones that would actually hurt us.

When to use it: Before any feature that changes your auth model, data handling, or user permissions. Also useful as a quarterly audit.

Our product depends on the following external services and libraries:

[LIST DEPENDENCIES]

For each one, tell me:
- What happens to our product if this service goes down for 10 minutes, 1 hour, 24 hours
- Whether we have graceful degradation or we hard-fail
- Whether we have alerting that would catch the failure before a user reports it
- Whether there's a realistic fallback

Prioritize by customer impact.

When to use it: Once a quarter, or whenever you add a meaningful third-party dependency.

Here is how we write and read data for [FEATURE / SYSTEM]:

[DESCRIBE DATA MODEL AND WRITE/READ PATTERNS]

Identify all the ways data could end up in an inconsistent state. Consider:
- Partial writes that succeed halfway
- Concurrent updates from multiple users or sessions
- Schema migrations that run against live data
- Rollbacks after a failed deployment
- Third-party webhook deliveries that arrive out of order

For each scenario, tell me what the user would see and whether we'd know about it from our current observability.

When to use it: Before any database migration, multi-user feature launch, or integration with a webhook-based third party.

Here is what we currently monitor and alert on:

[LIST METRICS, ALERTS, DASHBOARDS]

Given that we're running [BRIEF PRODUCT DESCRIPTION], what failures could happen that none of our current monitoring would catch? Think about:
- Silent failures (the system runs but produces wrong output)
- Failures that show up in user behavior before they show up in error rates
- Failures that only affect a subset of users
- Failures that compound slowly over days rather than spiking

For each gap, suggest the simplest monitoring addition that would catch it.

When to use it: After your first production incident that monitoring didn't catch. Ideally, before it.

We're about to deploy the following change:

[DESCRIBE CHANGE]

Evaluate our rollback plan:

[DESCRIBE ROLLBACK PLAN, OR SAY "WE DON'T HAVE ONE"]

Tell me:
1. Whether this rollback plan would actually work given the change
2. What data state issues could prevent a clean rollback
3. Whether our users would experience anything during the rollback
4. What we'd need to add to make this rollback safe

If we don't have a rollback plan, write one.

When to use it: Before every production deployment that touches the database or auth system. Non-negotiable.

Here is a summary of the incident we just had:

[DESCRIBE WHAT HAPPENED, TIMELINE, IMPACT]

Run a structured post-mortem on this. Cover:
1. The immediate cause
2. The contributing causes (go at least 3 levels deep with "why")
3. What our systems, process, or culture allowed this to reach production
4. What we would need to change to make this class of failure impossible, not just unlikely
5. What the early warning signs were that we missed (in logs, metrics, or user feedback)

Be direct. The goal is learning, not blame.

When to use it: Within 48 hours of any incident. The details decay fast.

Here are the bug reports we've received in the last [TIME PERIOD]:

[PASTE BUG REPORTS OR SUMMARY]

Do the following:
1. Cluster these into themes (what underlying issues keep surfacing)
2. Identify the ones that are symptoms of the same root cause
3. Flag any that suggest a systemic problem vs. a one-off edge case
4. Rank by user impact (not just frequency, but severity of the experience)
5. Write the first three bug tickets I should file, including reproduction steps and acceptance criteria for the fix

Skip anything that's a feature request disguised as a bug.

When to use it: Weekly, as part of your regular product rhythm. Don't let bug reports pile up unread.