Grill Me

Grill Me

Not for

A decision already made and needing adversarial pressure belongs to challenge-decision, not a fresh interview. Ordinary implementation, delegation, routing-only work, and meta-discussion that merely names this skill do not trigger it.

Quick start

1. Confirm the artifact or planning target to grill (plan, design, PR, architecture notes, or inspected refactor target).
2. Build a decision tree of unresolved choices and dependencies.
3. Run a batched-question loop:
   • Identify unresolved questions that are independent (one answer does not change another).
   • If AskQuestion is available, inspect its live schema and batch no more than its documented per-call question cap.
   • If it is unavailable, ask a concise numbered conversational batch instead.
   • Provide a recommended answer option for each question.
   • Wait for the user response, resolve those branches, then repeat with the next batch.

Core behavior

• Interview relentlessly on substance, not tone.
• Resolve decisions in dependency order while batching independent branches in the same turn.
• Prioritize questions that unlock downstream decisions.
• Convert vague claims into explicit, testable decisions.
• Never batch questions where one answer affects another question.

For feature planning, only the owning plan-feature or build-feature coordinator applies this protocol to a native planner questions-required result. The controlled planner never calls AskQuestion; answers are returned through a fresh named draft Task. implement-feature never enters this interview.

When a caller uses this skill instead of a questionnaire

This skill resolves questions in the live turn. A controlled questionnaire resolves them in a saved, validated file that survives the session. That axis, the count-based router built on it, and the pairs it governs are defined once in QUESTION-ROUTING.md; the four-or-more route dispatches under DECISION-QUESTIONNAIRE-ORCHESTRATION.md.

refactor invokes this skill only on that router's one-to-three route. Ask that complete current inventory in one pass, return the decisions, and let the caller recalculate; never accept a subset peeled off a larger inventory to avoid the questionnaire. After the answers, return to refactor instead of extending the same pass with newly unlocked questions. The explicit grill-me front door and the existing feature, debugging, and optimization caller contracts are not governed by those counts.

write-lld is the one design caller with no questionnaire alternative at all. It routes every unit-level decision here whatever the count, so a pass carries the complete current inventory and the caller recounts after it.

Codebase-first rule

If a question can be answered by exploring the codebase, explore first instead of asking.

1. Check relevant code, docs, tests, and config.
2. State findings with file path evidence.
3. Ask only the remaining uncertainties as focused questions, batching only independent ones. Use clickable questions only when the active runtime actually exposes the required tool.

Prefer "I checked X and recommend Y" over asking for facts already available.

For a refactor run without a valid supplied approved plan, repository discovery and the caller's current question inventory happen first. Invoke this protocol only for the one-to-three route described above. A valid supplied refactor plan skips this protocol entirely. Other callers retain their own entry and completion contracts.

Decision tree branches

Traverse these branches in dependency order (adapt as needed):

1. Problem definition and success criteria
2. Users, workloads, and non-goals
3. Constraints (time, cost, platform, compliance)
4. Architecture, boundaries, and ownership
5. Data model, state, and lifecycle decisions
6. API/interface contracts and integration points
7. Failure modes, recovery, and operability
8. Security, privacy, and abuse resistance
9. Performance, scalability, and cost trade-offs
10. Delivery plan: tests, rollout, observability, and ownership

Question format (every turn)

The semantics shared with the questionnaire mechanisms — name the decision, ground every option, recommend exactly one, and never pad a choice list — are in QUESTION-ROUTING.md, which also records per runtime how cardinality and the free-form escape actually behave. This section is the AskQuestion rendering.

Before calling a question tool, verify it appears in the active tool list and read its current argument schema. Tool names, field names, question caps, option caps, and whether free-form "Other" is automatic can vary by runtime.

When AskQuestion is available:

• Batch independent questions only, never exceeding its live per-call cap.
• Give each question a stable branch id when the schema supports one.
• Include the concrete decision, why it matters, the recommended choice and rationale, and the main consequence of choosing differently.
• Offer concrete mutually exclusive choices using only fields accepted by the live schema. Include a recommended choice. Add an explicit "Other" only when the live tool does not add one automatically and its schema permits it.
• Use single-choice behavior when the schema supports it.

When AskQuestion is unavailable:

• Ask the same independent decisions as a short numbered list in ordinary conversation, with the recommended option first and labeled (recommended).
• Keep each item to the decision plus 2-3 concise choices; invite a short custom answer without pretending the choices are clickable.
• Respect a readable batch size (normally at most three) and wait for answers.

After the user responds, resolve answered branches, unlock downstream dependencies, and repeat with the next batch.

Then stop and wait for the answers.

Completion criteria

For the explicit front door and callers whose own contract expects a complete interview, stop only when all critical branches are resolved and shared understanding is explicit. Close with:

• final decisions
• explicit assumptions
• open risks and mitigations
• next validation steps

This closing decision record is the hand-off to the consuming planning skill. The consumer renders its domain artifact from the record and must not start a second generic interview.

For the hybrid refactor route, pass completion instead means returning the decisions for the complete supplied inventory. The caller, not this pass, rebuilds the inventory and routes any newly exposed material question. Do not claim overall decision closure until the caller's recalculated inventory reaches zero.

Writing style

Question stems, recommendation rationale, and the closing decision summary follow writing style. Name the decision, why it is material now, and what changes if the user picks differently. Do not pad a choice list to a count.