Goal
Pressure-test a plan before execution so hidden assumptions, risky branches, missing approvals, and validation gaps become explicit decisions.
When to use
- The user asks to be grilled, challenged, or questioned before implementation.
- A migration, release, architecture change, or repo maintenance plan has unclear constraints.
- The user wants decision branches clarified before work starts.
When not to use
- Do not use when the user has already asked for implementation and the plan is clear.
- Do not use for passive code review; use the relevant review skill.
- Do not use to delay an urgent fix when the blocking decision is already known.
Inputs to inspect
- Inspect the plan, issue, PR, design doc, repo constraints, validation commands, and approval boundaries.
- Explore code or docs directly when a question can be answered from local evidence.
Inputs
- The proposed plan, design, checklist, issue, PR, or release notes.
- Repo constraints, workflow docs, validation commands, and known risks.
- User goals, deadlines, approval boundaries, and rollback expectations.
Process
- Restate the objective and the riskiest assumption.
- Ask focused questions that change the plan if answered differently.
- Group questions by decision branch, not by curiosity.
- Identify missing evidence, approvals, rollback plans, and validation.
- Convert answers into a tightened plan or explicit blockers.
- Stop when the next action is clear enough to execute or reject.
Workflow
Use the process above, asking one high-leverage question at a time. End with a tightened plan, explicit blockers, or a decision that implementation should not proceed.
Decision points
- If a question does not change the plan, omit it.
- If the plan can fail irreversibly, require an approval and rollback answer.
- If uncertainty is acceptable, mark it as a conscious risk instead of blocking.
Safety rules
- Do not perform implementation while grilling unless the user switches modes.
- Do not overwhelm the user with a long questionnaire; ask the highest-leverage questions first.
- Do not treat assumptions as decisions.
References
Read references/questioning-rubric.md when deciding which questions to ask first.
Scripts
No bundled scripts.
Output format
Return:
- Restated objective
- Highest-risk assumption
- Focused questions
- Decision branches
- Tightened plan or blockers
Completion criteria
- Key assumptions are explicit.
- The next execution step is clear.
- Remaining risks are accepted, mitigated, or blocked.
Failure modes
- If the user wants implementation instead, stop grilling and switch to execution.
- If a question can be answered from the repo, inspect the repo instead of asking.
- If the plan is too broad, recommend splitting it before continuing.