ad-grill-me

<background_information> Implements ADR-0022 — the upstream-of-research phase. Process scaffold for sharpening fuzzy asks before any code, research, or spec work begins. Sits upstream of ad-ground; routes to it (and the other implementation-phase skills) when the question is sharp enough to act on.

No primary file output. Side-effects land in CONTEXT.md (via ad-domain) and ADRs (via ad-adr) — both lazy, both belonging to other skills.

Codex auto-trigger on description keywords is less mature than Claude Code's. If auto-invocation does not fire when the user mentions grilling, interview, fuzzy ask, or "stress test the plan", invoke this skill manually. </background_information>

Route elsewhere when:

• The question is sharp and research-ready → ad-ground (WORKFLOW §4 + §5).
• The technique is known and the ask is implementation-strategy choice → ad-tdg (WORKFLOW §9).
• The technique itself is uncertain across multiple plausible approaches → ad-spike (WORKFLOW §14).
• The ask is "this is broken" / "fix this bug" → ad-diagnose (WORKFLOW §15).

A well-scoped routine ask ("rename foo to bar everywhere") does not need grilling — just do the work.

Step 1 — codebase-first. Before asking a single question, look. Most "what does this do?" questions are answered by the code.

Process:

1. Read CONTEXT.md if it exists. Anchor vocabulary first; nothing else makes sense without it.
2. Read CONTEXT-MAP.md if it exists; load the per-context glossaries that match the surface.
3. Glob / Grep the surface the question touches — file names, function names, the user's nouns and their plausible aliases.
4. Read the matched files in the order most likely to answer the surface question.

Only after the codebase pass produces no answer does the skill ask the user.

Step 2 — one question at a time. Each question:

• Stands alone. Self-contained, no "and also...". Never a numbered list of three.
• Carries a recommended answer. The user can confirm with one word.
• Walks the decision tree. Resolve the parent decision before its children.
• Waits for feedback. No proceeding past an unanswered question, no parallel branches.

Format:

[Branch: data model]
Q1: Should an Order own its Line Items, or should Line Items reference an Order by id?
Recommendation: Order owns Line Items. Locality wins — partial cancellation is the only operation that crosses the boundary, and it stays inside the aggregate.

After the user answers, the next question follows from the answer (depth-first), not from a pre-planned list.

Step 3 — challenge, sharpen, scenario-test. Three discipline patterns; mix as the conversation needs.

Challenge against the glossary. When the user's term conflicts with an entry in CONTEXT.md, surface the conflict immediately:

"Your glossary defines Cancellation as full-order rollback, but you said partial cancellation is in scope — which is it? If both, are they the same domain concept or two distinct events?"

Sharpen fuzzy language. When the user uses a vague or overloaded term, propose the canonical resolution:

"You're saying 'account' — do you mean Customer or User? Those are different things in this codebase: Customer carries billing, User carries auth. Which one drives this requirement?"

Scenario-test relationships. When two concepts interact, invent a concrete edge case that forces precision:

"Concrete scenario: a Customer cancels Order #42 while the warehouse is mid-pick on Line Item 3. Who decides whether the in-flight pick continues?"

The scenarios are fabricated, not historical. Their job is to expose the boundary.