Pratica di Shadowing: New Skills! v1.3 brings /pr, /implement-spec, and /retro - Impara a parlare inglese con i video

Creazione lezione...
1
Hello, folks.
2
Version 1 .3 of my skills repo is out, and it brings three very important skills that have become central to my workflow.
3
Today, I'm going to show you about implement spec.
4
I'm going to show you about PR, and I'm going to show you about retro.
5
And retro, I think, is the one that I've just seen absolutely go nuts on socials, people going crazy for this skill,
6
and it has felt incredibly powerful to me, too.
7
The first place I want to start is the implement spec skill.
8
The The main flow of my approach for landing huge chunks of work at once is essentially two different entities.
9
You have a spec and then you have the tickets that implement that spec.
10
The spec kind of acts like the place where you're going
11
and then the tickets break that destination down into a set of sessions
12
that you can then run in a single coding agent.
13
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 autocompact.
14
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.
15
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.
16
And I've kind of been sort of going back and forth over the way that I recommend you do this.
17
The most annoying and manual way to do this is managing it yourself, where you, the user, say, OK, agent, we are going to implement our first ticket.
18
You wait for it to be complete.
19
You clear the context.
20
And then you say, OK, implement ticket two.
21
You wait.
22
You clear the context.
23
You say implement ticket three.
24
You're kind of acting like a for loop there.
25
It's not really workable.
26
So that is what I would describe as the manual loop there, which is not much fun.
27
But you can change that by having a deterministic loop where you have a script
28
that reads each ticket and then runs implement on it itself.
29
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.
30
It's very reliable and it's cheap, right?
31
Because you're not using an agent or you're not using a human to run that loop.
32
You just essentially get a script to do it for you.
33
But setting this up is quite complicated
34
and requires a lot of patience as you sort of refine your loop and get it better and better.
35
And so I see this is out of range for beginners.
36
And so I wanted some way of allowing beginners to see not have to manually loop it themselves.
37
And so I decided, OK, why don't we try a middle ground where we have subagents go through and implement the loop?
38
In other words, an agent does the babysitting instead of a human.
39
This means that all of the tickets will be implemented by subagents.
40
And this has recently gotten possible because subagents can themselves spawn subagents.
41
So before subagents were kind of a little bit nerfed, whereas now they're actually as powerful as orchestrator agents.
42
And so this is what implement spec does, is the agent sits there looking at all of the tickets, orchestrating them, and then implements them in subagents.
43
This is, I would say, worse than doing a deterministic loop, because the deterministic loop, again, it's deterministic.
44
It works the same way every time.
45
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.
46
Before you use any skill, you should read the entire skill.
47
And it's not particularly long here.
48
There are nine steps in its process, and it's got a little bit of reference material just at the top.
49
One crucial thing is it goes for parallelization where it can.
50
So this says the tickets are not a list of steps.
51
They're a task graph with blocking relationships between them.
52
That means there's always a frontier of tickets that are ready to be grabbed.
53
If we take a look at the steps, we can see it reads the spec and tickets.
54
It does a little bit of exploration in its own subagent.
55
It creates an integration branch, and then it goes and uses implementer subagents to implement each ticket using TDD and using work trees too.
56
Once that's done, it merges its work to the integration branch with a subagent
57
and then pings off more implementer subagents until all the work is done.
58
And once the work is done, it goes and calls code review on the integration branch.
59
Then it cleans up all of its work and makes the PR ready for review.
60
So you get a single PR off this huge great big spec.
61
I've 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,
62
where you don't have your software factory dialed in, I suppose, implement spec has been really, really useful.
63
It's been in progress for a while now, but I thought now's the moment.
64
Let's graduate this so people can use it and fiddle around with it and build their own version of this too.
65
This is a basic version of how you might implement your own spec.
66
You could do something totally different to this.
67
You could use stacked PRs.
68
You could do all sorts of stuff.
69
And in fact, talking of PRs, one of my most used recent skills has to be the PR skill.
70
So prskill .md.
71
I've been a huge fan of Dex Hawthies for a while now.
72
I recently got to meet up with him in person and he has this gorgeous skill called show me.
73
What show me does is it helps the user understand the current topic visually with concise diagrams
74
and it uses all of this like really nice pseudocode.
75
This looks a little bit garbage but actually
76
when you see it in the context of a PR it really makes the PR a lot easier to read and review.
77
PRs are still the main bottleneck for work getting to Maine.
78
And my goal with this PR skill, kind of inspired by Show Me, is to make human review as easy as possible.
79
And in the skill, we provide essentially a template for writing a PR body.
80
That's all the skill does.
81
We first start with a summary based on the kind of Show Me template, which we include in the skill.
82
And then we ask for evidence.
83
So before and after.
84
This evidence is an essential part of learning to trust your agent, learning to trust your agent's outputs.
85
And actually prompting it to provide evidence often means it runs an extra test
86
or it takes an extra screenshot if it has that ability.
87
And it provides you runtime information on that its actual change is doing what it thinks it's doing.
88
Without asking for hard evidence, it's very easy for agents to say, yeah, that probably works because I've read the code.
89
But no, verification is something I'm beginning to be really obsessed with, especially after my recent interview with Lauren.
90
And then the third heading here is merge danger.
91
So how dangerous is this PR going to be to merge?
92
One metaphor I really like here is, is this a one -way door or is this a two -way door?
93
A two -way door is a door that you can walk back through.
94
In other words, we can easily revert this PR.
95
But a one -way door is a PR that's going to
96
do something out in the world it's going to delete some data
97
or it's going to be expensive in some way to roll back
98
and then finally you have blast radius here
99
so the potential ramifications of the changes so
100
if you have a very small blast radius on a two
101
-way door then you know you really don't need to like review
102
that pr very hard and so having this at the bottom probably the you know first
103
or second thing the person is going to see is essential
104
so for instance here's one of the prs in my repo that has been provided by the PR scale.
105
This is essentially merging two algorithms that were basically the same.
106
And we can see the files deleted and the files added in the right context.
107
We understand the functions, the sort of the call stack that's being structured here.
108
But crucially, we have the evidence.
109
We have a before and after on a real entity.
110
So there's no intro in this one, but afterwards it adds the intro, which is kind of the behavior that we want here.
111
And finally, we can see that the merge danger is two ways, just a pure refactor plus one deliberate behavior change and the blast radius is small.
112
So this PR skill has just become absolutely indispensable to my flow.
113
It is also one of the most consistently invoked model invoke skills that I've seen.
114
You, the user, don't have to worry about it at all.
115
It seems to just invoke it every single time, at least on Opus 5 .5.
116
So you should just be able to download it and just see your PR bodies get better.
117
And of course, if you already have a PR body skill, then why not just steal what you can from this.
118
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.
119
So let's take a look at domain modeling here and domain modeling skill.
120
Now, instead of writing to context .md, writes to glossary .md.
121
The inspiration for this skill came from DDD, came from Eric Evans's book Domain Driven design.
122
And for that, I was essentially using a file name based on the concept of bounded context from DDD.
123
And so this used to be context .md like this.
124
But now I've sort of moved away from the DDD style flow.
125
I mean, I still use DDD in all but name, but I wanted a slightly less overloaded term here.
126
Context .md just felt way too vague.
127
It didn't sort of trigger the agent to pull it in at the right moment.
128
And for users, it was pretty confusing.
129
I also ended up reducing the amount of stuff in glossary or in context .md until it was literally just a glossary.
130
So there really is no point anymore.
131
Glossary .md is now what we're going.
132
This is also updated everywhere.
133
And so loads of my skills rely on seeing a glossary .md in order to behave properly, in order to use the domain language at all points.
134
And so you will need to definitely update this.
135
There's no other behavior changes about the skill.
136
It's really literally just a file name change.
137
And I think that this is one that folks have been wanting for a while.
138
So I'm glad to ship it.
139
But now let's take a look at the retro skill.
140
And let's actually do it by running it.
141
What I noticed with my skill set is that I impose a lot.
142
I ask a lot of you, the user.
143
And what I was kind of asking of you is you were responsible for,
144
over time, making changes to the repo that would improve it.
145
In other words, I was asking you to manage your agents .md, to manage your skills, to make sure that your repo was token efficient,
146
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.
147
And I realized
148
that I personally was doing a lot of stuff to my
149
repos to my agents in order to make them easier for me to work with, to make them more performant.
150
And so I realized, why don't I bundle that up into a skill?
151
And this is what retro does.
152
It is short for retrospective.
153
You run it on a coding agent session, either the current one or 10 that I've currently got, or let's say the previous one,
154
and it will suggest improvements for next time.
155
The cool thing about actually reading real sessions here is that it's able to look at what happened with the agent.
156
It's able to see the inefficiencies that maybe the agent actually hides from.
157
I really like this post from Andre.
158
Retro by Matt Parker's Game Changer.
159
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.
160
In other words, the agent doesn't complain, I think, as much as it should and doesn't try to fix its own mistakes.
161
You kind of need to get another agent to look back on those sessions
162
and see where it went wrong and see how to help.
163
And so this is what our agent has found here.
164
The agent ran an irreversible public action before you picked a fix.
165
The agent found why the 1 .3 .0 release was missing and then it ran a release without actually asking.
166
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.
167
You know, Claude kind of screwed this up.
168
I don't honestly care that much about it, so I don't mind this one in my context.
169
We can see that this particular repo in has no actual guardrail.
170
So there is a PNPM check script, but nothing actually runs it.
171
So it's suggesting adding a CI pipeline here.
172
And here we can see there's context loss happening between compactions in long sessions.
173
So I use animatics to kind of create my videos or early drafts of them now.
174
And it's saying that there's some loss when you compact.
175
And so it's saying move some of the repeated instructions into an animatic skill.
176
This is definitely a really good one.
177
And I'm definitely going to implement that for sure.
178
Or look at this one.
179
A custom CLI that I've created for my course video manager, wastes tokens.
180
So Retro looks at token inefficiency too.
181
Wiki, which is another custom CLI, is not on path locally and Wiki AI Hero has gaps.
182
So Retro is merciless.
183
It will look at your actual sessions and see what is going on
184
and it will pretty much always find ways to improve.
185
Now, what I'd say with Retro is you want to use your human judgment when you look at these.
186
I know, for instance, the thing that it thinks is most serious is actually not that bad.
187
It's just a release.
188
I can always create and cut new releases.
189
And so the way retro works is it's designed to be human in the loop.
190
It's not designed to just keep creating these fixes random.
191
Pretty much everyone when I show them this, they go, oh, I'd love to automate this.
192
No, you don't want to automate this.
193
Automating this means that the agent will get itself into a loop where it continually finds false positives.
194
It continually tries to fix things, and you'll end up in this weird trajectory where it just takes the repo
195
and your agent into a place it shouldn't really go.
196
I recommend you run retro on a sampling of your agent sessions.
197
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.
198
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.
199
We can see that inside the steps in the retro skill, it has several categories for improvements that it looks for.
200
How easy is your code base to navigate?
201
Are there automated checks that we could add?
202
Could we add coding standards for the automated reviewer to enforce?
203
How healthy is the global agents .md?
204
Is the tool economy any good?
205
Are there any no -ops in the instructions and steering files?
206
Does the agent have access to all the information it needs?
207
Overall, I've seen my token efficiency and just the quality of work
208
that I've been able to produce massively increase by running retro regularly.
209
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.
210
I'm updating this today with a new lesson focusing on implement spec.
211
And if you want to take control of your coding agent and utilize my skills better, then this is the place.
212
But folks, thank you so much for following along.
213
Hopefully you enjoy skills v1 .3.
214
Enjoy seeing the uncomfortable truth of how bad your agent sessions are with Retro, and I'll see you in the next one.

