Matt Pocock v1.3 Workflow in Practice: Breaking Down implement-spec, PR, and retro

AI coding workflows are evolving from "manually supervising AI" to "letting AI manage AI." Matt Pocock recently released v1.3 of his skills repository, introducing three skills he considers essential: implement-spec, PR, and retro. The retro skill in particular sparked widespread discussion on social media, with many developers calling it a "game changer." This article breaks down the design philosophy and practical value of each skill, helping you understand the pain points they address.

implement-spec: From Specification to Automated Execution

Matt's core approach to handling large chunks of work is built on two entities: specs (specifications) and tickets. A spec defines "where you're going," while tickets break that goal down into a series of sessions that individual coding agents can execute.

He emphasizes strongly against trying to implement an entire spec in a single agent — that approach easily leads the agent into a "dumb zone" and may even trigger auto-compact (automatic context compression). Breaking work into independent tickets and handing each one to an agent with a clean context is far more reliable.

The challenge lies in orchestrating these tickets. Matt outlines three approaches:

• Manual loop: The user acts as the "for loop" themselves — implement one ticket, clear context, implement the next. Tedious and impractical.
• Deterministic loop: Write a script to read each ticket and automatically invoke the implementation process. This is his most recommended approach — reliable, reproducible, and cost-efficient since it consumes neither agent capacity nor human effort. The downside is setup complexity, making it unsuitable for beginners.
• Sub-agent orchestration: One agent acts as a "babysitter," dispatching multiple sub-agents to implement individual tickets.

implement-spec takes the third path. The reason it's viable now is that sub-agents can spawn their own sub-agents — they're no longer "neutered" like before, but just as capable as the orchestrating agent.

The skill's workflow has nine steps, with the key being that it parallelizes as much as possible. Matt points out that tickets aren't a linear sequence of steps but a "task graph" with blocking dependencies — meaning there's always a frontier of "ready-to-grab" tickets. The process includes: reading the spec and tickets, using sub-agents for exploration, creating an integration branch, using implementer sub-agents with TDD and work trees to implement each ticket, merging into the integration branch, conducting a code review of the integration branch once everything is done, cleaning up, and preparing a PR ready for review. The end result: one complete PR from a massive spec.

Matt acknowledges that implement-spec isn't as reliable as a deterministic script, but it's an excellent entry point into an AFK (away from keyboard) workflow — you can step away and let it automatically implement an entire spec. This skill is especially valuable for systems that haven't yet built out the "software factory" scripting infrastructure.

The "dumb zone" and auto-compact are key context for understanding why tickets need to be broken apart. Large language models have a capacity limit on their context windows. When a session accumulates too much content, the model's reasoning quality noticeably degrades — that's what Matt calls the "dumb zone." Auto-compact is the mechanism in tools like Claude that automatically compresses conversation history when the context approaches its limit; after compression, the model may lose critical intermediate states and decision rationale, leading to unpredictable outputs. Work trees are a Git feature that allows checking out multiple branches from the same repository into different directories simultaneously — enabling multiple sub-agents to develop different tickets in parallel in their own isolated working directories without interference. TDD (Test-Driven Development) requires agents to write tests before writing implementations, a core practice for ensuring each ticket produces verifiable output.

The PR Skill: Making Human Review as Easy as Possible

PRs remain the primary bottleneck for code entering the main branch. Matt's PR skill has a clear goal: make human review as easy as possible. The inspiration came from Dex Horthy's ShowMe skill — using concise diagrams and pseudocode to aid understanding of any given topic, making review significantly easier in a PR context.

The skill essentially provides a PR body template with several key sections:

Summary: Based on a ShowMe-style template.

Evidence: Provides before-and-after comparisons. Matt emphasizes this is critical to "learning to trust agent output." Requiring agents to provide hard evidence often prompts them to run one more test or take one more screenshot, delivering runtime information that proves the change actually achieved its intended effect. He states plainly that without requiring hard evidence, agents easily conclude "I read the code, it should be fine" — and verification is something he's become increasingly obsessed with recently.

Merge danger: How dangerous is it to merge this PR? Matt likes the "one-way door vs. two-way door" metaphor — two-way doors can easily be rolled back, while one-way doors have real-world consequences (data deletion, costly rollbacks).

Blast radius: The potential scope of impact from the changes. If a PR is a two-way door with a small blast radius, it barely needs serious review.

