📛 Frontmatter: name + description
Every skill starts with a header. In grill-me, this frontmatter has two fields: name e description. The secret is in the description—it teaches the model when load the skill.
New here? Frontmatter is the metadata block at the top of a Markdown file, between lines of ---. A trigger (or trigger) is a situation that should trigger the skill.
--- name: grill-me description: Interview the user relentlessly about a plan, design, or topic, checkpointing every answer to a brainstorm file so nothing is lost. Use when the user wants to stress-test a plan, get grilled on a design, run a brainstorm or discovery session, extract what's in their head into a doc, or says "grill me". ---
🎯 The description is the doorway
Notice how specific and action-oriented the description is: "stress-test a plan," "get grilled," "discovery," "says grill me." The more situational it is, the more accurately it activates. A vague description means a skill that never fires.
The skill identifier.
The activation triggers.
"When" > "what it is".
Without it, no one joins.
✍️ Matt Pocock’s original version
The original skill, created by Matt Pocock, it’s disarmingly simple: four or five sentences. It proves that a skill doesn’t need automation — it needs the right instructions.
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk through every branch of the design tree, resolving dependencies between decisions, one by one. For each question, give your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead of asking.
🔍 What’s already here
- • Interview relentless until there’s a shared understanding.
- • Design tree + resolve dependencies one by one.
- • Recommended answer per question.
- • One question at a time.
- • Explore instead of asking when it can.
4–5 sentences are enough.
Without automation.
The entire method fits there.
The rest are additions.
🚫 The Checkpoint Rule
Here's the addition that defines the practical version: the checkpoint rule, marked as non-negotiable. After each response, before the next question, the skill appends to the file.
✓ The rule says
- ✓Structured append after each answer.
- ✓Only then does it ask the next question.
- ✓Fix earlier entries if something changes.
✗ The rule prohibits
- ✗Combine multiple answers into a single write.
- ✗Keep everything "in the model's head."
- ✗Wait for the user to ask you to save.
📌 Why "non-negotiable"
If the context is lost at any point, the file already contains everything said up to that point. Checkpointing after every answer is what makes that promise hold—so it's not "when you can," it's always.
Always, not sometimes.
Never in batches.
Reconcile inputs.
Nothing gets lost.
📁 Setup: brainstorms/ and the capture file
The setup’s golden rule: create the file BEFORE the first question. That way, even the first answer already has somewhere to go.
New here? One slug is a short version of a title with no spaces, used in a file name (e.g., "product packaging" → packaging).
Capture the date
Runs date +%F to name the file predictably.
Create the folder and file
Create brainstorms/ if it doesn’t exist and brainstorms/{data}-{slug}.md with the header.
Says where it saved it
Tell the user the file path in one line. Only then ask Q1.
$ date +%F 2026-06-22 # cria: brainstorms/2026-06-22-packaging.md
Before Q1.
Always brainstorms/.
Consistent name.
Transparency.
🗂️ Capture file structure
The file has a fixed structure of four sections. That structure is what makes it traceable and easy to turn into a deliverable later.
# {Topic}: Brainstorm / Discovery Notes
Date: {date} · Goal: {uma linha}
## Summary / key decisions
(síntese contínua, atualizada conforme avança)
## Q&A log
### Q1 — {tópico}
- Asked: {pergunta}
- Captured: {fatos, decisões, nas palavras dele}
- Flags: {item em aberto -> owner}
## Open flags (pending input)
- {item} -> {quem pode responder}
Title, date, goal.
Living synthesis.
In his own words.
Item → owner.
🔁 Simple vs. incremental
Why "break" a skill that was already working? Because in long interviews, context window fills up and the model starts forgetting what was said at the beginning. The incremental version trades simplicity for robustness.
Simple version (Pocock)
- ✓Very short, easy to read.
- ✓Great for short sessions.
- ✗In a long session, context fills up and loses detail.
Incremented version
- ✓Checkpoint to disk after each answer.
- ✓Handles interviews of 1h+ without losing anything.
- ✗Longer, more ceremony.
💡 "I deliberately destroyed the skill"
The variation came from a real pain point: in practice, the author kept finding himself manually asking, "save this, make a checkpoint" all the time. Building that routine into the skill solved the problem at its source.
Simplicity × robustness.
Why the checkpoint matters.
Handles long sessions.
Automate repetitive work.
💡 Skill = a prompt you don't want to repeat
Maybe the most liberating lesson in this path: a skill doesn't need to be a complex automation. It could just be a prompt you got tired of typing every time. That’s exactly what grill-me is.
🧭 How to recognize a skill candidate
- • You type the same instructions repeatedly.
- • There is a the right way of doing things that you always explain.
- • The task has fixed steps that are worth standardizing.
🎯 Tip
The next time you catch yourself pasting the same paragraph of instructions for the third time, stop: that's a skill waiting to be born.
It can just be text.
Don’t retype.
Capture what repeats.
Anyone can create.
🔗 Update skills and docs at the end
The session doesn’t end with the recap. grill-me notices that there’s a related guide or skill—with nuance you just discussed that isn’t in there—and offers to update both. That's how the output feeds back into your OS.
Detect the orphaned nuance
"I noticed you have a packaging guide and a packaging skill, and there’s a lot of nuance here that isn’t in them."
Offers to update
"Do you want me to update both?" You answer "yes" and the brainstorm becomes a permanent improvement.
The system gets smarter
Skills and docs get richer; the OS “knows more” about how you work.
Missing nuance.
Update skill/doc.
Output → context.
Conversation → improvement.
🛠️ Module summary
Next track:
Track 4 · Advanced — the prompts that trigger grill-me, the real difficulty of answering, and the grill-me + skill-creator loop.