Vocabolario e note di pronuncia per questa lezione

Questo video contiene 214 frasi e 2897 parole da ripetere con lo shadowing. Il parlato dura 14:33. Chi parla va veloce, circa 199 parole al minuto: aspettati suoni legati e ridotti. Solo il 81% delle parole rientra nelle 3.000 più comuni dell’inglese, quindi il lessico è impegnativo.

Vocaboli chiave di questo video

15 parole del video che vale la pena imparare, con pronuncia e significato:

ParolaPronunciaSignificato
skill sostantivo/skɪl/abilità, capacità
implement verbo/ˈɪmpləmənt/mettere in pratica, attuare
loop sostantivo/luːp/cappio
essentially avverbio/ɪˈsɛnʃəli/in essenza
merge verbo/mɝd͡ʒ/fondersi, unirsi
script sostantivo/skɹɪpt/scritto
domain sostantivo/ˌdəʊˈmeɪ̯n/dominio
token sostantivo/ˈtoʊkən/simbolo, segno
blast sostantivo/blæst/raffica, folata
folk sostantivo/foʊk/gente, autoctono
integration sostantivo/ˌɪn.tɪˈɡɹeɪ.ʃən/integrazione
radius sostantivo/ˈɹeɪ.di.əs/radio
custom sostantivo/ˈkʌstəm/usanza, costume
manual sostantivo/ˈmæn.j(u)əl/manuale, guida
delete verbo/dɪˈliːt/cancellare, eliminare

