Generate questions, not answers. Use when the user needs to reframe a problem, explore a space they don't fully understand, challenge assumptions in an industry or process, or find the door that better ideas could walk through. Triggers on "what questions should I be asking," "what am I not seeing," "help me think about this differently," "what would a beginner ask," or any moment where the user is stuck not because they lack solutions but because they're asking the wrong questions. Also use when a problem space feels stale, when experts have been working on something for years without progress, when an industry or field does things "because that's how it's done," or when the user says "I don't even know what to ask." Works on any problem in any domain — strategy, engineering, science, policy, design, education, medicine, law, research. This skill produces questions that open doors. Other skills walk through them.
The most important question in cancer research wasn't asked by a researcher. It was asked by a student: "What if instead of trying to kill cancer cells, we just made them behave like normal cells?"
That question didn't contain an answer. It contained a door. Researchers walked through it and found an entire field (cell reprogramming) that the "smart" questions had been walking past for decades.
Every skill in this stack generates answers. This is the only one that generates questions.
That distinction matters because the quality of your answers is capped by the quality of your questions. A brilliant answer to a mediocre question is still a mediocre outcome. A dumb question that nobody's asking can unlock answers nobody's considered.
The pattern is consistent across every domain: "Why do elevators need to be faster?" opened the door to mirrors. "Why do shoppers need to register?" opened the door to the $300M button. "Why do we try to kill cancer?" opened the door to reprogramming. "Why does the data pipeline need stages?" opened the door to self-executing events. "Why do we punish people to reduce crime?" opened the door to restorative justice.
None of these were answers. They were questions that made the existing answers look like they'd been solving the wrong problem all along.
The territory is not the problem. It's the space the problem lives in.
Go one level wider than the problem. Questions about the problem produce incremental reframes. Questions about the territory produce paradigm shifts.
If the problem is "how do we increase our app's share rate," the territory is "how single-player mobile experiences become social."
If the problem is "how do we reduce hospital readmissions," the territory is "how people navigate the transition from institutional care to home."
If the problem is "how do we improve this codebase," the territory is "how software systems remain comprehensible as they grow."
If the problem is "how do we reduce recidivism," the territory is "how people rebuild identity after institutional confinement."
If the problem is "how do we find novel resistance mechanisms," the territory is "how organisms survive stressors in ways that don't look like resistance."
State the territory in one sentence. That sentence is the only input for the rest of the skill.
Every territory has assumptions that everyone inside it treats as facts. These are not controversial opinions. They're the things so obvious that nobody says them out loud because questioning them feels stupid.
That's exactly why they need questioning.
The method:
List 8-12 things that everyone in this territory takes for granted. Not debatable positions. Settled consensus. The stuff that experts would say "well, obviously" about.
Here is what this looks like across domains:
For word puzzle games:
For nonprofit fundraising:
For antibiotic resistance research:
For urban transportation policy:
For software architecture:
Each assumption is "obvious." Each is a door waiting for a dumb question to open it.
Take each assumption and generate 1-2 questions that challenge it.
The questions follow three patterns:
Take an assumption and flip it.
Assumption: Players want to solve puzzles. Question: "What if players don't want to solve puzzles — what if they want to watch someone else struggle?"
Assumption: Resistance is a property of individual organisms. Question: "What if the most dangerous adaptations aren't happening in individual bacteria at all, but in the structure of the population?"
Assumption: More roads reduce congestion. Question: "What if every road we build generates the traffic that fills it, and the cities with the least congestion are the ones that stopped building?"
Take an assumption and ask whether it's a law of nature or just a habit.
Assumption: The puzzle itself is the product. Question: "Why is the puzzle the product? What if the conversation about the puzzle is the product?"
Assumption: Complexity should be managed through abstraction. Question: "Why do we abstract? What if making the complexity visible and navigable is better than hiding it behind interfaces?"
Assumption: Public transit should serve existing demand patterns. Question: "Why do we design routes for where people already go? What if transit should create new patterns by connecting places people don't currently think to travel between?"
Take an assumption and look at it from the perspective of someone who has never encountered this territory.
Assumption: Sharing results is how puzzle games grow. Question: "If you'd never seen a phone before and someone showed you this game, would 'tell your friends your score' be your first instinct? Or would you say 'can I play this against someone right now?'"
Assumption: Stronger antibiotics are the goal. Question: "If an alien biologist looked at our approach, would they say 'why are you in an arms race with organisms that reproduce a million times faster than you can develop weapons?'"
Assumption: Technical debt is always bad. Question: "If someone from finance looked at how engineers talk about technical debt, would they say 'you realize all debt is a tool, right? The question isn't whether to have it — it's whether the return exceeds the interest.'"
Generate 15-20 questions total. Write each as a single question. No preamble. No explanation. No "this is interesting because..."
The question speaks for itself or it doesn't belong on the list.
Mix all three patterns. Don't label which pattern each comes from. The labels are scaffolding. The questions are the product.
Read every question back. Apply the Expert Threat Test:
Would a senior person in this territory hear this question and feel comfortable? If yes, the question is too safe. It's a "good question" that stays inside the existing frame.
Would they feel a flash of defensiveness? Would they say "that's not how it works" or "you don't understand the field" or "we've been over this"?
That defensiveness is the signal. The question touched something structural. Something the expert's career is built on. Something that would have to change if the question were taken seriously.
Star 3-5 questions that produce the most defensiveness. These are the doors worth walking through.
Present the full list of 15-20 questions. Star the dangerous ones. Then pause.
After the list, add a horizontal rule and whitespace, then ask in bold:
Which of the starred questions do you want to walk through? Pick one, pick several, or tell me which ones scare you — those are usually right.
The user must know it's their turn. The list is not the output. The list is a menu. The user picks the doors. Then you open them.
Questions are not the end. They're the beginning.
Each starred question can become:
A reframed problem for generation. "What if the most dangerous adaptations aren't in individual bacteria?" becomes a problem: "Design experiments that measure population-level genomic shifts rather than individual survival." Feed that into the Guilford Engine or Persona Divergence Engine.
An input for the Wrong Problem Detector. A starred question might reveal that the problem the user is solving is the wrong one. Run the detector against the reframe.
A seed for Think Wrong. Take the starred question, assume the answer is yes, and build the counterintuitive position.
A prompt for Strip Down. If the question points at a deeper desire than the one the user started with, Strip Down can extract it.
The Dumb Questions Engine is the only skill in the stack that doesn't produce things to evaluate. It produces things to explore. Every other skill evaluates or generates. This one opens doors and lets the user choose which rooms to enter.
Use it when:
Don't use it when:
Before Wrong Problem Detector: The Dumb Questions Engine surfaces the questions nobody is asking. The Wrong Problem Detector checks whether the current problem is right. Together they cover both sides: "are we asking the right questions?" and "is the problem we're solving the right one?"
Before Strip Down: A starred question might point at a different desire than the one the user started with. Strip Down can extract it.
Before all generation skills: A dumb question, taken seriously, becomes a problem statement. A problem statement feeds every generator. Questions → problems → ideas.
Complements Think Wrong: Think Wrong challenges consensus answers. Dumb Questions challenges consensus questions. Think Wrong says "the obvious answer is wrong." Dumb Questions says "the obvious question is boring — here's the interesting one."
This is the earliest skill in the stack. It runs before you even know what problem you're solving. It produces the raw material that every other skill refines.