dw-grilllisted

# dw-grill — interview the idea before it becomes work **Conversational, and it writes nothing.** What it produces is a **shared understanding**, which `dw-shape` turns into a durable artifact. ## What it reads The conversation, plus whatever it can verify in the repo. The subject may arrive as `$ARGUMENTS`; otherwise it's whatever is being discussed. It writes no files. Read `CONTEXT.md` before the first question if the project has one. An interview is where words get coined, and a second name for a thing that already has one is exactly the drift a glossary exists to stop — so ask in the terms already defined there. ## Workflow ### 1. Separate facts from decisions Split everything you don't know into two piles, because they are answered differently: - **Facts** — anything discoverable in the environment: which library version is installed, whether a route already exists, what the schema column is called, how the neighbouring module does it. **Look these up. Never ask.** Asking the user to read their own repo to you is the failure mode this rule exists to prevent. - **Decisions** — trade-offs, scope boundaries, product choices, "which of these two shapes". These are the user's, and only these become questions. ### 2. Spend the question budget well **At most five questions.** That cap is the point: it forces you to decide what is worth asking instead of interrogating. Order them hardest-first, by what a wrong answer would cost: 1. **scope** — what's in, what