Matt Pocock's Three New Skills Close the AI Coding Loop

AI writing code is no longer novel—but what happens after? PRs piling up with no one to review them, AI repeating the same mistakes across long tasks, context windows growing messier by the minute—these are the real bottlenecks. Matt Pocock recently updated his skill collection with three new skills that fill exactly the three gaps between "ticket breakdown" and "code merge" and "post-mortem."

Recap: The Original Four-Stage Flow

Before introducing the new skills, we need to understand the basic logic of Matt Pocock's original system. According to a Bilibili creator's video breakdown, the old workflow had four stages:

• grooming skill: Gather as much context as possible before starting—the more sufficient the context, the higher the accuracy of AI output
• two-step skill: Consolidate the consensus reached during grooming into a formal plan
• two-ticket skill: Break the plan into tickets, with the key constraint being "split by feature, not by layer," so each ticket can be completed independently by a single agent, thereby protecting the context window
• implement / code review skill: The former uses TDD for implementation, the latter reviews in a fresh context window against Martin Fowler's 12 refactoring principles

This flow solves the problem of "from idea to code," but the chain breaks from code to a mergeable PR, and then to the team learning from AI's mistakes.

The classic TDD (Test-Driven Development) cycle is "red—green—refactor": first write a failing test (red), then write the minimal implementation to make it pass (green), and finally refactor the code without changing behavior. Having AI work via TDD has additional benefits—tests become executable acceptance criteria, and the agent has a clear signal at each step to judge whether it's done, avoiding the false completion of "looks like it's written." It also constrains the scope of the agent's changes: behavior not covered by tests should not be modified arbitrarily. Paired with this, Martin Fowler's 12 refactoring principles (such as eliminating duplication, extracting functions, moving features, replacing conditionals with polymorphism, etc.) provide a checklist for code review, shifting review from subjective taste to rules that can be checked one by one, and giving the review agent running in a fresh context a stable basis for judgment.

New Skill 1: implement spec, Parallel Ticket Processing

The first new skill is implement spec. The Bilibili creator's positioning in the video: it packages the TDD skill, the code review skill, and multi-worktree parallelization together.

The approach is to first organize all tickets, identify those without dependencies, and simultaneously launch multiple AI agents to work on them separately. Compared to serial processing, this can significantly shorten overall time. After each branch is complete, they're merged into a unified branch, then code review runs, and finally issues are fixed and a usable pull request is generated.

The design thinking here is worth noting: parallelism isn't simply "spinning up more agents"—it's built on the premise that tickets have no dependencies between them. The two-ticket skill's original decision to "split by feature" was precisely to make this step possible—if you split by layer (write all models first, then all services), tickets naturally have dependencies, and parallelism becomes impossible.

Multi-worktree (git worktree) is a Git mechanism that allows checking out multiple independent working directories on the same repository simultaneously, each corresponding to a different branch and sharing the same .git object store. Compared to cloning multiple repositories, worktrees don't duplicate storage of historical objects, making switching and cleanup cheaper. In AI coding scenarios, each agent occupies one worktree and commits independently on one branch without interfering with others, then everything is merged at the end. This is the underlying support for implement spec's "parallel advancement": agents don't compete for files, and there's no need to repeatedly stash or switch branches. Note that worktrees only isolate the working directory—they don't resolve merge conflicts. Conflicts still need to be resolved one by one by humans or agents during the consolidation phase.

New Skill 2: PR skill, Let Reviewers Grasp Risk in Thirty Seconds

The second skill targets the PR review bottleneck. The Bilibili creator put it bluntly in the video: the bottleneck used to be writing code, because humans write slowly; after AI accelerated code writing, the bottleneck shifted to "humans reviewing PRs." The number of PRs AI produces daily is enormous, and the traditional PR description's "quick summary" and "test plan" don't prove the feature actually works—whether the test plan is valid still requires someone to run it to find out.

Matt's PR skill restructures the description into three sections:

