Matt Pocock skills 1.3 Explained: The Three Core Skills — Implement Spec, PR, and Retro

The pace of iteration in AI coding toolchains tends to show up in details that look unremarkable but actually set the ceiling on your workflow. Matt Pocock recently released version 1.3 of his skills repo, bringing three skills he calls the "core of the workflow": Implement Spec, PR, and Retro. These three skills map to orchestration of implementation, code review efficiency, and retrospective optimization of agent sessions.

Implement Spec: Orchestrating a Ticket Graph with SubAgents

When you're facing a big chunk of work, Matt's approach is to split it into two things: a Spec (the goal) and Tickets (units of execution). The Spec is where you want to go; the Tickets break that destination into small tasks that can each be handed independently to a coding agent.

His core judgment: letting a single coding agent do an entire Spec in one shot pushes it into the "silly zone" and may trigger auto-compaction. It sometimes works, and it's getting better, but splitting the work into Tickets handed to independent agents is far cleaner.

The question is how to orchestrate those Tickets. Matt lists three ways:

• Manual loop: The user plays the loop, telling the agent "implement the first Ticket," waiting for it to finish, clearing context, then saying "implement the second." He calls it "not fun at all."
• Deterministic loop: Write a script that reads each Ticket and runs the implementation automatically. Reliable and cheap, because the thing running the loop is a script — not an agent, not a human. But polishing that loop takes a lot of patience, and the bar is too high for newcomers.
• SubAgent loop: The middle ground Implement Spec takes — let a SubAgent run the loop and do the implementation, effectively handing off the "babysitting" job to an agent.

This is now viable because SubAgents can themselves spawn SubAgents. SubAgents used to be somewhat nerfed; now they're as capable as the orchestrating agent.

Implement Spec's flow has nine steps, and the key idea is parallelize wherever you can. Tickets aren't a linear sequence — they're a task graph with dependencies, so there's always a batch of Tickets ready to be claimed. The agent first reads the Spec and all Tickets, explores inside a SubAgent, creates an integration branch, then dispatches implementation SubAgents to work each Ticket TDD-style, using WorkTrees. When done, a SubAgent merges results into the integration branch, then more branches are dispatched until all the work is finished. Finally, it runs code review on the integration branch, cleans things up, and sets the PR to awaiting review.

In his words: that big a Spec, ending in just one PR.

SubAgent is a concept defined relative to a "main agent" (or orchestrating agent): the main agent understands user intent, plans steps, and dispatches tasks, while a SubAgent is a subprocess spawned by the main agent with its own independent context window, focused on executing one specific subtask. SubAgents used to be limited to one-shot, stateless, weaker helper roles that couldn't spawn further. Once SubAgents can spawn SubAgents, orchestration becomes a tree: a SubAgent dispatched by the main agent can dispatch its own SubAgents, and each layer only cares about its own small slice of the problem. This is the technical prerequisite that makes Implement Spec able to execute a Ticket graph automatically.

WorkTree refers to Git's git worktree feature, which lets you check out multiple working directories from the same repo simultaneously, each on a different branch. Compared to the traditional "copy the repo" or "switch branches repeatedly" approaches, WorkTree gives multiple parallel SubAgents non-interfering filesystems while sharing the same Git history and object store — cleaner merges and less disk overhead. This is the infrastructure that makes the "parallelize wherever you can" strategy actually work.

TDD (Test-Driven Development) is a development rhythm of "write the test, then write the implementation, then refactor." In agent scenarios it's especially valuable: tests give the agent an executable, unambiguous definition of the goal, so it doesn't have to rely on fuzzy natural language to judge whether it's "done."

PR Skill: Making Code Review Easy

Matt calls himself a huge fan of Dex Hossi, whose Show Me skill uses clean diagrams to help users grasp a topic visually. Inspired, he built his own PR skill with the goal of making human review as easy and simple as possible.

The skill's core is a template for writing PR descriptions, requiring three key parts:

1. Summary: Start with a Show Me-style template to write an overview.
2. Evidence: Before-and-after comparisons, including tests, screenshots, and runtime information.
3. Merge risk: How dangerous is it to merge this PR.

Matt uses a very vivid metaphor: is this a one-way door or a two-way door? A two-way door means you can walk back — easy to roll back. A one-way door has real-world consequences, like deleting data, where rolling back is expensive. If it's a two-way door with a small blast radius, the PR doesn't really need heavy review.

Why is evidence so critical? Matt says that asking the agent for evidence tends to mean it runs an extra test and takes an extra screenshot, giving you runtime information proving the change actually does what it thinks it does. Without that requirement, the agent easily says "should work, I looked at the code." He admits he's become increasingly obsessive about verification lately.

By his observation, the PR skill is one of the most reliable skills he's seen for models to invoke on their own. As a user you don't manage it at all — at least on Opus 5.5, it seems to call itself every time.

Show Me style refers to a writing style that visualizes abstract concepts with structured diagrams, thumbnail sketches, and code blocks. It emphasizes "the reader can grasp the structure in seconds" rather than piling up long paragraphs. Using this style in PR descriptions aims to let reviewers quickly build a mental model even if they know nothing about the change's background.

One-way door / two-way door comes from Amazon's decision classification framework: a two-way door is a reversible decision you can quickly try and quickly correct; a one-way door is hard to reverse and has irreversible real-world consequences once executed (deleting data, shipping, publishing externally). Applied to PR review, the reviewer only needs to first judge "which kind of door is this" and then decide the review intensity — a two-way door with a small blast radius can be fast-tracked, while a one-way door demands strict scrutiny. It converts the fuzzy question of "how carefully should I review this" into a quickly classifiable yes/no judgment.

