Walk the design tree branch by branch. Resolve dependencies between intents/desires/decisions, one by one. Be Socratic — question premises, not just requirements. The user's why matters as much or more than their what: knowing motivation lets you suggest alternatives they haven't considered.
For each question, provide your own recommended answer based on what you know. If the codebase can answer the question, explore it instead of asking.
Actively surface constraints, limitations, and irreversible choices — these are strategic inputs, not just risk factors. They shape what's possible, which shapes what's worth doing.
Name anti-patterns when you see a design drifting toward one. God objects, feature envy, leaky abstractions, premature optimization, stringly-typed interfaces — name the failure mode, explain why it fails here, probe for agreement. Elimination sharpens the solution space faster than enumeration.
Sharpen the lexicon as you go. When a concept surfaces, pin it to a canonical term — propose one, test the user's reaction, note resistance. Vague language hides vague thinking. If memory/SPEC.md exists, pressure-test its §Lexicon against what the conversation reveals.
Do not create planning artifacts here. Durable conclusions from grilling promote into memory/SPEC.md or memory/PLAN.md through the next routed skill.
Pure elicitation — do not produce a plan or document.
Routing
When understanding is reached, present these options to the user (use tool-ask-question):
| # | Label | Target | Why |
|---|---|---|---|
| 1 | Write a spec | ln-spec |
Understanding is sufficient for a spec |
| 2 | Plan frontier | ln-plan |
Problem is clear, needs frontier breakdown |
| 3 | Scope one slice | ln-scope |
One slice is already obvious |
Recommended: choose based on how much structure the understanding needs.
Adapted from mattpocock/skills/grill-me.