---
url: "https://www.youtube.com/watch?v=BsJGo1wFTvQ"
title: New Skills! v1.3 brings /pr, /implement-spec, and /retro
source_kind: youtube
author: Matt Pocock
captured: "2026-10-08T18:16:34+00:00"
comment_tree: false
topics: [agent-tooling, skills]
summary: Matt Pocock introduces v1.3 skills including /implement-spec, /pr, and /retro, explaining how they streamline ticket implementation and agent orchestration.
status: ok
---

# New Skills! v1.3 brings /pr, /implement-spec, and /retro

Channel: Matt Pocock

## Transcript

[0s] Hello folks, version 1.3 of my skills
[3s] repo is out and it brings three very
[6s] important skills that have become
[7s] central to my workflow. Today I'm going
[9s] to show you about implement spec. I'm
[11s] going to show you about PR and I'm going
[13s] to show you about retro. And retro I
[16s] think is the one that I've just seen
[19s] absolutely go nuts on socials. People
[21s] going crazy for this skill and it has
[24s] felt incredibly powerful to me too. And
[26s] the first place I want to start is the
[28s] implement spec skill. The main flow of
[30s] my approach for landing huge chunks of
[33s] work at once is essentially two
[35s] different entities. You have a spec and
[38s] then you have the tickets that implement
[40s] that spec. The spec kind of acts like
[42s] the place where you're going and then
[44s] the tickets break that destination down
[47s] into a set of sessions that you can then
[50s] run in a single coding agent. If you try
[52s] to implement the spec all in one coding
[54s] agent, you would go into the dumb zone
[56s] of that coding agent, you might end up
[58s] hitting auto compact. And you know,
[60s] while that works sometimes, and it is
[62s] getting better, I still think that
[64s] breaking things down into individual
[66s] tickets is just a lot cleaner. Now, the
[68s] way that you orchestrate those tickets,
[69s] the way that you give them each to one
[72s] coding agent has always been a little
[73s] bit confusing for users. And I've kind
[76s] of been sort of going back and forth
[78s] over the way that I recommend you do
[80s] this. The most annoying and manual way
[83s] to do this is managing it yourself where
[85s] you the user say okay uh agent we are
[88s] going to implement our first ticket. You
[90s] wait for it to be complete. You clear
[92s] the context and then you say okay
[94s] implement ticket two. You wait. You
[96s] clear the context. You say implement
[98s] ticket three. You're kind of acting like
[100s] a for loop there. It's not really
[102s] workable. So that is what I would
[104s] describe as the manual loop there which
[106s] is not much fun. But you can change that
[109s] by having a deterministic loop where you
[111s] have a script that reach uh reads each
[113s] ticket and then runs implements on it
[115s] itself. This is how I recommend that
[117s] most people do this because once you've
[118s] set up your deterministic loop, it's
[120s] going to run the same way every time.
[122s] It's very reliable and it's cheap,
[125s] right? Because you're not using an agent
[126s] or you're not using a human to run that
[129s] loop. You just essentially get a script
[131s] to do it for you. But setting this up is
[133s] quite complicated and requires a lot of
[136s] patience as you sort of refine your loop
[138s] and get it better and better. And so I
[140s] see this as out of range for beginners.
[142s] And so I wanted some way of allowing
[146s] beginners to see not have to manually
[149s] loop it themselves. And so I decided,
[151s] okay, why don't we try a middle ground
[154s] where we have sub agents go through and
[157s] implement the loop. In other words, an
[158s] agent does the babysitting instead of a
[161s] human. This means that all of the
[162s] tickets will be implemented by sub
[164s] agents. And this has recently gotten
[167s] possible because sub aents can
[169s] themselves spawn sub aents. So before
[172s] sub agents were kind of a little bit
[174s] nerfed whereas now they're actually as
[176s] powerful as orchestrator agents. And so
[178s] this is what implement spec does is it
[181s] the agent sits there looking at all of
[183s] the tickets orchestrating them and then
[185s] implements them in sub aents. This is I
[188s] would say worse than doing a
[190s] deterministic loop because the
[191s] deterministic loop again it's
[192s] deterministic. It works the same way
[194s] every time. But implement spec is a good
[196s] way to get started with AFK workflows
[199s] away from keyboard workflows where you
[201s] step away and it implements the entire
[203s] spec. Before you use any skill, you
[205s] should read the entire skill. And it's
[207s] not particularly long here. There are
[210s] nine steps in its process and it's got a
[212s] little bit of reference material just at
[213s] the top. One crucial thing is it goes
[215s] for parallelization where it can. And so
[217s] this says the tickets are not a list of
[219s] steps. They're a task graph with
[221s] blocking relationships between them.
[223s] That means there's always a frontier of
[224s] tickets that are ready to be grabbed. If
[226s] we take a look at the steps, we can see
[227s] it reads the spec and tickets. It does a
[230s] little bit of exploration in its own sub
[232s] agent. It creates an integration branch
[235s] and then it goes and uses implement sub
[237s] aents to implement each ticket using TDD
[240s] and using work trees too. Once that's
[242s] done, it merges its work to the
[244s] integration branch with a sub aent and
[247s] then pings off more implement sub aent
[249s] until all the work is done. And once it
[252s] the work is done, it goes and calls code
[254s] review on the integration branch. Then
[256s] it cleans up all of its work and makes
[258s] the PR ready for review. So you get a
[260s] single PR off this huge great big spec.
[263s] I have been reaching for this a lot more
[265s] than I thought I would, especially on
[268s] systems where you haven't set up these
[269s] deterministic scripts yet, where you
[271s] don't have your like software factory
[273s] dialed in. I suppose implement spec has
[276s] been really really useful. It's been in
[277s] in progress for a while now, but I
[279s] thought now's the moment. Let's graduate
[281s] this so people can use it and fiddle
[283s] around with it and build their own
[284s] version of this, too. This is a basic
[286s] version of how you might implement your
[288s] own spec. You could do something totally
[290s] different to this. You could use stacked
[292s] PRs. You could do all sorts of stuff.
[294s] And in fact, talking of PRs, one of uh
[296s] my most used recent skills has to be the
[299s] PR skill. So, PR skill.md. I've been a
[302s] huge fan of Dex Hies for a while now. I
[304s] recently got to meet up with him in
[306s] person and he has this gorgeous skill
[308s] called Show Me. What show me does is it
[310s] helps the user understand the current
[312s] topic visually with concise diagrams and
[315s] it uses all of this like uh really nice
[318s] pseudo code. This looks a little bit
[320s] garbage, but actually when you see it in
[322s] the context of a PR, it really makes the
[325s] PR a lot easier to read and review. PRs
[328s] are still the main bottleneck for work
[330s] getting to Maine. And my goal with this
[333s] PR skill, kind of inspired by Show Me,
[337s] is to make human review as easy as
[340s] possible. And in the skill, we provide
[341s] essentially a template for writing a PR
[344s] body. That's all the skill does. We
[346s] first start with a summary based on the
[348s] kind of show me template which we
[350s] include in the skill and then we ask for
[353s] evidence. So before and after. This
[355s] evidence is an essential part of
[357s] learning to trust your agent, learning
[360s] to trust your agents outputs. and
[361s] actually prompting it to provide
[363s] evidence often means it runs an extra
[365s] test or it takes an extra screenshot if
[367s] it has that ability and it provides you
[370s] runtime information on that it's actual
[374s] change is doing what it thinks it's
[375s] doing without asking for hard evidence
[377s] it's very easy for agents to say yeah
[379s] that probably works cuz I've read the
[380s] code but no verification is something
[382s] I'm beginning to be really obsessed with
[385s] especially after my recent interview
[386s] with Lauren and then the third heading
[388s] here is merge danger so how dangerous Is
[391s] this PR going to be to merge? One
[393s] metaphor I've really like here is, is
[395s] this a one-way door or is this a two-way
[398s] door? A two-way door is a door that you
[400s] can walk back through. In other words,
[401s] we can easily revert this PR. But a
[404s] one-way door is a, you know, a PR that's
[406s] going to do something out in the world.
[409s] It's going to delete some data or it's
[411s] going to be expensive in some way to
[413s] roll back. And then finally, you have
[414s] blast radius here. So the potential
[416s] ramifications of the changes. So, if you
[419s] have a very small blast radius on a
[421s] two-way door, then, you know, you really
[423s] don't need to like review that PR very
[425s] hard. And so, having this at the bottom,
[427s] probably the, you know, first or second
[429s] thing the person is going to see is
[431s] essential. So, for instance, here's one
[433s] of the PRs in my repo that has been
[435s] provided by the PR skill. This is
[436s] essentially merging two algorithms that
[439s] were basically the same. And we can see
[441s] the files deleted and the files added in
[443s] the right context. We understand the
[445s] functions, the sort of the call stack
[447s] that's being structured here, but
[448s] crucially, we have the evidence. We have
[450s] a before and after on a real entity. So,
[453s] there's no intro in this one, but
[455s] afterwards, it adds the intro, which is
[457s] kind of the behavior that we want here.
[459s] And finally, we can see that the merge
[460s] danger is two-way. It's just a pure
[462s] refactor plus one deliberate behavior
[464s] change, and the blast radius is small.
[466s] So, this PR skill is just become
[468s] absolutely indispensable to my flow. It
[470s] is also one of the most consistently
[472s] invoked model invoke skills that I've
[474s] seen. The you you the user don't have to
[477s] worry about it at all. It seems to just
[479s] invoke it every single time, at least on
[481s] Opus 5.5. So you should just be able to
[483s] download it and just see your PR bodies
[485s] get better. And of course, if you
[487s] already have a PR body skill, then why
[489s] not just steal what you can from this?
[491s] Now, before we talk about the retro
[492s] skill, we should mention that there has
[494s] been a big change in how my especially
[497s] grill with docs function. So let's take
[499s] a look at domain modeling here and
[501s] domain modeling skill now instead of
[505s] writing to context.md writes to
[507s] glossery.mmd. The inspiration for this
[509s] skill came from DDD came from Eric
[512s] Evans's book domain driven design. And
[515s] [snorts] for that I was essentially
[517s] using a file name based on the concept
[520s] of bounded context from DDD. And so this
[523s] used to be context.md like this. But now
[527s] I've sort of moved away from the DDD
[530s] style flow. I mean, I still use DDD in
[533s] all but name, but I wanted a slightly
[536s] less overloaded term here. Context.md
[539s] just felt way too vague. It didn't sort
[542s] of trigger the agent to pull it in at
[543s] the right moment. And for users, it was
[546s] pretty confusing. I also ended up
[547s] reducing the amount of stuff in glossery
[550s] or in context.md until it was literally
[552s] just a glossery. So there really is no
[554s] point anymore. glossery.mmd is now what
[556s] we're going this is also updated
[557s] everywhere and so loads of my skills
[560s] rely on seeing a glossery.mmd in order
[563s] to behave properly in order to use the
[564s] domain language at all points and so you
[567s] will need to definitely update this.
[569s] There's no other behavior changes about
[570s] the skill. It's really literally just a
[572s] file name change and I think that this
[575s] is one that folks have been wanting for
[576s] a while. So I'm glad to ship it. But now
[578s] let's take a look at the retro skill and
[580s] let's actually do it by running it. What
[583s] I noticed with my skill set is that I
[586s] impose a lot I ask a lot of you the
[589s] user. And what I was kind of asking of
[592s] you is you were responsible for overtime
[598s] making changes to the repo that would
[599s] improve it. In other words, I was asking
[601s] you to manage your agents.mmd to manage
[604s] your skills, to make sure that your repo
[606s] was token efficient, to make sure that
[608s] your environment was good and safe for
[610s] the agent to write code in, that you had
[612s] good lint rules, that you had good
[613s] navigation. And I realized that I
[615s] personally was doing a lot of stuff to
[617s] my repos to my agents in order to make
[620s] them easier for me to work with to make
[622s] them more performant. And so I realized,
[624s] why don't I bundle that up into a skill?
[627s] And this is what retro does. It is short
[629s] for retrospective. You run it on a
[632s] coding agent session, either the current
[634s] one or, you know, 10 that I've currently
[637s] got or let's say the previous one, and
[639s] it will suggest improvements for next
[641s] time. The cool thing about actually
[642s] reading real sessions here is that it's
[645s] able to look at what happened with the
[648s] agent. It's able to see the
[650s] inefficiencies that maybe the agent
[651s] actually hides from. I really like this
[653s] post from Andre Retro by Mogers. Game
[655s] changer. My agents are bumping into all
[657s] kinds of problems. that went undetected.
[660s] But due to persistence, the features
[662s] still got built one way or another. In
[663s] other words, the agent doesn't complain,
[665s] I think, as much as it should, and
[668s] doesn't try to fix its own mistakes. You
[671s] kind of need to get another agent to
[673s] look back on those sessions and see
[674s] where it went wrong and see how to help.
[676s] And so, this is what our agent has found
[679s] here. The agent ran an irreversible
[680s] public action before you picked a fix.
[683s] The agent found why the 1.3.0 release
[685s] was missing and then it ran a release
[687s] without actually asking. This is why, by
[689s] the way, when you actually look at the
[690s] releases, you'll see there's no 1.3.0
[693s] release, only a 1.3.1 release. You know,
[695s] Claude kind of screwed this up. I don't
[696s] honestly care that much about it, so I
[699s] don't mind this one in my context. We
[701s] can see that this particular repo in has
[703s] no actual guard rail. So, there is a
[705s] PNPM check script, but nothing actually
[707s] runs it. So, it's suggesting adding a CI
[710s] pipeline here. In here, we can see
[712s] there's context loss happening between
[714s] compactions in long sessions. So, I use
[717s] animatics to kind of create my videos or
[720s] early drafts of them now. And it's
[722s] saying that there's some loss when you
[724s] compact. And so, it's saying move some
[726s] of the repeated instructions into an
[728s] animatic skill. This is definitely a
[730s] really good one, and I'm definitely
[732s] going to implement that for sure. Oh,
[733s] look at this one. A custom CLI that I've
[735s] created for my course video manager
[737s] wastess tokens. So, Retro looks at token
[740s] inefficiency too. Wiki, which is another
[742s] custom CLI, is not on path locally and
[744s] Wiki AI hero has gaps. So, Retro is
[747s] merciless. It will look at your actual
[750s] sessions and see what is going on and it
[752s] will pretty much always find ways to
[754s] improve. Now, what I'd say with Retro is
[756s] you want to use your human judgment when
[759s] you look at these. I know, for instance,
[761s] the thing that it thinks is most serious
[763s] is actually not that bad. It's just a
[766s] release. I can always create and cut new
[768s] releases. And so the way retro works is
[770s] it's designed to be human in the loop.
[772s] It's not designed to just keep creating
[774s] these fixes random. Pretty much everyone
[776s] when I show them this, they go, "Ooh,
[778s] I'd love to automate this." No, you
[779s] don't want to automate this. Automating
[782s] this means that the agent will get
[783s] itself into a loop where it continually
[786s] finds false positives. It continually
[788s] tries to fix things and you'll end up in
[790s] this weird trajectory where it just
[792s] takes the repo and your agent into a
[794s] place it shouldn't really go. So, I
[796s] recommend you run retro on a sampling of
[799s] your agent sessions. Every time you've
[801s] got a free moment and you realize, "Oh,
[803s] I haven't run retro in a while." Just
[805s] try getting it to run through your most
[807s] recent sessions. Maybe a session that
[809s] has gone wrong, let's say, or you feel
[811s] the agent has done something weird, and
[813s] retro will usually find a fix. We can
[815s] see that inside the steps in the retro
[817s] skill, it has several categories for
[819s] improvements that it looks for. How easy
[821s] is your codebase to navigate? Are there
[824s] automated checks that we could add?
[826s] Could we add coding standards for the
[827s] automated reviewer to enforce? How
[830s] healthy is the global agents.mmd? Is the
[832s] tool economy any good? Are there any
[834s] noops in the instructions in steering
[836s] files? Does the agent have access to all
[838s] the information it needs? Overall, I've
[840s] seen my token efficiency and just the
[842s] quality of work that I've been able to
[844s] produce massively increase by running
[846s] retro regularly. And if you want to see
[848s] the quality of your work increase too,
[850s] then I recommend you take my AI coding
[852s] crash course which is on aihero.dev. I'm
[854s] updating this today with a new lesson
[856s] focusing on implement spec. And if you
[857s] want to take control of your coding
[859s] agent and utilize my skills better, then
[861s] this is the place. But folks, thank you
[863s] so much for following along. Hopefully
[864s] you enjoy Skills V1.3. Enjoy seeing the
[868s] uncomfortable truth of how bad your
[870s] agent sessions are with retro.