ce-grill

name	ce-grill
description	Clarify and stress-test a requirements doc, plan, design, or rough approach through a focused interview. Use when the user wants to be grilled, or before ce-plan when the requirements are too branchy, ambiguous, or strategically important to plan cleanly.
argument-hint	[requirements doc path, plan path, or topic to stress-test]

Planning Clarity Gate

Interview me relentlessly about every aspect of this plan until every branch of the design tree has a resolved decision or an explicit deferral — the same readiness bar the Handoff section applies below. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase, explore the codebase instead. Use repoprompt when that codebase question is broad, unfamiliar, or crosses multiple owner boundaries; keep the result as context for sharper questions, not as a plan.

Loop Role

ce-grill is the clarity gate before planning, not a replacement for planning. Use it before ce-plan when the input has:

• unresolved scope or success criteria
• competing product directions
• hidden stakeholder or user-flow assumptions
• broad standard/deep work where the next decision affects many downstream units
• a requirements document that feels technically plannable but product-shaky
• a chosen approach or existing architecture that may itself be the constraint, not a fixed base to build on

Do not use it for narrow, already-clear implementation tasks. Let ce-plan handle one or two ordinary clarifying questions directly.

Stress the Frame, Not Just the Details

Grill whether this is the right approach at all, not only whether its parameters are tuned. If the difficulty traces back to an existing structure or a settled prior decision, put that decision back on the table — ask whether you would arrive here building it fresh today, and weigh replacing it by resulting complexity, not by how much already exists. A wrong turn already taken is not a reason to keep walking; name it and let the user choose to reopen it.

Handoff

When the interview is done, return a compact handoff:

• Resolved decisions - what is now settled
• Remaining open questions - only blockers that still prevent planning
• Recommended planning input - the exact summary or requirements path to pass to ce-plan
• Ready for ce-plan - yes/no, with the reason

Do not write the implementation plan here. Recommend the next step gated on that readiness verdict:

• Ready: yes. Recommend ce-plan with the recommended planning input. When the caller asked to continue the loop, invoke ce-plan directly rather than just naming it. When this was a standalone grill, offer the choice via the platform's blocking question tool (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini, ask_user in Pi (requires the pi-ask-user extension)) — in Claude Code call ToolSearch with select:AskUserQuestion first if its schema isn't loaded — and fire the selection. Fall back to a numbered chat list only when no blocking tool exists or it errors.
• Ready: no. Recommend resolving the remaining blocker — return to the open question rather than routing to ce-plan. Do not force planning.

Always leave a Done for now path that ends the turn without planning.