---
name: wonder
description: Question the work before doing it — the interview that turns a raw idea into a confirmed problem statement. Use when a tracked piece of work is at its wonder stage, or when the user asks to start the Working Genius flow — or to be questioned — on a new idea. An ordinary request to build something is not an invitation to start the flow.
argument-hint: "the idea or request to question"
---

# Wonder

The genius of questioning. Most failed work fails here first: the agent built exactly what was asked, and what was asked was not what was wanted.

The concept: **confirm the problem before designing anything.** Interview the user — live dialogue, always; a model interviewing itself confirms nothing. How you interview is your judgment:

- Ask only what the user alone can answer — everything the repo, the history or the docs can settle is homework, not a question. Attach your best recommendation to every question, and say the price when an answer forks the cost. The one question no homework can settle is how they will judge it done — the run they would make, the number they would look at, the case they would try first — and it goes into the problem statement in their words, because a success the interviewer wrote and they nodded at confirms the interviewer's picture, and the bar they actually hold arrives otherwise at close-out, when meeting it costs the most.
- **Ask in rounds** — a batch of independent questions in one message, the next round grown from the answers. The one-question drip costs eight round-trips and their patience; a single wall of everything is a form, not an interview.
- Telling them the story you'd build and letting them correct it is usually cheaper for them than answering from zero.
- Ask the question behind the request — a feature ask is often a solution wearing a problem's clothes. "Don't build this" is a successful outcome.
- **The interview ends when nothing load-bearing is still assumed** — not when your questions run out, and not when the user nods at a statement vague enough to nod at. Ending early is the user's line to say ("enough — go with your recommendations"), never an exit you offer them; when they say it, record what you assumed.
- An architecture question surfacing mid-interview is a fork, not small talk — answered casually, it becomes a defaulted decision. Name `/architect` and let the user call it; the interview recommends, it never dispatches.

## How it runs

1. Read the snapshot (`genius-file` skill); walk unfamiliar territory first (`blindspot` skill). Homework done now, never a question asked later.
2. Tell the user the story you would build, and ask the first round with it: independent questions, a recommendation on each, the price where an answer forks the cost.
3. Grow the next round from the answers. Collide terms with the glossary as they surface (`domain-glossary` skill). Name `/architect` when an architecture question surfaces; never dispatch it.
4. Write the problem statement back to them — success observable by their own measure, scope edged — and ask for the yes. Their words, not a nod at something vague enough to nod at.
5. Record: the Problem section in their words, the interview whole under `## wonder` in the log, every load-bearing question they chose not to answer as `assumed:` in Open, and `next:` rewritten.

Then `/invent` — or recommend `/architect` first when the work is greenfield or the design itself is the risk, and `/designer` before any interface someone will see gets built. Done when the user has said "yes, that's it" to a problem statement *you* wrote back to them: success observable by their own measure, scope edged, their confirmation in the file in their words. Every load-bearing question is answered by then, or written down as `assumed:`. Until that line exists, the next stage doesn't.