Skip to main content

AI prompts for analysis you can act on

Tool comparisons with a verdict. Pre-mortems that name the failure mode. Root-cause prompts that go past the second 'why'. These templates force a decision instead of a balanced overview.

10 free prompts · tested in ChatGPT, Claude & Gemini · browse the full library

Compare two tools for a specific use case

Get an opinionated comparison, not a vendor-neutral feature matrix.

Compare tool a and tool b for the specific use case: use case.

I am: user context.

Output:
1. **Verdict in one sentence** — which one I should pick and why.
2. **Three reasons** the verdict tool wins for my use case.
3. **One reason** the other tool would actually be better, so I know the trade.
4. **When to switch** — what would have to change for the verdict to flip.

Do not list every feature. Do not be diplomatic. Pick a winner.
Why it works
Demands a verdict. Models default to 'it depends' — this prompt removes that escape hatch and surfaces the real trade-off.
What to swap
user_context is critical: 'solo founder' vs 'enterprise IT' will flip most verdicts.

Pre-mortem on a plan or decision

Surface failure modes before committing to a course of action.

Imagine it is 12 months from now and the plan below has clearly failed. Work backwards.

The plan: plan
Context: context

Produce:
1. **Top 5 failure modes**, ranked by likelihood × impact.
2. For each: the early warning signal you would see in months 1–3.
3. **The single biggest assumption** the plan is making that, if wrong, kills it.
4. **The cheapest test** to falsify that assumption in the next two weeks.

Be specific. "Bad execution" is not a failure mode.
Why it works
The 'work backwards from failure' framing surfaces risks that forward-planning misses. Gary Klein's pre-mortem method.
What to swap
Plug in any decision: a hire, a feature launch, a product pivot, a job change.

5 Whys root-cause analysis

Get past surface symptoms to the actual cause of a recurring problem.

Apply the 5 Whys technique to the problem below. Go five levels deep — do not stop early.

Problem: problem
What we have tried: previous attempts

For each "Why?":
1. State the immediate cause.
2. Give the evidence you would expect to see if that cause is real.
3. Move to the next "Why?".

After Why #5, give:
- The likely root cause (one sentence).
- The smallest experiment to confirm it.
Why it works
Stopping at Why #2 or Why #3 is the most common analysis failure. Demanding five levels enforces depth.
What to swap
previous_attempts is critical — without it the model retreads stuff you've already tried.

Map a competitive landscape before a build, buy, or partner decision

Get a structured market picture, and a recommended move, without two days of research.

Map the competitive landscape for: market or category.

My context: my context (e.g. "Series A SaaS, building in this space" or "evaluating an acquisition target")
The dimension that matters most to me: key dimension (e.g. price, distribution, product depth, brand, regulatory moat)

Produce:
1. **The four to six most relevant players**, each with: their positioning in one sentence, their primary strength, their primary weakness.
2. **The positioning axis** — the two dimensions that best separate these players on a 2×2.
3. **The white space** — what combination of position is currently unoccupied and why.
4. **What changes in 12 months** — one structural shift (regulation, technology, distribution) that reshapes this map.
5. **Recommended move** — one sentence on the most defensible position given my context.

Do not give me a balanced overview. Give me a verdict.
Why it works
Forcing the recommended move prevents the 'it depends' conclusion that makes competitive research useless. The 12-month structural shift question is where most analyses stop too early.
What to swap
key_dimension is the single most important field — 'price vs distribution' produces a completely different map than 'feature depth vs brand'.

Identify the load-bearing assumptions in a plan

Find which beliefs, if wrong, cause everything else to collapse — before you commit.

I want to audit the assumptions in the plan below.

The plan: plan
What I am trying to achieve: goal

1. List every assumption the plan is making — stated or unstated. Include assumptions about customer behavior, market conditions, team capability, technology, and timing.
2. For each assumption, rate:
 - **Confidence**: High (well-evidenced), Medium (plausible but untested), Low (a guess)
 - **Consequence if wrong**: High (kills the plan), Medium (requires rework), Low (minor adjustment)
3. Surface the three assumptions in the High×High quadrant.
4. For each High×High assumption, name the cheapest test you could run in two weeks to validate or falsify it.

Be specific. "We assume the market exists" is not an assumption — name the specific belief.
Why it works
Running this before the pre-mortem catches assumptions during design, while they are still cheap to change. The confidence×consequence matrix turns them into a prioritized testing list.
What to swap
Paste the actual plan. A summary has already stripped out the assumptions you need to find.

Steelman the position you disagree with

Build the strongest honest case against your own conclusion before you commit to it.

I have reached a conclusion and I want the strongest case against it, argued honestly.

My conclusion: my conclusion
My reasoning: my reasoning
What I would lose if I am wrong: cost of error

