grilling
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 32
- Forks
- 11
01 前言 Front Matter
- name
- grilling
- description
- Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
03 SKILL.md 正文
Interview the user relentlessly until you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it.
Work the tree in rounds. The frontier is every decision whose prerequisites are already settled: the questions you can ask now without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Format a round like so:
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
---
❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one.
Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The decisions are the user's: put each to them and wait.
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
<!-- Vendored from https://github.com/mattpocock/skills (MIT, © Matt Pocock). -->
04 同仓库更多 Skills
wizard
Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.
ui-review
Senior UI/UX review of an ApplyPack dashboard page, screenshot, or primitive. Use when asked to critique, audit, or find improvements in the dashboard. Produces prioritized findings, never code.
testing-gate
Required verification per change type for ApplyPack (pure module → unit test, fetcher → smoke run, schema → hand-written migration, dashboard → rebuild + screenshot). Read before implementing any feature and before every commit.
stop-slop
Remove AI writing patterns from prose. Use when drafting, editing, or reviewing text to eliminate predictable AI tells.
resolving-merge-conflicts
Use when you need to resolve an in-progress git merge/rebase conflict.
release-discipline
Tag and GitHub-release rules for this repository — when a merge gets a version tag, how releases stay in parity with tags, and the release-notes format. Read after every PR merge, before tagging, and at the start of a new stage (parity check).