1. Evidence: Proof that the feature actually works, not "should be fine"
2. Risk: What consequences this change might cause in production
3. Merge danger: If the PR goes wrong, how large is the blast radius, and can it be rolled back

The value of this structure is putting the basis for judgment upfront. A small change that's easy to roll back can be quickly approved; a large change that's hard to roll back should be paused for careful human review. The Bilibili creator also mentioned that this skill isn't a fixed template—people without technical backgrounds can rewrite it into a version without excessive technical jargon; the key is making it readable and judgeable for yourself.

Blast radius is borrowed from the incident management and security fields, referring to the scope affected when a change goes wrong: how many users, how many services, whether it touches data writes or financial paths. It depends not only on the number of lines changed but more on where the change sits in the system—modifying an internal utility function versus modifying authentication middleware carry completely different risk magnitudes. Paired with blast radius is rollback-ability: whether it can be quickly disabled via a feature flag, whether it involves irreversible data migration, and whether rollback requires downtime. Writing both alongside risk in the PR description means reviewers don't have to rebuild context themselves and can directly allocate attention by the rule of "large impact and hard to roll back means look closely; small impact and easy to roll back means quick approval"—this is the practical benefit of putting the basis for judgment upfront.

New Skill 3: retro skill, Let Agents Learn from Mistakes

The third skill addresses the "repeated mistakes" problem in long tasks. When a task stretches to dozens, hundreds, or even thousands of tickets, the agent may repeatedly stumble on the same type of problem, consuming tokens without producing progress. The retro skill's job is to review the agent's complete conversation record and improve from two directions:

Context engineering: Check whether the agent is inefficient at finding files, and based on that generate an agent MD file listing key file locations and search paths; also clean up verbose, redundant parts of the system prompt.

Guard rails: Codify recurring errors like "APIs that shouldn't be called" and "imports placed in the wrong location" into lint rules or coding conventions, mechanically preventing recurrence.

One point Matt Pocock particularly emphasized: retro skill must not be set to autopilot mode. If run continuously, Claude will treat every observation as a problem worth nitpicking, and the project's focus will drift from "building features" to "fixing the project itself." The correct usage is to run it periodically and have a human review the suggested changes it proposes.

The Complete Loop Assembled by the Three New Skills

Looking at the old and new skills together, coverage of the entire software development lifecycle becomes continuous: after two-ticket comes implement spec for parallel implementation, after code review comes PR skill to make merging easier to review, and finally retro skill feeds this round's lessons back into the next round's context and guard rails. The Bilibili creator called this "full circle" at the end of the video—the next round of agents building features or fixing bugs starts from a higher baseline than this round.

It should be noted that the above content mainly comes from a single video source. The specific implementation details of Matt Pocock's original skills (such as the prompt wording for each skill and the specific configuration of parallel worktrees) were not elaborated in the video; interested readers should consult his original repository and documentation. Additionally, the Bilibili creator mentioned a companion canvas page that summarizes each skill's use cases and how it works, which can serve as further reference.

For developers who use AI coding daily, the thinking behind these three skills is more worth borrowing than the specific implementations: trade dependency-free splitting for parallelism, trade risk grading for review efficiency, and trade periodic retrospectives for long-term convergence. Even without Matt's originals, this structure can be migrated to your own agent workflows.

One-line Summary

Matt Pocock adds three AI coding skills, completing the loop from tickets to PRs to retrospectives.

Paragraph Summary

The article walks through Matt Pocock's updated AI coding skill system: the original four-stage flow of grooming, two-step, two-ticket, and implement/code review solved the problem from idea to code, but there were breakpoints from code to a mergeable PR, and then to the team learning from AI mistakes. The three new skills fill these gaps: implement spec packages TDD, code review, and multi-worktree parallelization, advancing multiple agents simultaneously on the premise that tickets have no dependencies; PR skill restructures the description into evidence, risk, and merge danger, putting the basis for review judgment upfront; retro skill uses context engineering and guard rails to stop agents from repeating mistakes, but emphasizes that it must run periodically and be human-reviewed. Together with the old flow, the three form a complete development loop.