grill-me
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
If invoked with a file path argument, Read that file first and use its contents as the plan to grill. Do not rely solely on conversation context — always read the plan from disk when a path is provided.
Rules
ALWAYS use the AskUserQuestion tool for every question you present to the user. Never fall back to plain-text questions with "A/B/C" or "y/n" — every decision MUST be cursor-selectable via AskUserQuestion.
- Ask ONE question at a time. Never batch multiple decisions into one message. Never emit multiple AskUserQuestion calls in one turn.
- Provide 2-4 options per question. Your recommended answer should be the first option with "(Recommended)" in the label.
- Each option needs a clear
descriptionexplaining the trade-off or implication — not just a label. - After each answer, briefly acknowledge the choice (1 sentence max) before presenting the next question. This prevents a rapid-fire feeling and confirms the decision was captured.
- If a question can be answered by exploring the codebase, explore the codebase INSTEAD of asking the user. Use Grep, Glob, Read, or Agent to verify assumptions before grilling on them.
- If the user says "enough", "done", "stop", or "skip the rest", announce "Grill complete." with decisions captured so far and exit.
- When all decision branches are resolved, announce "Grill complete." with a numbered summary of all decisions captured.
More from bhagyamudgal/skills
review-pr
Deep, anti-slop review of a GitHub PR. Grounds findings in the linked issue's intent, runs a Claude reviewer (+ conditional silent-failure hunter) in parallel with existing CodeRabbit comments fetched from the PR, then critic-passes the findings before printing. Use when user says "review this pr", pastes a GitHub PR URL, or asks "check this pull request". NOT for local uncommitted changes — use /parallel-review for those.
14fix-pr-review
Triage and fix CodeRabbit / review-pr findings on a GitHub PR, then reply + resolve conversations. Classifies each finding (FIX/DISMISS/DEFER/DISAGREE/NEEDS-INPUT), runs /done, posts specific replies. Use on CodeRabbit review URLs, PR URLs, or local review files. Pairs with /review-pr.
8harden-plan
Pre-code quality gate that runs /review-pr's anti-slop lens against a written plan BEFORE any code is written. Grounds the plan against the real codebase, runs 11 category checks (security, concurrency, round-trip, control-flow, error-handling, pattern-consistency, plus /review-pr's Q1-Q6), then grills the user one question at a time until the plan is hardened. Use when the user says "harden my plan", "check my plan", "grill my plan before I code", "lint this plan", or invokes `/harden-plan` explicitly. Also invoke proactively after `/superpowers:brainstorm` or `/grill-me` completes with a written plan and before any implementation begins. Do NOT invoke after coding has started — redirect to `/review-pr` / `/fix-pr-review` in that case.
8forge-plan
Use when starting any non-trivial feature or design task that needs the full idea-to-implementation pipeline. Also use when user says "forge", "forge plan", "full pipeline", or wants the complete AI development workflow before shipping.
6project-discovery
Deep project discovery and architecture planning. Use when starting a new project, when user says "new project", "let's build", or asks for help architecting/planning a non-trivial application.
6qa
Use when user says "qa", "test the flow", "QA this", "verify the UI", "test this page", "check if it works", "end-to-end check", or after completing code changes that affect UI and need manual verification replaced by automation.
5