Hello folks, version 1.3 of my skills

repo is out and it brings three very

important skills that have become

central to my workflow. Today I'm going

to show you about implement spec. I'm

going to show you about PR and I'm going

to show you about retro. And retro I

think is the one that I've just seen

absolutely go nuts on socials. People

going crazy for this skill and it has

felt incredibly powerful to me too. And

the first place I want to start is the

implement spec skill. The main flow of

my approach for landing huge chunks of

work at once is essentially two

different entities. You have a spec and

then you have the tickets that implement

that spec. The spec kind of acts like

the place where you're going and then

the tickets break that destination down

into a set of sessions that you can then

run in a single coding agent. If you try

to implement the spec all in one coding

agent, you would go into the dumb zone

of that coding agent, you might end up

hitting auto compact. And you know,

while that works sometimes, and it is

getting better, I still think that

breaking things down into individual

tickets is just a lot cleaner. Now, the

way that you orchestrate those tickets,

the way that you give them each to one

coding agent has always been a little

bit confusing for users. And I've kind

of been sort of going back and forth

over the way that I recommend you do

this. The most annoying and manual way

to do this is managing it yourself where

you the user say okay uh agent we are

going to implement our first ticket. You

wait for it to be complete. You clear

the context and then you say okay

implement ticket two. You wait. You

clear the context. You say implement

ticket three. You're kind of acting like

a for loop there. It's not really

workable. So that is what I would

describe as the manual loop there which

is not much fun. But you can change that

by having a deterministic loop where you

have a script that reach uh reads each

ticket and then runs implements on it

itself. This is how I recommend that

most people do this because once you've

set up your deterministic loop, it's

going to run the same way every time.

It's very reliable and it's cheap,

right? Because you're not using an agent

or you're not using a human to run that

loop. You just essentially get a script

to do it for you. But setting this up is

quite complicated and requires a lot of

patience as you sort of refine your loop

and get it better and better. And so I

see this as out of range for beginners.

And so I wanted some way of allowing

beginners to see not have to manually

loop it themselves. And so I decided,

okay, why don't we try a middle ground

where we have sub agents go through and

implement the loop. In other words, an

agent does the babysitting instead of a

human. This means that all of the

tickets will be implemented by sub

agents. And this has recently gotten

possible because sub aents can

themselves spawn sub aents. So before

sub agents were kind of a little bit

nerfed whereas now they're actually as

powerful as orchestrator agents. And so

this is what implement spec does is it

the agent sits there looking at all of

the tickets orchestrating them and then

implements them in sub aents. This is I

would say worse than doing a

deterministic loop because the

deterministic loop again it's

deterministic. It works the same way

every time. But implement spec is a good

way to get started with AFK workflows

away from keyboard workflows where you

step away and it implements the entire

spec. Before you use any skill, you

should read the entire skill. And it's

not particularly long here. There are

nine steps in its process and it's got a

little bit of reference material just at

the top. One crucial thing is it goes

for parallelization where it can. And so

this says the tickets are not a list of

steps. They're a task graph with

blocking relationships between them.

That means there's always a frontier of

tickets that are ready to be grabbed. If

we take a look at the steps, we can see

it reads the spec and tickets. It does a

little bit of exploration in its own sub

agent. It creates an integration branch

and then it goes and uses implement sub

aents to implement each ticket using TDD

and using work trees too. Once that's

done, it merges its work to the

integration branch with a sub aent and

then pings off more implement sub aent

until all the work is done. And once it

the work is done, it goes and calls code

review on the integration branch. Then

it cleans up all of its work and makes

the PR ready for review. So you get a

single PR off this huge great big spec.

I have been reaching for this a lot more

than I thought I would, especially on

systems where you haven't set up these

deterministic scripts yet, where you

don't have your like software factory

dialed in. I suppose implement spec has

been really really useful. It's been in

in progress for a while now, but I

thought now's the moment. Let's graduate

this so people can use it and fiddle

around with it and build their own

version of this, too. This is a basic

version of how you might implement your

own spec. You could do something totally

different to this. You could use stacked

PRs. You could do all sorts of stuff.

And in fact, talking of PRs, one of uh