I phrasal verb che sentirai

ParolaPronunciaSignificato
end up verboandare a finire, finire
set up verbo/ˌsɛt ˈʌp/preparare, installare
clean up verboripulire
go back verbotornare
go through verboattraversare

La grammatica di questo video

Le strutture che chi parla usa di più, con le parole esatte del video:

StrutturaNel video
Present perfect continuous have/has been + -ing — un’azione iniziata prima e ancora in corsoI've been reaching · have been wanting
Present perfect have/has + participio passato — un’azione passata che conta ancora adessohave become · I've just seen · has felt
Forma passiva be + participio passato — conta ciò che accade, non chi lo fawill be implemented · be grabbed · is done
Frasi relative who / which + frase — un’informazione in più su una persona o una cosathere, which is · intro, which is · Wiki, which is

Pronuncia a cui fare attenzione

Chi parla usa 46 contrazioni e forme ridotte, come I've, don't, I'm. Pronunciale nella forma breve, così come le senti.

  • I suoni “sh” e “zh”: speculation /ˌspɛk.jəˈleɪ.ʃən/, essentially /ɪˈsɛnʃəli/, integration /ˌɪn.tɪˈɡɹeɪ.ʃən/, instruction /ɪnˈstɹʌkʃən/, efficient /ɪˈfɪʃənt/
  • Parole lunghe — attenzione all’accento: speculation /ˌspɛk.jəˈleɪ.ʃən/, essentially /ɪˈsɛnʃəli/, integration /ˌɪn.tɪˈɡɹeɪ.ʃən/, entity /ˈɛn.tə.ti/ [-tʰi], continually /kənˈtɪnjuəli/

