Stats
Actions
Tags
From king-skills
Interview the user relentlessly about a plan, design, or decision until you reach shared understanding. Walk down each branch of the decision tree, resolving open questions one at a time. Use when the user wants their plan stress-tested, says "grill me", asks you to poke holes, or hands you a draft they want pressure-tested before shipping. For open exploration where there isn't a plan yet, use `/brainstorming` instead.
How this skill is triggered — by the user, by Claude, or both
Slash command
/king-skills:grill-meThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Interview me relentlessly about every part of this plan until we reach a shared understanding. The goal is to expose every assumption, force a resolution on every open question, and end with a plan that's actually executable — not a plan that just sounds good.
Interview me relentlessly about every part of this plan until we reach a shared understanding. The goal is to expose every assumption, force a resolution on every open question, and end with a plan that's actually executable — not a plan that just sounds good.
You're here because I have something I want stress-tested. It's usually one of these:
If I haven't told you what we're grilling, ask me. One sentence is enough: "What are we grilling?"
If I don't have a plan yet — I'm still thinking through what to even do — stop and tell me /brainstorming is the better fit, then route there.
One question at a time. Never bundle. I should be answering one thing per turn.
Walk the decision tree. Start at the biggest open question. Resolve it. Then move to the next branch that opens up. Don't skip ahead to small stuff while a big assumption is still unresolved.
Recommend an answer with every question. Don't ask blank-canvas questions. Tell me what you'd pick and why, then ask if I agree or want to push back. Use AskUserQuestion with 2-4 options when the question is multiple-choice; your first option is always your considered recommendation, suffixed "(Recommended)". The tradeoff goes in the description so I can see what each pick costs.
Read before asking. If the answer is sitting in a file I've already written — a README, a planning doc, project notes, a prior decisions log — read it instead of asking me to repeat myself.
Push back when warranted. If I say something that contradicts an earlier decision, something already written down, or basic reality, name it. Don't pretend I'm consistent when I'm not. Don't ask leading questions — ask the real one.
Capture as we go. When I lock an answer, repeat it back in plain English so I can confirm. Don't move on until I've signed off on that branch.
You're done when:
If we hit a question that needs outside input — a vendor's pricing page, a tool's docs, my calendar — pause the interview, fetch the info, then resume.
If the grilling reveals the plan is wrong and I need to start over, say so. Don't keep grilling a broken plan to look productive.
At the end of the grill, summarize:
If the grill produced enough material for a real plan document, ask whether to write it to a PLAN.md in the project folder. If it produced a decision worth keeping, offer to save it to a decisions log (newest at top).
npx claudepluginhub beltdoor/claude-skills --plugin king-skillsProvides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.