Do this in order:
1. Restate my position in a form I would agree with. If you cannot, say what is unclear and stop.
2. Build the strongest opposing case — the one a competent person who disagrees would actually make. Do not build a weak version you can knock down.
3. Identify which single piece of evidence, if it existed, would most damage my position.
4. State what that opposing case requires to be true, and how I could check each requirement.
5. Give your honest read: which position is better supported by what I have given you, and by how much.

Do not conclude that both sides have merit unless you can say specifically why the disagreement is unresolvable with the available evidence.
Why it works
The 'balanced overview' is the default failure mode of AI analysis. Requiring a verdict and a falsifying test forces the model past it.
What to swap
Put your real reasoning in `my_reasoning`, including the weak parts. A sanitised version gets you a sanitised critique.

Sanity-check a number before you act on it

Pressure-test a surprising metric for measurement error before you build a story around it.

A number surprised me and I want to know whether it is real before I act on it.

The number: the number
What it is supposed to measure: intended measure
How it is calculated, as far as I know: calculation
What changed recently that could be related: recent changes
What I currently believe it means: my interpretation

Work through, in order:
1. Definitional causes — could the metric mean something other than I think it means?
2. Measurement causes — collection changes, tracking gaps, double-counting, timezone or period boundaries, bot or internal traffic
3. Composition causes — could the aggregate move without any subgroup moving? Could a subgroup mix shift explain it entirely?
4. Only then, real causes

For each candidate, give the specific check that would rule it in or out, in the order I should run them — cheapest and most likely first.
Finish with: what is the probability this is a real change and not an artefact, and what is the single check that would move that estimate most?
Why it works
Forcing measurement and composition causes ahead of real ones matches the actual base rate — most surprising numbers are artefacts.
What to swap
`recent_changes` should include deploys and tracking changes as well as business events. That is where most artefacts come from.

Turn a pile of sources into a decision brief

Compress a stack of articles or reports into something a decision-maker will read.

Turn the sources below into a brief for someone deciding the decision.

Structure:
1. The answer, in three sentences, stated up front
2. What the sources agree on — only claims supported by more than one source
3. Where they genuinely disagree, and what the disagreement turns on
4. What none of them address that matters for this decision
5. Confidence: high, medium or low, with the reason

Rules:
- Attribute every substantive claim to a specific source. If you cannot, drop the claim.
- Do not smooth over disagreement into a consensus that no source actually holds.
- Flag any source that is marketing material from an interested party, and weight it accordingly.
- Maximum word count words.

Sources:
"""
paste sources here
"""
Why it works
Section 4, what nobody addresses, is where the real risk usually is, and it is the section a summary never produces on its own.
What to swap
Frame `the_decision` as a choice between named options. A topic gets you a summary; a decision gets you a brief.

Write a decision memo that commits to one option

Turn a set of options into a memo with a recommendation and a reversal condition.

Write a decision memo recommending one of these options.

The decision: decision
Options: options
Constraints that cannot be relaxed: hard constraints
What we are optimizing for, in order: priorities
Who decides and what they care about: decider

Structure:
1. Recommendation — one option, in one sentence, at the top
2. Why this one, argued against the priorities in order
3. The strongest argument for the runner-up, and why it loses
4. What we give up by choosing this — named specifically. "Some trade-offs" is not an answer
5. What would have to be true for this to be the wrong call
6. The reversal condition: the specific signal, and by when, that should make us revisit

Maximum one page. Do not recommend "it depends", a hybrid not in the option list, or further research unless you name the specific question research would answer and what it would change.
Why it works
The reversal condition is what turns a recommendation into a decision — it lets people commit without pretending to be certain.
What to swap
Order `priorities` honestly. If cost genuinely outranks speed, say so, or you will get a memo optimizing the wrong thing.

Find the real themes in open-text survey answers

Extract what respondents actually said, with counts, instead of a flattering summary.

Analyze the open-text responses below.

Question they were answering: survey question
What I am trying to decide: the decision

Do this:
1. Group responses into themes. Derive themes from the text — do not start from a category list.
2. For each theme: the count, the share of total, and two verbatim quotes (unedited, including typos)
3. Rank themes by count. Ignore how interesting they are
4. Separately list themes mentioned by fewer than three respondents, unranked, as "low frequency"
5. Note responses that fit no theme, and how many
6. State what these responses cannot tell me — the selection bias in who answered, and what the question wording pushed people toward

Do not paraphrase a quote and present it as verbatim. Do not merge two themes because they sound similar if respondents used them differently.

Responses:
"""
paste responses here
"""
Why it works
Counts plus verbatim quotes is what survives scrutiny in a meeting. Paraphrased themes without counts are indistinguishable from opinion.
What to swap
Paste raw responses. A cleaned export loses the typos and half-sentences that carry signal about how strongly people felt.

Frequently asked questions

Tool comparisons with a verdict. Pre-mortems that name the failure mode. Root-cause prompts that go past the second 'why'. These templates force a decision instead of a balanced overview. This page collects 10 free, copy-pasteable research & analysis prompts, each tested in ChatGPT, Claude, and Gemini with a one-line rationale and the fields you need to swap in.