📖 Living glossary (read first — come back whenever you need to)
This learning path is "ready to copy." Here we define the NEW terms in this module. The fundamentals (model, agent, skill, prompt) are already covered in Path 1 — if you forget them, go back there.
🗺️ Pipeline overview
🧠 Imagine it this way: A restaurant kitchen. First the waiter interviews you ("with fries? medium rare?") until the order is unambiguous. Then that becomes a typed command (the document). And the command is broken down into stations (grill, salad, dessert) — each cook gets their own. The idea in your head has become organized work, without you going to the stove.
This module is at the heart of how Matt Pocock delegate without losing control. Instead of one giant skill that does everything, it chains three small skills in a pipeline: grill-me → two-PRD → to-issues. As he sums it up in the transcript: “chain together: grill-me → two-PRD → to-issues"—this keeps “most of the AI descriptions hidden and the knowledge with the human.” Each step has just one job, and you approve it before moving to the next.
The path is literal: you leave the "brain" (the raw idea) and arrives at "backlog" (a queue of ready-to-go issues). The reason to break it into three: Pocock prefers procedures letting the model decide everything — "I know my skills, I don't want to delegate my thinking" ("I know my skills, I don't want to delegate my thinking"). Each link is a point where you can stop, correct, and continue. The common mistake the trap is trying to create one mega-skill that goes "from idea to code" without any stops: you lose visibility, and the AI fills in the gaps with wrong assumptions.
Three small skills in a row outperform one mega-skill that does everything: you can see and correct each link.
⚠️ Common beginner mistake
Trying to get “one skill that takes you from idea to deploy.” Without stops, the AI makes every decision on its own, and you only discover the errors at the end. The pipeline exists precisely to give you a “pause” button between each step.
In one sentence: the pipeline takes the idea to the backlog in three steps, with you approving each link—no black-box mega-skill.
🔥 Step 1 — grill-me
🧠 Imagine it this way: an experienced lawyer before taking your case. They don't say "ok, understood" — they questions: “what if X happens? did you consider Y? why not Z?” By the end, you both see the case the same way. grill-me does this with your product idea.
A grill-me turns the model into a adversarial interviewer: it asks questions, raises ideas you hadn’t considered, and keeps going until it reaches a shared understanding. Pocock calls it “unreasonably effective.” You use it as a substitute for the plan mode: “here’s my idea; interview me, let’s reach an understanding and work out the quirks before implementing it.”
The exact text of the skill (from the transcript): "Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead." Notice two golden rules: one question at a time (doesn’t drown you) and if the code can answer the question, it looks at the code instead of asking. The common mistake: answer automatically. Grill-me is only worthwhile if you fight back—disagree with its recommendations when it makes sense.
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead.
"Walk down each branch of the design tree" — one question at a time, resolving dependencies.
In one sentence: grill-me interviews you one question at a time until you and the AI see the plan the same way.
📄 Step 2 — two-PRD
🧠 Imagine it this way: after discussing the home renovation with the architect, he turns the conversation into a signed blueprint. It’s no longer “guesswork”—it’s become a document the builder can read and follow. The two-PRD turns your interview into that blueprint.
The grill-me interview is in the context from the conversation—but conversation isn't a deliverable. The PRD is the product of this step: a structured document that says what build, why, e which requirements. The skill two-PRD reads everything agreed on in the interview and writes this document for you — vision, consequential decisions, requirements, and acceptance criteria.
Why write a PRD instead of going straight to the code? Because the PRD is a reviewable artifact: you read it, adjust a sentence, delete a requirement you don’t want—before a single line of code exists. It fits perfectly with David’s favorite prompt mentioned in the transcript: "describe my vision, list out the 10 most consequential decisions (software design / architectural / product) that will shape this project, and interview me until you understand 98%" — describe my vision, list the 10 most consequential decisions, and interview me until you understand 98%. Those 10 decisions become the backbone of the PRD. The common mistake: accept the first PRD without reading it. It’s your draft to edit—not a final verdict.
🔬 Worked example: “notes app with reminders” becomes a PRD
You run /grill-me with the raw idea. The AI asks one question at a time: "reminders at a set time or based on location? Syncs across devices? Offline-first?". You answer and disagree in one go (“no, no geolocation in v1”). Then you run /two-PRD. Here’s what you get:
## Vision — capture quick notes and be reminded at the right time.
## Consequential decisions
1. Reminders only at fixed times (geolocation can wait for v2).
2. Offline-first, background sync.
3. No login in v1 — local data.
## Requirements — CRUD for notes; schedule/cancel reminders; local notification.
## Acceptance criteria — the note persists after closing the app; the reminder fires within ±1 min.
Notice: each "consequential decision" is a choice you confirmed in grill-me. The PRD just formalized it.
Going deeper (optional): why a PRD and not an informal plan?
A plan that lives only in chat disappears when the context fills up or you run /clear. The PRD is a file: versionable in git, open to comments, and—crucial for the next step—something the skill to-issues can read consistently. Pocock prefers solid artifacts between pipeline links precisely so each skill has a predictable input, not "whatever was left from the conversation".
In one sentence: two-PRD distills the interview into a reviewable document — the product blueprint, before the code.
🎫 Step 3 — to-issues
🧠 Imagine it this way: the entire order ticket is split into slips for each station — one goes to the grill, another to the salad station, another to the bar. Each cook takes their slip and gets to work. to-issues splits the PRD into slips (issues) that an agent can pick up from the queue.
O to-issues reads the PRD and creates issues on GitHub—one per executable piece. This connects to how Pocock thinks about the work: "I mostly think about these as QUEUES, not loops" ("I think of this as queues, not loops"). The backlog is this queue: “all development is just a queue of tasks: PMs add to the queue, you complete them; multiple nodes (devs) pick off the queue”. Here, the “nodes” can be agents.
The detail that turns this into automation is the labels (labels). In the actual transcript example (frame 74), the issue #795 walks through the labels agent:explore → agent:in-progress, and the GitHub Actions bot posts a “Triage” with TL;DR + Difficulty. In other words, the issue isn’t just a note—it’s a trigger. The common mistake: create huge, vague issues (“build the app”). The trick is to break them down enough for an AFK agent to pick one up a and finish.
Title: Agendar e cancelar lembrete de uma nota Labels: agent:explore, area:reminders, size:S ## Contexto (do PRD) Decisão #1: lembretes só por horário fixo na v1. ## Tarefa - Permitir definir um horário para uma nota existente. - Agendar uma notificação local nesse horário. - Permitir cancelar o lembrete. ## Critério de aceite - Lembrete dispara em ±1 min do horário definido. - Cancelar remove a notificação agendada.
In one sentence: to-issues splits the PRD into issues with labels — a backlog (queue) ready for agents to pick up.
⛓️ Complete chaining
🧠 Imagine it this way: an assembly line with three stations and an inspector (you) between them. The part doesn’t move to the next station until the inspector gives the “OK.” It’s fast, but no one pushes defects forward.
Now we put it all together. This is the actual sequence of commands of the pipeline—that’s what you actually type in Claude Code, with what each step produces noted down. Copy it, adapt the names to your project, and run it. Remember: between one / and the next one, you read and approve. It’s not one button that does everything—it’s three buttons with you in the middle.
# PIPELINE: do brain ao backlog (Claude Code, Opus 4.8 medium) # --- PASSO 1: grill-me --------------------------------------- # voce cola a ideia crua e invoca a skill de entrevista /grill-me > Ideia: app de notas com lembretes por horario. Me entreviste. # PRODUZ: um entendimento compartilhado (Q&A na conversa). # -> VOCE APROVA antes de seguir. # --- PASSO 2: two-PRD ---------------------------------------- # transforma a entrevista alinhada num documento de produto /two-prd # PRODUZ: docs/PRD.md (visao, 10 decisoes, requisitos, aceite) # -> VOCE LE e edita o PRD.md antes de seguir. # --- PASSO 3: to-issues -------------------------------------- # le o PRD e cria as issues no GitHub, uma por tarefa /to-issues docs/PRD.md # PRODUZ: issues no GitHub com labels (ex.: agent:explore, size:S) # -> VOCE revisa o backlog; ajusta labels/prioridade. # RESULTADO: brain -> backlog. Agentes AFK pegam da fila.
Quick retrieval: what is the correct pipeline ORDER?
In one sentence: three skills in a series with a human checkpoint between each one — you delegate the work, not the thinking.
🧑✈️ Where the human fits
🧠 Imagine it this way: the medieval king (David's analogy in the transcript). He won't personally fight every battle—but problems come to him (invasion, famine, an alliance proposal), and it prioritizes: 50 problems, only 3 critical. It delegates execution, never control.
What distinguishes Pocock's method from "letting the AI take the wheel" is where the human stays. They prefer procedures a abilities precisely to stay “in the driver's seat”: “I want to be in the driver's seat, not delegate my thinking” (“I want to be in the driver's seat, not delegate my thinking”). In the pipeline, you are present in each link: you launch grill-me, push back on the answers, edit the PRD, and prioritize/adjust the issues.
But—and this is the AFK insight—the human stays in the checkpoints, not typing. How Pocock thinks about queues: you prioritizes and reviews, while agents pick up issues and execute them. The goal is to "push human-in-the-loop checkpoints further toward the final output" (move human checkpoints closer and closer to the final output), from the transcript. The common mistake is the opposite extreme—becoming a bottleneck by wanting to review every character. The goal isn’t to be involved in everything; it’s to be involved at the few the points that determine the direction. The knowledge lives in you; execution scales through agents.
Quick recall: why does Pocock prefer "procedures" in the pipeline?
In one sentence: the human stays at the few checkpoints that decide the direction—delegate execution, never command.
🧾 Module Summary
Next module:
5.4 — Complete AFK Setup: Claude Code + Opus 4.8, sandboxes (Sand Castle), and how to pull the commits back.