Pocock Skills · Lesson 02 · Methodology

The engineering flow, end to end

idea → ship: the one path most work travels, and where each skill sits on it.

Lesson 01 gave you four failure modes. This lesson gives you the main flow — the route that turns an idea into shipped code while defending against all four at once. Pocock keeps this map in a router skill, ask-matt ("you don't remember every skill, so ask"), and it's worth internalizing as a single sentence before we break it apart:[askmatt]

The main flow. grill-with-docs → (maybe prototype) → to-spec → to-tickets → implement (which drives tdd internally, then code-review) → commit. Two on-ramps feed onto it (triage, diagnosing-bugs); a huge foggy effort starts at wayfinder and merges back in at to-spec.

Walking the flow

1. Sharpen the idea — grill-with-docs

Start here when you have a codebase. It's a relentless grilling session — the agent interviews you — and it's stateful: what it learns lands in CONTEXT.md (shared language) and ADRs (hard-to-reverse decisions). That single skill attacks failure mode #1 (misalignment) and #2 (verbosity) together. No codebase? Use grill-me — same interview, but stateless, leaves no paper trail.[askmatt]

2. Branch — can you settle every question in conversation?

If a question needs a runnable answer — a state model, some business logic, a UI you have to see — you detour through prototype (throwaway code, keep the answer, delete the demo), bridged in and out by handoff so the fresh prototype session doesn't pollute your main thread. Otherwise, straight on.

3. Branch — is this a multi-session build?

Yes → spec & tickets

to-spec turns the thread into a spec (PRD), then to-tickets splits it into tracer-bullet tickets, each declaring its blocking edges. Then one implement per ticket — clearing context between each.

No → implement here

Skip spec and tickets. Run implement right in the same context window while the grilling is still fresh in memory.

Either way, implement builds each unit by driving tdd internally — one red-green slice at a time — then closes out with code-review before it commits. That's failure mode #3 (broken code) and #4 (ball of mud) handled inside the last step.

Two ideas from to-tickets worth their own memory slot: tracer-bullet vertical slice — each ticket cuts a narrow but complete path through every layer (schema → API → UI → tests), demoable on its own, sized to fit one fresh context window. And the wide refactor exception — a mechanical change whose blast radius breaks thousands of call sites can't be a vertical slice, so it's sequenced expand → migrate in batches → contract instead.[totickets]

The rule that makes it work: context hygiene

The flow isn't just an ordering of skills — it comes with a discipline about when to keep or drop the agent's memory:

Keep steps 1–3 in one unbroken context window — don't compact or clear until after to-tickets — so grilling, spec, and tickets all build on the same thinking. Each implement then starts fresh from its ticket. The ceiling is the smart zone (~120k tokens) where the model still reasons sharply; if you approach it before to-tickets, handoff and continue in a new thread rather than push on degraded.[askmatt]

handoff forks (new session, context preserved in a file); compact continues (same session, earlier turns summarized). Fork to branch off; compact only at clean phase breaks.

A subtle but load-bearing detail

Look at the frontmatter of the orchestrating skills: grill-with-docs, to-spec, to-tickets, implement all carry disable-model-invocation: true. They're user-invoked — the human walks the flow, step by deliberate step. The agent never decides on its own to jump from grilling to shipping. Only the reusable disciplines underneath (tdd, code-review, domain-modeling) are model-invoked. This is the thesis from Lesson 01 made concrete: you keep the wheel. (We'll dig into this user-vs-model split in Lesson 03.)[askmatt]

Check yourself

Recall from memory — don't scroll up.

In the main flow, what does implement drive internally before committing?

implement builds each unit via tdd (red-green slices), then runs code-review (Standards + Spec) before committing.

The context-hygiene rule says to keep which stretch in one unbroken window?

Steps 1–3 stay together (don't clear until after to-tickets); then each implement starts fresh from its ticket.

What is a "tracer-bullet vertical slice" as to-tickets defines it?

Vertical = narrow but complete through schema→API→UI→tests, independently verifiable, one-window-sized. The horizontal slice and the wide-refactor rename are the anti-patterns; the throwaway program is prototype.

Primary source

Read ask-matt/SKILL.md in full — it's the router that is this flow, including the on-ramps (triage, diagnosing-bugs), the wayfinder merge point, and the vocabulary layer underneath. Then skim to-tickets for the vertical-slice and wide-refactor rules in the author's words.[askmatt][totickets]

Ask me anything. Good follow-ups: "Walk me through a real idea going through the whole flow" · "When would I use wayfinder instead of grill-with-docs?" · "How would this map onto my Pi setup, which has no issue tracker?" Or say next for Lesson 03: the invocation model — user- vs model-invoked, routers, and the two loads you're spending.
Lesson 02 of the arc · Previous: The thesis & the four failure modes · Next: The invocation model

References