The Context Collapse Prompt Pack: 18 Prompts

I'm running a post-mortem on a product decision that didn't go as expected.

Here's the original decision: [describe the feature or bet you made]
Here's what we expected to happen: [expected outcome]
Here's what actually happened: [actual outcome]

Please help me work backwards through the decision:
1. What assumptions were embedded in the original decision that may not have held true?
2. What signals, if any, typically precede this kind of miss, and could we have caught them earlier?
3. Where in the decision process (problem framing, solution selection, success definition) was the failure most likely introduced?
4. What's the single most useful question we should have asked before committing to this?

Don't speculate about technical issues. Focus on the decision-making layer only.

A recent project ran significantly over its original scope. I want to understand where and why scope expanded.

Original scope: [describe what was originally planned]
What was actually built: [describe what shipped]
Key decision points where scope changed: [list the moments you remember]

Please help me:
1. Categorize each scope expansion: was it driven by discovered complexity, changing requirements, stakeholder input, or something else?
2. Identify which expansions were necessary vs. which were avoidable given better upfront definition.
3. Flag the earliest point in the project where the scope drift became likely.
4. Suggest three questions we should answer before scoping the next similar project.

I want a second opinion on our current prioritization.

Here's what we're building right now (or planning to build next): [list features/projects]
Here's the business goal we're trying to hit: [goal]
Here's the user problem we're solving: [problem statement]
Here's what we're NOT building right now: [deprioritized items]

Please stress-test this prioritization:
1. What's the strongest argument that we're working on the wrong thing right now?
2. Is there anything in the "not building" list that has a stronger direct path to the stated goal than what's in the active list?
3. What would have to be true for our current priorities to be correct?
4. What's one question we should be able to answer confidently before locking this in, and can we answer it?

I'm about to commit to building [describe the feature or product].

Before we proceed, I want to map the assumptions underneath this decision.

Please help me generate an assumption map:
1. User assumptions: What do we believe about how users will behave, what they want, and what they'll pay for or tolerate?
2. Market assumptions: What do we believe about the competitive landscape, timing, and demand?
3. Technical assumptions: What do we believe about feasibility, complexity, and integration?
4. Business assumptions: What do we believe about monetization, retention impact, and strategic value?

For each assumption you surface, rate it on two dimensions:
- How confident are we likely to be in this assumption at this stage? (low/medium/high)
- How damaging would it be if this assumption is wrong? (low/medium/high)

Flag the top 3 most dangerous assumption combinations (low confidence + high damage).

We shipped [feature or made decision X], and in hindsight, [problem or issue Y] was fairly predictable.

I want to understand why we didn't catch it earlier.

Please help me analyze:
1. What information was available to us before we made the decision that, if weighted differently, would have flagged this risk?
2. What cognitive or process biases are most likely to explain why we missed it (e.g., confirmation bias in user research, anchoring on a preferred solution, optimism about complexity)?
3. What process change, if any, would give us a reasonable chance of catching something like this earlier next time?
4. Is this the kind of miss that process can prevent, or is it fundamentally a "you can't know until you try" situation? Be honest.

Here is a feature spec or PRD I'm about to hand off for development:

[paste spec]

Please stress-test this spec for gaps that will cause problems during build:
1. Ambiguous requirements: Where could a developer make two different reasonable interpretations? Flag each.
2. Missing edge cases: What user states, inputs, or conditions aren't addressed that are likely to come up?
3. Unstated dependencies: What other parts of the system does this implicitly rely on that aren't mentioned?
4. Success criteria gaps: Can a developer look at this spec and know unambiguously when the feature is done? If not, what's missing?
5. Scope risk: Is anything in this spec likely to expand significantly once implementation starts?

Be specific. Don't give general writing feedback. Only flag things that will cause real problems.

Here are the user stories for [feature name]:

[paste user stories]

Please evaluate these user stories on the following:
1. Job-to-be-done alignment: Does each story describe what the user is trying to accomplish, or just what the user is doing? Flag stories that describe actions without capturing intent.
2. Outcome vs. output: Are the acceptance criteria measuring whether the user achieved their goal, or just whether the feature was built?
3. Persona specificity: Are these stories written for a real, specific user type, or a generic "user" that could mean anyone?
4. Testability: Can each acceptance criterion be tested with a real user in under 10 minutes? If not, rewrite it so it can.

Rewrite the 2-3 weakest stories in a stronger form as examples.

Someone has requested the following feature: [describe the feature request]

Before I decide whether and how to build it, help me audit the underlying problem:
1. What problem is this feature explicitly meant to solve?
2. What deeper or underlying problem might the requester actually have, that this feature is a proposed solution to?
3. Are there three alternative solutions to the underlying problem that we should consider before committing to this specific feature?
4. What question should I ask the person who made this request to validate that I'm solving the right problem?
5. What does "this didn't work" look like in 6 months if we build this feature as described?

We keep shipping features that get returned for rework. I want to debug our Definition of Done.

Here's our current DoD (or as close as I can describe it): [describe or paste your current DoD]
Here are two or three recent examples of features that shipped but came back: [describe them briefly]

