Grill plan
Skill honerlaw/agent-marketplace/plugins/minerva/skills/grill-plan
A personal plugin marketplace for AI coding agents. Each plugin provides skills and automation scripts.
npx -y skills add honerlaw/agent-marketplace --skill grill-planAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when a plan has just been drafted in conversation and needs stress-testing before approval — invoked by `minerva:propose` after approach selection and by `minerva:replan` after the new-plan brainstorm, also usable standalone on any drafted plan. Interviews the user relentlessly about the drafted plan, one question at a time, with the LLM's recommended answer leading each question, until shared understanding is reached.
SKILL.md
3.3 KB, 646 tokens by cl100k_base, as published. Nobody here has run it
Stress-test a drafted plan by interviewing the user about it until shared understanding is reached. Modeled on mattpocock/skills' productivity/grill-me.
Inputs
A plan is already in conversation context. It may be:
- A
minerva:proposedesign draft (Goal / Why / Approach / Success criteria / Open Questions), not yet written to disk. - A
minerva:replanentry draft (Original plan / What changed / New plan), not yet appended toreplan.md. - An ad-hoc plan the user has shared or pointed at (e.g., an existing
proposal.mdthey want re-grilled).
No flag distinguishes these — read the conversation and act on whichever plan is in front of you.
Protocol
Walk down the decision tree of the drafted plan one question at a time, resolving each branch before moving on.
-
Ask one question at a time. Never batch. Wait for the user's answer before asking the next.
-
Lead with your recommended answer. For every question, state what you think the answer is based on the draft and project context, then ask the user to confirm or correct. Example: "The Approach says X. I'd expect this means Y because Z — is that right?"
-
Prefer codebase exploration over asking. If a question can be resolved by reading code,
.minerva/knowledge/, prior proposals, or other repo files, do that instead of asking the user. Only ask when the answer genuinely lives in the user's head. -
Push on the load-bearing parts. Probe assumptions the plan is leaning on, ambiguities a reader could resolve two ways, success criteria that aren't objectively checkable, edge cases the Approach doesn't address, scope that might be drifting. Don't run a fixed checklist — let the plan itself tell you what to probe.
-
Edit the draft as you go. When an answer shifts the plan, update the affected draft sections in place in conversation memory before continuing. The plan that exits this skill is the plan that gets approved and written, so it must already reflect everything surfaced here.
-
Stop when shared understanding is reached. Termination conditions:
- You judge that no further material gaps remain.
- The user signals stop: "good enough", "stop grilling", "ship it", "move on", or similar.
- The user says the draft is ready to proceed (distinct from the formal per-section approval the caller skill will run next — this is just a "done grilling" signal).
When you stop, summarize what changed in the draft (if anything) and hand control back to the caller skill.
Out of scope
- File writes — the caller skill (
minerva:propose,minerva:replan) owns persistence. - Approval gates — the caller skill runs its own approval flow after this skill returns.
- Scope re-decomposition — if grilling reveals the plan should be split into multiple work units, surface that to the user and return; the caller decides how to handle it.