Come esercitarsi con questo video

  1. Ascolta tutto il video una volta senza parlare e annota le parole che non conosci.
  2. Inizia a velocità 0,75×, fai shadowing frase per frase e torna alla velocità normale quando diventa facile.
  3. Registrati e confronta con l’originale, facendo attenzione a parole come skill, implement, loop.

Cos'è la tecnica dello Shadowing?

Shadowing è una tecnica di apprendimento delle lingue supportata da studi scientifici, originariamente sviluppata per la formazione dei traduttori professionisti e resa popolare dal poliglotta Dr. Alexander Arguelles. Il metodo è semplice ma potente: ascolti un audio in inglese di madrelingua e lo ripeti immediatamente ad alta voce — come un'ombra che segue il parlante con un ritardo di solo 1–2 secondi. A differenza dell'ascolto passivo o degli esercizi di grammatica, lo shadowing costringe il tuo cervello e i muscoli della bocca a elaborare e riprodurre simultaneamente i modelli di discorso reale. La ricerca dimostra che migliora significativamente la precisione della pronuncia, l'intonazione, il ritmo, il discorso connesso, la comprensione dell'ascolto e la fluidità del parlato — rendendolo uno dei metodi più efficaci per la preparazione alla prova di speaking dell'IELTS e per la comunicazione reale in inglese.

Tecnica dello shadowing: leggi la guida completa passo dopo passo →