This entry is a synthesis inspired by the linked /grill-me video and expanded with Matt Pocock’s skills repo: a 15-slide teaching artifact for using AI agents without surrendering design decisions. The key pattern is simple: let the agent interrogate the human first, freeze the decisions into a spec, cut vertical tickets, execute with TDD, review against both code quality and the spec, then write the workflow down as reusable agent discipline.
Source basis: linked video — “700 萬人下載的 /grill-me,Matt Pocock 到底寫了什麼?”; mattpocock/skills repo snapshot; public AIHero pages on /grill-me, grill-with-docs, and “My ‘Grill Me’ Skill Went Viral”; internal deck generated from transcript-derived notes, repo inspection, and visual chapter sampling. The “700 萬人下載” phrase is part of the video title, not a usage metric independently verified here. Visual chapter sampling was used to match the deck’s visual rhythm, not as a comprehensive factual audit.
Framing note: the post intentionally separates three layers: video inspiration, repo-grounded skill behavior, and LearnAI workflow synthesis. Treat the pipeline below as a teaching pattern derived from those sources, not as a verbatim workflow prescribed by the video.
Download the Deck
| Format | Link | Notes |
|---|---|---|
| grill-me-ai-workflow.pdf | Best for reading and sharing | |
| PPTX | grill-me-ai-workflow.pptx | Image-based slides with prompt notes, not fully editable text/shapes |
Why This Deserves a Separate Post
The existing grill-me wiki entry explains the skill itself. This post is different: it captures a workflow that can be taught, practiced, and reused.
The video’s useful angle is not just “/grill-me asks questions.” It is that a good AI development loop separates decision work from execution work:
grilling -> to-spec -> to-tickets -> implement -> tdd -> code-review
|
v
writing-for-agents
That matters because many practical AI coding failures are not caused by the model being unable to write code. They come from letting the model silently decide product behavior, edge cases, architecture boundaries, and testing standards before the human has noticed those decisions exist.
AIHero Clarification: What /grill-me Is For
The public AIHero pages make the role of /grill-me sharper than the video alone. /grill-me is best understood as the entry-point questioning loop: it is portable, stateless, and useful even when there is no repo. Its job is to turn a vague plan into explicit decisions by asking questions, exploring the codebase only when that helps answer a question, and giving the user a recommended answer to accept, reject, or edit.
That means /grill-me is not the whole build workflow. It is still valuable whenever uncertainty is high, including later in a project, but its main output is clarified context. In the AIHero framing, if the work is software, the same conversation can then move into to-spec. In this post’s LearnAI framing, that is where the build workflow begins.
Use grill-with-docs when repo-grounded continuity matters: it runs the same interview style, but reads the codebase and records what it learns as durable artifacts such as CONTEXT.md and ADRs. Use wayfinder when the effort is too large for one grilling session. Use a prototype when the question is not really answerable by talking, such as an interaction feel or layout choice.
The Workflow
1. Start With Grilling
/grill-me is the public-facing hook. In the repo snapshot used here, grill-me is a small wrapper that runs a /grilling session. The important behavior is decision-tree discovery: each answer exposes the next layer of decisions.
Use this before implementation when the idea is still fuzzy:
- Who is the user?
- What are the failure modes?
- What data exists already?
- What can be out of scope?
- What should the agent not decide alone?
The recommended-answer mechanic is crucial. A question without a recommendation can stall the human. A recommended answer gives the human something concrete to accept, reject, or modify.
2. Freeze Decisions Into a Spec
to-spec turns the conversation into a stable artifact. The point is not to dump code paths into a document. The point is to preserve problem framing, user stories, implementation decisions, and testing decisions before the chat context gets fuzzy.
Good spec behavior:
- records decisions that should survive the session
- avoids stale implementation detail unless needed
- captures testing seams before code is written
- gives future agents a source of truth
3. Cut Vertical Tickets
to-tickets is valuable because it discourages horizontal slicing.
Bad split:
database -> backend -> frontend -> tests
Better split:
login slice -> schema + API + UI + tests
checkout slice -> schema + API + UI + tests
export slice -> schema + API + UI + tests
Each ticket should be a small proof that the system works through the stack. That gives the agent a narrower frontier and gives the human something real to inspect.
4. Execute, But Keep Feedback Loops Tight
implement should not re-plan the product. It should execute a settled spec or ticket.
The guardrails come from two companion skills:
tdd: write tests against public behavior first, then implementcode-review: review on two axes, code standards and spec compliance
This is the core anti-vibe-coding lesson: the agent can execute quickly, but the proof has to come from tests, review, and the spec, not from the same model saying its own output looks good. TDD only helps here when tests are derived from the spec or worked examples before implementation; weak tests written first are still weak tests.
5. Use Architecture Maintenance as a Recurring Loop
The architecture lesson I take from the video’s later section is that agent workflow and module design are connected. AI agents are easier to constrain when important behavior sits behind clear interfaces instead of being spread across many shallow modules with implicit coupling. Deep modules are easier to reason about because a smaller interface hides real complexity.
The architecture maintenance idea here uses deletion-test thinking: if removing a module makes complexity leak everywhere, it may be hiding useful complexity; if removing it makes the system clearer, it may be a shallow middleman.
This should be a recurring maintenance loop, not an emergency refactor:
review diff -> inspect architecture pressure -> identify deepening opportunities -> grill the proposal -> refactor only after the decision is clear
6. Turn the Workflow Into Agent Writing
writing-for-agents is the meta-layer. A workflow that lives only in one chat dies with that chat. A workflow written as a skill, project rule, or compact instruction becomes reusable.
The writing lesson is compression, not verbosity:
- give the agent a context pointer
- use leading words that trigger known behavior
- define completion criteria
- prune no-op instructions and repetition
This is why the deck ends with writing-for-agents: a good AI workflow should eventually become something the next agent session can load.
Workflow Tradeoff: Superpowers vs Small Skills
Slide 14 introduces Superpowers as a useful contrast with Matt Pocock’s smaller composable skills. The point is not that one approach always wins. Heavier workflows can help when the operator needs a complete guardrail system. Small skills are better when the operator already understands the task and wants a flexible control surface.
For teaching, that contrast is useful: students should learn to ask whether they need a production line or a toolbox before installing another agent framework.
Teaching Use
This deck works well as a 30-45 minute workshop:
| Segment | Activity |
|---|---|
| 5 min | Show why vague prompts outsource hidden decisions |
| 10 min | Run a live /grill-me or /grilling session on a small feature |
| 10 min | Convert the decision tree into a spec and vertical tickets |
| 10 min | Show how TDD and code review constrain agent execution |
| 5 min | Ask students to write one reusable agent instruction from the workflow |
The goal is not to make students memorize Matt Pocock’s skills. The goal is to teach the operating discipline: decide deliberately, execute narrowly, verify independently, then preserve the workflow.
Slide Gallery
References
- “700 萬人下載的 /grill-me,Matt Pocock 到底寫了什麼?”, YouTube video.
- Matt Pocock — “My ‘Grill Me’ Skill Went Viral”, AIHero.
- Matt Pocock — “The /grill-me Skill”, AIHero.
- Matt Pocock — “grill-with-docs: Align Before You Build”, AIHero.
- Matt Pocock — “The /to-spec Skill”, AIHero.
- Matt Pocock — “The /wayfinder Skill”, AIHero.
- mattpocock/skills, repo snapshot used here:
84fdeffd12f2ee307994d1eb6feb48173b6e0502. - Upstream skill files consulted:
grill-me,grilling,to-spec,to-tickets,implement,tdd,code-review,improve-codebase-architecture, andwriting-for-agents. - Related LearnAI entries: grill-me — When AI Interviews You Before Writing Code, Matt Pocock’s Skills — Claude Code for Real Engineers, AI Slide Generation with Claude Code.