シャドーイング練習: New Skills! v1.3 brings /pr, /implement-spec, and /retro - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

214 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

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.

The first place I want to start is the implement spec skill.

The 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 autocompact.

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, OK, agent, we are going to implement our first ticket.

You wait for it to be complete.

You clear the context.

And then you say, OK, 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 reads each ticket and then runs implement 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 is 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, OK, why don't we try a middle ground where we have subagents 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 subagents.

And this has recently gotten possible because subagents can themselves spawn subagents.

So before subagents 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 the agent sits there looking at all of the tickets, orchestrating them, and then implements them in subagents.

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.

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 subagent.

It creates an integration branch, and then it goes and uses implementer subagents 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 subagent

and then pings off more implementer subagents until all the work is done.

And once 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'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,

where you don't have your software factory dialed in, I suppose, implement spec has been really, really useful.

It's been 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 my most used recent skills has to be the PR skill.

So prskill .md.

I've been a huge fan of Dex Hawthies 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 really nice pseudocode.

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 agent's 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 its 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 because 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 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 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

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.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

同じチャンネル

New Skills! v1.2 brings /wait-what, /writing-for-agents, and fixes /grill-me

Daily ConversationWorking Adults

New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets

Business EnglishUniversity StudentsWorking Adults

FOR YOU

この動画は誰におすすめ？

英語の会話力向上を目指す中級者から上級者、特にビジネスシーンや技術的な議論で使える実践的な表現を学びたい人にぴったりです。動画では技術用語やワークフローに関する説明が中心で、リアルな会話のリズムや論理的な展開を学ぶことができます。英語シャドーイングの練習にも最適で、「AFK workflows」のような最新の表現を自然に使いこなすコツがつかめます。

覚えておきたいフレーズ&イディオム

go nuts：「大興奮する」「夢中になる」。動画では「人々がこのスキルに夢中になっている」と使われています。
dumb zone：「鈍感な領域」。ここでは「コーディングエージェントが効率的に機能しない状態」を指します。
AFK workflows：「離席中のワークフロー」。「Away From Keyboard」の略で、自分が席を離れていても自動的に進む作業プロセスを意味します。

これらのフレーズは日常会話だけでなく、ミーティングやレポートでも活躍します。shadow speakの練習では、発音とともに使い方も覚えておきましょう。

アクセントのコツをマスター！

この動画のスピーカーは速めの口調ですが、重要な単語にはアクセントが置かれています。例えば「deterministic loop」では「de-TER-mi-nis-tic」の部分に強調があり、「orchestrate」は「OR-ches-trate」と発音します。shadowspeaksの練習では、これらの強調部分を真似ることで、自然なリズムを身につけられます。また、「you know」「I think」などのフィラーワードの使い方も覚えると、会話がより自然になります。

少しずつ繰り返し練習することで、この動画の表現やアクセントを完璧にマスターできます。shadow speechで楽しく英語力を上げましょう！

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
現在完了進行形 have/has been + -ing — 以前に始まり今も続いている動作	I've been reaching · have been wanting
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	have become · I've just seen · has felt
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	will be implemented · be grabbed · is done
関係詞節 who / which + 節 — 人や物について情報を加える	there, which is · intro, which is · Wiki, which is

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: New Skills! v1.3 brings /pr, /implement-spec, and /retro - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

同じチャンネル

New Skills! v1.2 brings /wait-what, /writing-for-agents, and fixes /grill-me

New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets

mattpocock/skills: A complete AI Coding workflow, end-to-end

I was an AI skeptic. Then I tried plan mode

/wayfinder: Nothing is too big to plan anymore

The 7 phases of AI-driven development

How to actually force Claude Code to use the right CLI (don't use CLAUDE.md)

Learn anything with the /teach skill

5 Claude Code skills I use every single day

Most devs don't understand what agents are

Can Cursor's HARDCORE Review Skill Stop The Slop?

Most devs don't understand how LLM tokens work

New Skills! /handoff, /prototype, /review and /writing-* | Skills Changelog

おすすめ動画

Claude Code: The Advanced Guide (99% of Devs Skip These Features)

Weekly Team Meeting: Project Status Update

The Weird Design Playbook of 6 App Outliers

AI-First Playbook: Do a Team's Work With AI (2026) | Peter Yang

JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue

Basic Opt Flw regimes

Incremental Cooking in UE 5.7: A Dive Into the UE Cook Pipeline | Unreal Fest Chicago 2026

Overcoming Service Blueprinting Frustrations

How To Effectively Leverage Skip Level 1 1s

Introducing Automations: always-on coding agents

この動画は誰におすすめ？

覚えておきたいフレーズ&イディオム

アクセントのコツをマスター！

この動画の文法

シャドーイングとは？英語上達に効果的な理由