Matt demonstrated a real example from his repository: merging two nearly identical algorithms. The PR clearly presented deleted/added files, call stack structure, and most importantly, before-and-after evidence. Merge danger was labeled as a two-way door (pure refactoring plus one intentional behavior change), with a small blast radius. He says this skill has become an indispensable part of his workflow, and on Opus 5.5 it's invoked automatically almost every time without users needing to think about it.

An Important Change: context.md Renamed to glossary.md

Before discussing retro, Matt mentions a change with broad impact: the domain modeling skill now writes to glossary.md instead of context.md.

This skill was inspired by Eric Evans' Domain-Driven Design (DDD), and was originally named context.md after the DDD concept of "bounded context." But Matt found the name context.md too vague — it didn't trigger agents to incorporate it at the right moments, and it confused users. Since he'd also trimmed the file contents down to just a glossary, he simply renamed it glossary.md. This is purely a filename change with no other behavioral modifications, but since many skills depend on recognizing glossary.md to function correctly, users must update accordingly.

retro: Letting Another Agent Expose the Uncomfortable Truth About Your Sessions

retro is the most talked-about skill in this release — short for "retrospective." Matt's starting point: he was asking too much of users — managing agents.md, managing skills, keeping the repository token-efficient, maintaining good lint rules and navigation structure. He realized he'd been doing enormous work to optimize the repository and decided to package it all into a single skill.

You run retro on a coding agent session (current or past) and it gives you recommendations for improvement next time. Its power lies in actually reading real sessions and seeing the inefficiencies the agent encountered — including ones it hid from you.

Matt cites feedback from user Andre: "Retro is a game changer. My agent ran into all sorts of previously undiscovered issues, but due to its persistence, the feature got built one way or another." In other words, agents often don't complain the way they should and don't proactively fix their own mistakes — you need another agent to look back at those sessions and identify what went wrong and how to improve.

In Matt's live demo, retro surfaced multiple issues: the agent ran irreversible public operations before the user confirmed a fix (it published a release without asking — which is exactly why the repository has a 1.3.1 but no 1.3.0 release); the repository had a PNPM check script but nothing running it, prompting a suggestion to add a CI pipeline; there was context loss between long session compressions, with a recommendation to extract repeated instructions into dedicated skills; even details like the custom CLI wasting tokens and tools not being in PATH were flagged. Matt describes retro as "merciless" — it almost always finds something to improve.

On usage, Matt offers two important pieces of advice:

Keep the human in the loop. Issues flagged by retro require human judgment — for instance, what it considered the most serious release issue was actually irrelevant. Almost everyone who sees the demo wants to automate it, but Matt is firmly against this: automation leads to agents endlessly discovering false positives and trying to fix them, steering the repository and agents in strange directions.

Run it as a spot check on a sample of sessions. No need to run it every time. Run retro when you have spare time, when a session clearly went wrong, or when agent behavior seems off — it usually finds a fix.

retro has several built-in improvement dimensions it checks: whether the codebase is easy to navigate, whether automated checks can be added, whether coding standards can be added for automated reviewers, whether the global agents.md is healthy, whether tool economy is reasonable, whether there are no-op instructions in steering files, and whether agents have access to all the information they need.

Matt says that by running retro regularly, his token efficiency and output quality have improved significantly.

retro's ability to "read real sessions" depends on tools like Claude saving the complete agent interaction history — including tool calls, intermediate reasoning steps, and error retry records — in structured form. What ordinary users see in the UI is often just the final output, while the failed attempts, workarounds, and repeated operations the agent went through to reach its goal are hidden. When retro reads these raw records as a separate agent, it can identify hard-to-notice inefficiency patterns like "silently retried tool calls seven times after failure" or "read the same file fifteen times." "Tool economy" is a metric in Matt's repository that measures the ratio between the number of tool calls an agent makes to complete a task and the actual value produced — fewer calls with more accurate outputs means higher tool economy efficiency, directly impacting token consumption costs.

Summary

The three skills in v1.3 each correspond to a different phase of the AI coding workflow: implement-spec handles "getting the work done," giving even beginners access to an automated AFK workflow; PR handles "making merging feel safe," reducing review overhead through the three elements of evidence, merge danger, and blast radius; retro handles "continuous improvement," using one agent to review another agent's real sessions and surface inefficiencies masked by sheer persistence. The core philosophy runs throughout: verification first, human in the loop, continuous iteration.