---
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, guided by what the moment needs:

- 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.
- **Ask in rounds** — a batch of independent questions in one message, the next round grown from the answers. Both failure modes are real: the one-question drip costs eight round-trips and their patience, and a single wall of everything you thought of is a form, not an interview. Few round-trips, many questions.
- 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. Work that entered the flow earns the whole interview; a skimmed one pays the ceremony and buys nothing. 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. When one surfaces, or the user wants to go deeper on design than the interview can, name `/architect` and let the user call it — the same question, asked with the field's evidence behind it. The interview recommends; it never dispatches.

Record the outcome in the work file (`genius-file` skill), sharpen terms into the glossary as they resolve (`domain-glossary` skill), walk unfamiliar territory before asking about it (`blindspot` skill). 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, scope edged, their confirmation in the file in their words rather than your paraphrase. Every load-bearing question is answered by then — or, where they chose to stop, written down as `assumed:`, so nothing sits silently assumed. Until that line exists, the next stage doesn't.