crew-grilllisted

Run the full design pipeline in three phases. Pause for user feedback within each phase, but do not ask the user to manually invoke the next skill — transition automatically. ## Phase 1 — Grill Interview the user relentlessly until you reach shared understanding. Map the plan as a **design tree**: every decision branches into the decisions that hang off it. Work in **rounds**. The **frontier** is every decision whose prerequisites are already settled — what you can ask now without guessing at answers you haven't heard. A question that depends on another still-open question belongs to a later round, not this one. Every frontier node passes two gates, in order. Gate 1 asks whether the question deserves to exist at all; Gate 2 asks who owns it. Most bad questions die at Gate 1, and Gate 2 cannot catch them — routing decides who owns a genuine fork, it never asks whether the node is a fork at all. ### Gate 1 — Competence: does this question deserve to exist? Facts are your job, never the user's. Test every node with: > Would a staff engineer on this team need to ask this — or would they be embarrassed to? They'd be embarrassed to ask anything that is: - **Discoverable** — answerable from the codebase, the project's own docs, a dependency's or vendor's documentation, or the open web. - **Already answered** — stated earlier in this conversation, or in the plan, PRD, or issue you were handed. - **Testable** — settled by a read-only experiment: run the test, grep the tree, c