my most used recent skills has to be the

PR skill. So, PR skill.md. I've been a

huge fan of Dex Hies for a while now. I

recently got to meet up with him in

person and he has this gorgeous skill

called Show Me. What show me does is it

helps the user understand the current

topic visually with concise diagrams and

it uses all of this like uh really nice

pseudo code. This looks a little bit

garbage, but actually when you see it in

the context of a PR, it really makes the

PR a lot easier to read and review. PRs

are still the main bottleneck for work

getting to Maine. And my goal with this

PR skill, kind of inspired by Show Me,

is to make human review as easy as

possible. And in the skill, we provide

essentially a template for writing a PR

body. That's all the skill does. We

first start with a summary based on the

kind of show me template which we

include in the skill and then we ask for

evidence. So before and after. This

evidence is an essential part of

learning to trust your agent, learning

to trust your agents outputs. and

actually prompting it to provide

evidence often means it runs an extra

test or it takes an extra screenshot if

it has that ability and it provides you

runtime information on that it's actual

change is doing what it thinks it's

doing without asking for hard evidence

it's very easy for agents to say yeah

that probably works cuz I've read the

code but no verification is something

I'm beginning to be really obsessed with

especially after my recent interview

with Lauren and then the third heading

here is merge danger so how dangerous Is

this PR going to be to merge? One

metaphor I've really like here is, is

this a one-way door or is this a two-way

door? A two-way door is a door that you

can walk back through. In other words,

we can easily revert this PR. But a

one-way door is a, you know, a PR that's

going to do something out in the world.

It's going to delete some data or it's

going to be expensive in some way to

roll back. And then finally, you have

blast radius here. So the potential

ramifications of the changes. So, if you

have a very small blast radius on a

two-way door, then, you know, you really

don't need to like review that PR very

hard. And so, having this at the bottom,

probably the, you know, first or second

thing the person is going to see is

essential. So, for instance, here's one

of the PRs in my repo that has been

provided by the PR skill. This is

essentially merging two algorithms that

were basically the same. And we can see

the files deleted and the files added in

the right context. We understand the

functions, the sort of the call stack

that's being structured here, but

crucially, we have the evidence. We have

a before and after on a real entity. So,

there's no intro in this one, but

afterwards, it adds the intro, which is

kind of the behavior that we want here.

And finally, we can see that the merge

danger is two-way. It's just a pure

refactor plus one deliberate behavior

change, and the blast radius is small.

So, this PR skill is just become

absolutely indispensable to my flow. It

is also one of the most consistently

invoked model invoke skills that I've

seen. The you you the user don't have to

worry about it at all. It seems to just

invoke it every single time, at least on

Opus 5.5. So you should just be able to

download it and just see your PR bodies

get better. And of course, if you

already have a PR body skill, then why

not just steal what you can from this?

Now, before we talk about the retro

skill, we should mention that there has

been a big change in how my especially

grill with docs function. So let's take

a look at domain modeling here and

domain modeling skill now instead of

writing to context.md writes to

glossery.mmd. The inspiration for this

skill came from DDD came from Eric

Evans's book domain driven design. And

[snorts] for that I was essentially

using a file name based on the concept

of bounded context from DDD. And so this

used to be context.md like this. But now

I've sort of moved away from the DDD

style flow. I mean, I still use DDD in

all but name, but I wanted a slightly

less overloaded term here. Context.md

just felt way too vague. It didn't sort

of trigger the agent to pull it in at

the right moment. And for users, it was

pretty confusing. I also ended up

reducing the amount of stuff in glossery

or in context.md until it was literally

just a glossery. So there really is no

point anymore. glossery.mmd is now what

we're going this is also updated

everywhere and so loads of my skills

rely on seeing a glossery.mmd in order

to behave properly in order to use the

domain language at all points and so you

will need to definitely update this.

There's no other behavior changes about

the skill. It's really literally just a

file name change and I think that this

is one that folks have been wanting for

a while. So I'm glad to ship it. But now

let's take a look at the retro skill and

let's actually do it by running it. What

I noticed with my skill set is that I

impose a lot I ask a lot of you the

user. And what I was kind of asking of

you is you were responsible for overtime

