Check what problem a solution actually solves before you build it

A solution usually shows up before anyone has said what problem it solves. Sometimes it's yours, because building something has gotten cheap enough that trying it costs less than thinking it through. Sometimes a teammate brings it to a planning meeting, or a client asks for a specific feature in the middle of a project. Either way you're holding an answer, and the question it answers was never written down.

Building it as it arrived is where the cost hides. A person who could state their problem precisely would usually have stated it, so the solution is a compressed version of something felt and never put into words. Building it faithfully solves whatever survived the compression. Your own ideas carry the same risk with no one to push back, and they pile up, each one plausible and none of them tested.

The answer is to run the solution backward. Guess at the pressure that produced it, state the problem in one sentence, name what the solution quietly assumes and look for other ways to read the same problem. For your own ideas, finish with a verdict on whether each is worth the time. The XY problem is the old, narrower name for the pattern, someone asking how to do the thing they think will get them what they want rather than describing what they want.

The test runs showed why the verdict needs a floor. Handed three ideas with nothing behind them, the prompt marked every one "none named" and asked one concrete question about each, where a friendlier prompt would have found something encouraging to say.

Your own ideas get a verdict

Pointed at your own ideas, the prompt triages rather than analyzes. For each idea it gives the problem the idea appears to solve, the evidence that exists for it and a verdict: worth the time, not yet or needs one named check first. Give it several at once and they come back as a table, one row per idea, so the whole list reads in one pass.

It asks rather than searches. The prompt won't go hunting for support in your files or on the web. An agent that assembles your evidence for you takes the judgment away from you and hands back something that only looks researched. The evidence has to be what you already have, said out loud, so it asks you direct questions about what exists.

Most ideas should stop at the evidence line. A prompt that returns an encouraging verdict on everything has told you nothing, so it defaults to no evidence unless you name something concrete and checkable. It never softens a finding of none.

Someone else's solution gets taken apart in five parts

An old plan of your own counts here too, since you're no longer the person who wrote it.

Read the solution as evidence, not as an instruction. The first move is a guess at what produced it. Something happened, such as a complaint, a number that moved or a bad meeting, and the solution is what was left. Naming the pressure takes a sentence and makes everything after it possible.

State the underlying problem in one sentence. Say who is stuck, what is stopping them and what it costs while it stays unresolved. If it takes two sentences, the problem hasn't been found yet.

Name what the solution assumes, and attach a real check to each assumption. There are two to four, and each gets one thing that could actually be done this week, a specific search, a specific person or a specific number. A check that sounds specific and isn't, like gather more data, is worse than no check, because it reads as resolved when nothing was. The prompt names the checks and never runs them.

Write the problem statement. One sentence says who is blocked, what is blocking them, why it matters and what success would look like. This is the sentence you could hand to someone else with the original solution stripped off.

Offer readings that point somewhere else. There are two or three, and they have to be genuinely different rather than the same idea rephrased. Sometimes the original solution was right, and the prompt says so plainly rather than inventing weak alternatives to fill a list.

What you get and what you don't

For your own ideas you get a verdict on each, backed by what you could say out loud. For someone else's solution you get a one-sentence statement of the problem it was probably meant to solve, the checks worth running before anyone builds and two or three other ways to read the same problem.

You don't get a plan, and you don't get new ideas, only other readings of the same problem. You don't get a reply to send either. What to say to a teammate or a client depends on what you're bringing them instead, so that part stays yours. If you want a draft once you know, ask for one in the same conversation.

The block below is written for your AI rather than for you. Paste it with your ideas or the solution underneath, and it works out which of the two you brought, because they come back in different shapes. Paste it with nothing after it and it asks. It runs there and then, in the conversation. At the end it offers to keep itself as a skill, a saved command you call by name, and saves nothing unless you say yes.

Try it on the next idea or proposal you're about to start building, pasted in the words it arrived in rather than your summary of it. The first step reads the wording for the pressure behind it, and a summary strips that out.

Paste this into your AI agent or a new chat. The post above says what it does. Some prompts set something up in your project that keeps working after, and others run once, right where you paste them. None of them pushes anything to a remote.

You are taking a solution apart to find the problem underneath it. Do it here, in this conversation. Do not set anything up, do not save any files and do not commit anything. You are given either a solution that came to me from somewhere else, or one or more of my own ideas. The input is: $ARGUMENTS. If that slot is empty or still reads as a placeholder, the input is whatever I wrote after these instructions, and if there is nothing there either, ask me which of the two I have and wait.

Decide which case you are in before writing anything. A solution that arrived already formed is the first case: a teammate's proposal, a client asking for a specific feature, a plan from a past version of me. My own ideas, offered for triage, are the second. If you cannot tell, ask. Do not guess, because the two produce different outputs and the wrong one wastes my time.

In the first case, work through all five parts, every time, and keep each to a sentence or two. The parts that get skipped under time pressure are the ones the whole thing exists for.

One, diagnosis. What pain or pressure most likely produced this solution. Read it as evidence of something felt, not as a spec to fill.

Two, the underlying problem. One tight sentence: who is stuck, what exactly is stopping them, and what it costs while it stays unresolved.

Three, assumptions. Name the two to four things the proposed solution is quietly resting on. For each, say what breaks if it is wrong, and name one check I could really carry out this week: a specific search, a specific person to ask, a specific number to pull. Never write a check that sounds specific and is not, such as gather more data or do some research. A fake check is worse than none, because it looks done when nothing was done. Do not carry the checks out yourself, here or anywhere in this prompt. Naming them is the work; running them is mine, and a check you ran is a judgment you took off me.

Four, the problem statement. One sentence combining who is blocked, what is blocking them, why it matters, and what success would look like. This is the sentence I could hand to someone else so they understand the real problem with the original solution stripped off.

Five, alternative framings. Two or three genuinely different ways to read the same underlying problem, each pointing somewhere different. Before writing them, check that they are actually distinct and not the same idea in new words. If the original solution turns out to be the right one, say that plainly instead of manufacturing weaker alternatives to reach a count.

Stop after part five. Do not draft a message, email or reply to anyone unless I ask for one.

In the second case, triage rather than analyze. For a single idea, give the problem it appears to be solving in my own words as far as possible, the evidence that exists for it, and a verdict: worth the time, not yet, or needs one named check first. For more than one idea, return a table with one row per idea and a phrase per cell, columns for the idea, the problem it infers, the evidence, and the verdict. A whole list read in one pass is the point; paragraphs defeat it.

On evidence, ask rather than search. Put direct questions to me about what actually exists: a conversation I had, a pattern I noticed, a number I saw, a person who said something specific. Do not go looking through my files or the web for support, because that turns a judgment I own into one you assembled. Default to no evidence unless I name something concrete and checkable. Most ideas should stop here, and that is the tool working. Never soften a verdict of none to spare an idea.

Never attack a decision I have already chosen; that is a different job. Never generate new ideas here either. This runs on what is already on the table, before anyone has committed.

At the end, tell me in one line that I can have this on a keystroke instead of a paste, and create no file unless I answer yes, in which case save these instructions as a skill wherever my tool keeps them, with one line at the top saying it only ever runs when I call it by name. If a skill with that name is already there, tell me and ask before you replace it. It must never fire on its own just because something looks like a solution handed down.