Please help me:
1. Identify what's missing from our current DoD that would have caught the rework triggers in these examples.
2. Flag any DoD criteria we have that are theater (they sound rigorous but don't actually catch real problems).
3. Suggest a revised DoD that's specific enough to be usable but short enough that a developer will actually check it.
4. Identify one integration test or user scenario that, if it passed, would have prevented each of the rework examples you were given.

Here is the work we're planning to ship in our next sprint or release:

[list the features, fixes, and changes]

Please evaluate whether this work coheres as a product narrative:
1. If a user experienced everything in this list after it shipped, would they recognize a single improvement or theme? Or would it feel like a collection of unrelated changes?
2. Is there anything in this list that works against another item in the list (conflicting UX patterns, overlapping functionality, mixed signals about product direction)?
3. What single sentence would describe the user benefit of this entire sprint? If you can't write one, flag that as a coherence problem.
4. Which item in this list is most likely to confuse users who haven't been following our roadmap?

We shipped [feature name]. Technically it works. But user response has been [describe the response: confused, disengaged, using it wrong, not using it at all].

Here's what we intended the feature to do: [describe the original intent]
Here's what the feature actually does (as shipped): [describe the behavior]

Please help me analyze the gap:
1. Where is the largest distance between what we intended and what the user is experiencing?
2. Is this a communication gap (the feature does the right thing but the user doesn't understand it), a design gap (the interface doesn't match the mental model), or a scope gap (we built a subset of what was needed)?
3. What's the minimum change that would close the most important part of this gap?
4. Should we fix this now, or is this a signal that the underlying concept needs to be revisited before we iterate on execution?

After our most recent release, [describe what broke or degraded].

This thing was working before. Here's what changed in the release: [describe the changes].

I want to debug this systematically:
1. Based on what changed, what are the three most likely mechanisms by which the regression could have been introduced?
2. What should I test or check first to confirm or rule out each mechanism?
3. Is this regression more likely to be a direct consequence of one of the changes, or an interaction effect between multiple changes?
4. What test or check, if it had been in our release process, would have caught this before it reached users?

We have an AI-powered feature that [describe what it does]. When we launched, user response was [describe initial reception]. Now, [describe current problems: quality has dropped, users complain about X, outputs feel generic, etc.].

Help me audit what might have drifted:
1. Prompt drift: Could the prompts powering this feature have been modified in ways that degraded quality? What changes would I look for?
2. Model drift: Could a model update or change have shifted the output behavior? What would that look like in our outputs?
3. Data drift: Has the input data (user inputs, context being passed) changed in ways that the prompts weren't designed for?
4. Expectation drift: Have user expectations shifted since launch in ways that make the same output quality feel worse?
5. What's the fastest way to diagnose which of these is the primary driver?

We shipped [feature name]. It works. The build is solid. But [X% of users / almost no users] are using it.

Here's where it lives in the product: [describe placement, discoverability, entry point]
Here's how we communicated it to users: [describe onboarding, notifications, changelog, etc.]
Here's what using it requires from the user: [describe steps, friction, prerequisite knowledge]

Please help me diagnose low adoption:
1. Discoverability: Would a user who wanted this feature know it exists and where to find it?
2. Activation friction: What's the minimum a user has to do to get value from this feature, and is any of that friction unnecessary?
3. Value clarity: From the UI alone, can a user understand what this feature does and why they should care, without documentation?
4. Timing mismatch: Is this feature being surfaced at the right moment in the user's workflow, or is it available at the wrong time?
5. What's the single most likely reason a user who would benefit from this feature hasn't tried it?

Here is a batch of user feedback we've collected about [feature or product area]:

[paste feedback]

Please help me sort this into signal and noise:
1. Group the feedback into themes. For each theme, tell me how many distinct users it represents, not how many times it was mentioned.
2. Separate what users are asking for (their proposed solution) from what they're actually struggling with (the underlying problem).
3. Flag feedback that is loud but represents a small or unrepresentative segment.
4. Flag feedback that is quiet but points at a structural problem.
5. Rank the themes by how much user friction disappears if we resolve them, not by how many people requested them.
6. Tell me which themes I don't have enough information to act on yet, and what I'd need to learn first.

Be willing to tell me that a loud request is the wrong thing to build.

Something got lost in a handoff on our team. I want to find out where and why.

The handoff: [describe who handed what to whom: PM to design, design to eng, eng to support, etc.]
What the sender believed they communicated: [describe]
What the receiver actually acted on: [describe]
The consequence: [what got built wrong, delayed, or reworked]

Please help me trace the loss:
1. What specific piece of context failed to survive the handoff? Name it precisely.
2. Was it never written down, written down somewhere nobody reads, or written down and misread?
3. Is this a one-off, or does the structure of this handoff make this loss likely every time?
4. What is the smallest artifact or ritual that would have carried this context across? Be concrete. Don't suggest "better communication."
5. Who should own that artifact, and when in the process does it need to exist?

We keep reopening the same decision. I want to understand why it won't stay closed.

The decision: [describe what was decided]
When and how it was made: [describe the forum, who was there, how it was recorded]
How many times it has been reopened: [number and rough timeline]
Who reopens it, and what they say: [describe]

Please help me diagnose:
1. Is this being reopened because the decision was never actually made, never recorded, or never explained?
2. Is the person reopening it missing context, or do they have context the original decision didn't account for? Those need opposite responses.
3. What was left unresolved at the moment of the decision that keeps leaking back in?
4. What would "closed" need to look like for this to stop? What has to be written, and who has to agree to it?
5. Is there a real unresolved disagreement here that we're avoiding by relitigating the surface question instead?

Our team follows a process, and problems still reach users. I want to find out which parts of the process are real and which are theater.

Here are the rituals, docs, and checkpoints we currently run: [list them: standups, planning, reviews, DoD checks, retros, sign-offs, whatever applies]
Here are two or three recent problems that reached users anyway: [describe them]

For each ritual or checkpoint, tell me:
1. Which of the recent problems it had a genuine chance to catch, and whether it did.
2. Whether it produces a decision or an artifact anyone uses afterward, or whether it just produces attendance.
3. What it costs per week in hours across the team.
4. What would actually break if we stopped doing it tomorrow. Be honest. For some of these the answer is nothing.

Then: recommend what to cut, what to keep, and the one checkpoint that doesn't exist yet that would have caught the most of the problems I described.