making changes to the repo that would

improve it. In other words, I was asking

you to manage your agents.mmd to manage

your skills, to make sure that your repo

was token efficient, to make sure that

your environment was good and safe for

the agent to write code in, that you had

good lint rules, that you had good

navigation. And I realized that I

personally was doing a lot of stuff to

my repos to my agents in order to make

them easier for me to work with to make

them more performant. And so I realized,

why don't I bundle that up into a skill?

And this is what retro does. It is short

for retrospective. You run it on a

coding agent session, either the current

one or, you know, 10 that I've currently

got or let's say the previous one, and

it will suggest improvements for next

time. The cool thing about actually

reading real sessions here is that it's

able to look at what happened with the

agent. It's able to see the

inefficiencies that maybe the agent

actually hides from. I really like this

post from Andre Retro by Mogers. Game

changer. My agents are bumping into all

kinds of problems. that went undetected.

But due to persistence, the features

still got built one way or another. In

other words, the agent doesn't complain,

I think, as much as it should, and

doesn't try to fix its own mistakes. You

kind of need to get another agent to

look back on those sessions and see

where it went wrong and see how to help.

And so, this is what our agent has found

here. The agent ran an irreversible

public action before you picked a fix.

The agent found why the 1.3.0 release

was missing and then it ran a release

without actually asking. This is why, by

the way, when you actually look at the

releases, you'll see there's no 1.3.0

release, only a 1.3.1 release. You know,

Claude kind of screwed this up. I don't

honestly care that much about it, so I

don't mind this one in my context. We

can see that this particular repo in has

no actual guard rail. So, there is a

PNPM check script, but nothing actually

runs it. So, it's suggesting adding a CI

pipeline here. In here, we can see

there's context loss happening between

compactions in long sessions. So, I use

animatics to kind of create my videos or

early drafts of them now. And it's

saying that there's some loss when you

compact. And so, it's saying move some

of the repeated instructions into an

animatic skill. This is definitely a

really good one, and I'm definitely

going to implement that for sure. Oh,

look at this one. A custom CLI that I've

created for my course video manager

wastess tokens. So, Retro looks at token

inefficiency too. Wiki, which is another

custom CLI, is not on path locally and

Wiki AI hero has gaps. So, Retro is

merciless. It will look at your actual

sessions and see what is going on and it

will pretty much always find ways to

improve. Now, what I'd say with Retro is

you want to use your human judgment when

you look at these. I know, for instance,

the thing that it thinks is most serious

is actually not that bad. It's just a

release. I can always create and cut new

releases. And so the way retro works is

it's designed to be human in the loop.

It's not designed to just keep creating

these fixes random. Pretty much everyone

when I show them this, they go, "Ooh,

I'd love to automate this." No, you

don't want to automate this. Automating

this means that the agent will get

itself into a loop where it continually

finds false positives. It continually

tries to fix things and you'll end up in

this weird trajectory where it just

takes the repo and your agent into a

place it shouldn't really go. So, I

recommend you run retro on a sampling of

your agent sessions. Every time you've

got a free moment and you realize, "Oh,

I haven't run retro in a while." Just

try getting it to run through your most

recent sessions. Maybe a session that

has gone wrong, let's say, or you feel

the agent has done something weird, and

retro will usually find a fix. We can

see that inside the steps in the retro

skill, it has several categories for

improvements that it looks for. How easy

is your codebase to navigate? Are there

automated checks that we could add?

Could we add coding standards for the

automated reviewer to enforce? How

healthy is the global agents.mmd? Is the

tool economy any good? Are there any

noops in the instructions in steering

files? Does the agent have access to all

the information it needs? Overall, I've

seen my token efficiency and just the

quality of work that I've been able to

produce massively increase by running

retro regularly. And if you want to see

the quality of your work increase too,

then I recommend you take my AI coding

crash course which is on aihero.dev. I'm

updating this today with a new lesson

focusing on implement spec. And if you

want to take control of your coding

agent and utilize my skills better, then

this is the place. But folks, thank you

so much for following along. Hopefully

you enjoy Skills V1.3. Enjoy seeing the

uncomfortable truth of how bad your

agent sessions are with retro.