Matt Pocock walks through version 1.3 of his skills repo, which adds three skills: /implement-spec, /pr, and /retro. implement-spec orchestrates a whole spec's tickets through sub-agents (a middle ground between manually babysitting each ticket and writing a deterministic script loop), /pr enforces a PR body template with a visual summary, before/after evidence, merge danger and blast radius, and /retro reads your actual past agent sessions and suggests repo and agent improvements. He also notes a breaking rename: domain modeling now writes to glossary.md instead of context.md, which many other skills depend on.
- His workflow splits big work into a spec (the destination) plus tickets (individual coding-agent sessions), because running a whole spec in one agent hits auto-compact and the 'dumb zone'.
- There are three ways to run the tickets: manual human looping (tedious), a deterministic script loop (most reliable and cheapest, but too complex for beginners), and the new implement-spec skill where a sub-agent does the babysitting.
- implement-spec became feasible because sub-agents can now spawn their own sub-agents, making them as capable as orchestrator agents; it treats tickets as a task graph with a frontier of unblocked work so it can parallelize.
- implement-spec's nine steps include exploration, creating an integration branch, implementing each ticket with TDD in work trees, merging, running code review on the integration branch, and producing a single review-ready PR.
- The /pr skill, inspired by Dex Horthy's 'Show Me' skill, templates a PR body as a diagram-based summary, before/after evidence, merge danger (one-way vs two-way door), and blast radius — so reviewers know how hard to look.
- Demanding evidence matters because agents will otherwise claim something works from reading the code; being asked for proof prompts them to run an extra test or take a screenshot.
- The domain modeling skill now writes glossary.md instead of context.md — 'context' was too vague to trigger the agent at the right moment and the file had shrunk to just a glossary; users must update since many skills look for it.
- /retro reads real coding-agent session logs and flags problems the agent papered over — an unasked-for release, a check script nothing runs, context loss across compactions, token-wasting custom CLIs — and Matt insists it stay human-in-the-loop rather than automated, or the agent will chase false positives.
Lays out the three options for orchestrating tickets and why implement-spec exists as the beginner-friendly middle ground.
The most annoying and manual way to do this is managing it yourself... you're kind of acting like a for loop there. It's not really workable.
A compact, reusable framing for how much scrutiny a PR actually deserves, and the core idea behind the /pr template.
Is this a one-way door or is this a two-way door? A two-way door is a door that you can walk back through... a one-way door is a PR that's going to do something out in the world.
My agents are bumping into all kinds of problems that went undetected. But due to persistence, the features still got built one way or another.
Without asking for hard evidence it's very easy for agents to say, yeah, that probably works 'cause I've read the code, but no verification.
Pretty much everyone when I show them this, they go, 'Ooh, I'd love to automate this.' No, you don't want to automate this.
Enjoy seeing the uncomfortable truth of how bad your agent sessions are with retro.