Skills v1.3: Matt Pocock's /pr, /implement-spec, and /retro

0:00Matt Pocock's skills repository — the most-starred agent-skills collection on GitHub — ships version 1.3 with three additions he describes as "central to my workflow": implement-spec, PR, and retro. This is a short, dense walkthrough of each, and it reads as the follow-up to his earlier grill-me / wayfinder deep dive. It is also a notable crossover: the PR skill is explicitly "inspired by" Dex Horthy's Show Me skill — the same Dex Horthy whose "software factories fail" thesis we covered separately.

What's in v1.3

Three skills, three different jobs. implement-spec takes a written spec and its tickets and drives them to completion across multiple sub-agent sessions, landing as a single PR. PR is a template for the PR body — nothing more — designed to make human review as cheap as possible. retro (short for "retrospective") reads real coding-agent sessions afterward and lists what should improve before the next run. Pocock singles out retro as the one that "absolutely went nuts on socials."

implement-spec: specs → tickets → one PR

0:26The core mental model: two entities — a spec (the destination) and the tickets (the sessions that get you there). His reason for the split is practical: "If you try to implement the spec all in one coding agent, you would go into the dumb zone — you might end up hitting auto-compact." Breaking the work into individual tickets is "a lot cleaner."

3:36The skill's nine steps are what matters. Crucially, it treats tickets as a task graph with blocking relationships, not a list: "there's always a frontier of tickets that are ready to be grabbed." So it parallelizes where it can — each ticket implemented by a sub-agent using TDD and git worktrees, results merged to an integration branch, another round of sub-agents dispatched, then code review, cleanup, and one PR "off this huge great big spec."

4:23He frames it explicitly in terms of a software factory: implement-spec is for "systems where you haven't set up these deterministic scripts yet, where you don't have your software factory dialed in." It's deliberately a beginner-friendly middle ground — a starter kit you can rebuild your own way ("you could use stacked PRs, you could do all sorts of stuff").

The orchestration problem

1:23Pocock lays out three ways to run tickets, in ascending order of sophistication:

• The manual loop — you act as the for-loop: "implement ticket two… wait… clear context… implement ticket three." "Not much fun," and not workable at scale.
• The deterministic loop — a script reads each ticket and runs it itself. "Very reliable and cheap," but the setup "is out of range for beginners" and takes patience to refine.
• Sub-agent orchestration — what implement-spec does. "An agent does the babysitting instead of a human." This only recently became viable because sub-agents can now spawn sub-agents — "before, sub-agents were a little bit nerfed; now they're actually as powerful as orchestrator agents."

His honest ranking: implement-spec is "worse than a deterministic loop" in reliability, but it's the best way to start "AFK workflows" — step away, and it implements the whole spec.

PR: making human review easy

4:56"PRs are still the main bottleneck for work getting to main." The PR skill's entire job is to shrink that bottleneck, and it is a direct descendant of Dex Horthy's Show Me skill, which "helps the user understand the current topic visually with concise diagrams." Pocock calls Show Me "gorgeous."

The PR body template has four parts:

• Summary — built on the Show Me template, giving a visual/pseudo-code shape of the change.
• Evidence — before and after. Pocock is "obsessed" with this: "without asking for hard evidence, it's very easy for agents to say 'yeah, that probably works because I've read the code' — but no, verification." Prompting for evidence often makes the agent run an extra test or take a screenshot.
• Merge danger — the one-way vs two-way door metaphor. A two-way door (a pure refactor) is easy to walk back through; a one-way door deletes data or does something out in the world that's expensive to roll back.
• Blast radius — the potential ramifications of the change. Small blast radius on a two-way door = barely needs review.

7:46He notes the PR skill is "one of the most consistently invoked model-invoked skills" — on Opus 5.5 it just fires automatically, so "you should just be able to download it and see your PR bodies get better." And if you already have a PR-body skill, "steal what you can."

The context.md → glossary.mmd rename

8:11A small but consequential breaking change: the domain-modeling skill no longer writes to context.md — it writes to glossary.mmd. The original name came from Eric Evans's Domain-Driven Design ("bounded context"), but Pocock has moved away from the overloaded term. "Context.md just felt way too vague — it didn't trigger the agent to pull it in at the right moment." The file has also been trimmed down until it is "literally just a glossary."

The catch: loads of his other skills rely on glossary.mmd to use the domain language, so existing users must rename the file. "There's no other behavior change — it's really literally just a file name change."

retro: reading your sessions back

9:38The star of the release. Pocock's realization: "I impose a lot — I ask a lot of you, the user" to keep your repo token-efficient, your agents.md healthy, your lint rules and navigation good. He was doing all of that by hand on his own repos, so he "bundled that up into a skill." Retro runs on a coding-agent session (current, previous, or a batch) and suggests improvements for next time.

11:16The power is that it reads real sessions, catching what the agent hides. Live examples from his own repo:

• The agent ran an irreversible public action — it found why the 1.3.0 release was missing and "ran a release without actually asking." That's why there is no 1.3.0 release, only 1.3.1.
• A repo has a pnpm check script "but nothing actually runs it" → it suggests a CI pipeline.
• Context loss between compactions in long sessions → move repeated instructions into a dedicated "animatic" skill.
• A custom CLI wastes tokens; another isn't on PATH.

The categories it scans: codebase navigability, missing automated checks, coding standards for an automated reviewer, the health of the global agents.md, "tool economy," no-ops in steering files, and whether the agent has the information it needs. "Retro is merciless."

Why retro stays human-in-the-loop

12:36The trap everyone falls into: "Pretty much everyone when I show them this goes 'ooh, I'd love to automate this.'" Pocock's answer is flat: don't. Automating retro means the agent "gets itself into a loop where it continually finds false positives, continually tries to fix things, and you'll end up in this weird trajectory where it takes the repo and your agent into a place it shouldn't go."

13:16His prescription: run retro on a sampling of sessions whenever you have a free moment — especially a session that went wrong or felt weird. And use human judgment on the findings; in his own run, the item flagged most serious (the botched release) was actually fine, because "I can always create and cut new releases."

His closing line frames the whole release: enjoy "the uncomfortable truth of how bad your agent sessions are" that retro surfaces.

Claims checked

Sources & further reading