Domain Modeling and Retro: Digging Problems Out of Real Sessions

Before getting to Retro, Matt mentions a major change in how he works: the domain modeling skill no longer writes to context.md — instead it writes glossary.md. The inspiration comes from Eric Evans's Domain-Driven Design, and the original filename context.md was taken from its "Bounded Context" concept.

But Matt felt the name context.md was "overloaded" and too vague — it couldn't get the agent to proactively read it when it should, and users found it confusing too. He kept cutting content until it really was just a glossary, so he renamed it glossary.md. Many other skills need to see this file to function and to use domain language at every step, so it's essential to remember to update it. The behavior is unchanged; only the filename changed.

What Retro Actually Does

Matt reflects that he's always asked users to make all kinds of long-term changes to their repos: managing AGENTS.md, managing skills, keeping repos token-efficient, making environments agent-friendly and safe, writing good lint rules, setting up code navigation. Then he realized he himself has been doing all these things to repos and agents — so why not package it as a skill? That's Retro (Retrospective).

Retro runs on a coding agent session — the current one, one of the ten currently open, or the last one — and surfaces what could be improved next time. The cool part of reading real sessions is that it can see what the agent actually did at the time, and see inefficiencies it might be hiding from your skills.

Matt quotes a line that captures the value: "Agents complain less than they should, and they won't proactively fix their own mistakes. You need to get another agent to go back and look at those sessions, see what went wrong, and see how to help it."

The agent found these problems in his sessions:

• Did something irreversible before waiting for sign-off — found the cause of the missing 1.3.0 version, then shipped a release without asking. That's why releases have 1.3.1 but no 1.3.0.
• The repo has no guardrails — there's a PMPM check script but it was never wired up.
• Context is lost between compactions in long sessions — suggested moving recurring instructions into a dynamic skill.

Why He's Against Automating Retro

Matt says plainly that almost everyone who sees Retro says "I want to automate this," and his answer is "No, you don't want to automate it."

The reason is simple: once automated, the agent falls into a death loop — endlessly finding false positives, endlessly fixing things, and ultimately walking a very strange path that takes the repo and the agent somewhere they shouldn't go.

Retro is designed to have a human in the loop, not to be "run it and it fixes everything." Matt suggests running Retro on a subset of agent sessions — whenever you have time and suddenly remember it's been a while, have it go through recent sessions, or pick a session where something went wrong and the agent did something weird.

In the Retro skill's steps, it lists several categories of improvements to look for: is the codebase easy to navigate, are there automated checks to add, can coding standards be added for automated review to enforce, is the global AGENTS.md healthy, are tools being used cost-effectively, is there dead content in instruction and guidance files, can the agent get all the information it needs.

Matt says that after sticking to running Retro regularly, his token efficiency and output quality have improved dramatically.

Domain-Driven Design (DDD) was systematically introduced by Eric Evans in his 2003 book of the same name. Its core idea is to align software structure with the conceptual model of the business domain, and to use a unified "Ubiquitous Language" across code, documentation, and team communication. Bounded Context refers to the boundary within which a concept or term has a clear and unique meaning; outside that boundary, the same word may refer to something entirely different. Matt's original context.md was taken from this concept, but "context" in the agent world can also mean "context window," "system prompt," and so on — a classic case of term overload — so renaming it to glossary.md (glossary) is actually more precise and easier for the agent to proactively read.

Auto-compaction refers to the system automatically summarizing earlier conversation and discarding original details when a session's context length approaches the model's window limit, freeing space to continue. This is the mechanism that keeps long sessions alive, but the cost is loss of fine-grained information — and in Retro, Matt specifically flags "context lost between compactions" as a problem to fix.

The Combined Value of the Three Skills

Looking at these three skills together reveals a clear line of thinking: Implement Spec solves how to get agents to reliably complete large chunks of work, the PR skill solves how to let humans quickly trust and review agent output, and Retro solves how to continuously improve the whole environment from real runs.

The first two lean toward execution efficiency; the last leans toward long-term evolution. And Matt's opposition to automating Retro points to a more general principle: where judgment and trade-offs are involved, human oversight remains irreplaceable. Especially when automation amplifies false positives and steers the system off course, "human in the loop" isn't conservatism — it's design clarity.

One-line Summary

Matt Pocock releases skills 1.3, bringing three core skills: Implement Spec, PR, and Retro.

Paragraph Summary

Matt Pocock releases version 1.3 of his skills repo, containing three "workflow core" skills. Implement Spec breaks large work into a Spec plus a Ticket task graph, implemented in parallel via a SubAgent loop where SubAgents can spawn further SubAgents, producing just one PR — a good starting point for an AFK workflow. The PR skill offers a PR description template with three parts — summary, evidence, and merge risk — and uses the "one-way door or two-way door" test to decide review intensity, while requiring evidence pushes agents to run more tests and take more screenshots. Retro reads real agent sessions to uncover inefficiencies, missing guardrails, and context loss during compaction, but Matt explicitly opposes automating it, since that would trap the agent in a false-positive-fixing death loop. Additionally, the domain modeling skill was renamed from context.md to glossary.md. Together the three cover execution efficiency, review trust, and long-term environment evolution.