ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: New Skills! v1.3 brings /pr, /implement-spec, and /retro
กำลังสร้างบทเรียน...
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.
📺 ช่องเดียวกัน
B23
Most devs don't understand what agents are
British AccentBusiness EnglishUniversity StudentsWorking Adults
C12
Most devs don't understand how LLM tokens work
British AccentBusiness EnglishUniversity StudentsWorking Adults
B22
New Skills! v1.2 brings /wait-what, /writing-for-agents, and fixes /grill-me
British AccentBusiness EnglishUniversity StudentsWorking Adults
C14
New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets
British AccentBusiness EnglishUniversity StudentsWorking Adults
C13
mattpocock/skills: A complete AI Coding workflow, end-to-end
British AccentBusiness EnglishUniversity StudentsWorking Adults
B23
I was an AI skeptic. Then I tried plan mode
British AccentBusiness EnglishUniversity StudentsWorking Adults
B23
/wayfinder: Nothing is too big to plan anymore
British AccentBusiness EnglishUniversity StudentsWorking Adults
C15
The 7 phases of AI-driven development
British AccentBusiness EnglishUniversity StudentsWorking Adults
C12
How to actually force Claude Code to use the right CLI (don't use CLAUDE.md)
British AccentBusiness EnglishUniversity StudentsWorking Adults
C13
Learn anything with the /teach skill
British AccentBusiness EnglishUniversity StudentsWorking Adults
C16
5 Claude Code skills I use every single day
British AccentBusiness EnglishUniversity StudentsWorking Adults
C15
Can Cursor's HARDCORE Review Skill Stop The Slop?
British AccentBusiness EnglishUniversity StudentsWorking Adults
C1New Skills! /handoff, /prototype, /review and /writing-* | Skills Changelog
British AccentBusiness EnglishUniversity StudentsWorking Adults
✨ วิดีโอแนะนำ
C11
180 ประโยค
Armchair Architects: Resiliency in the Cloud – Core Patterns
Business EnglishUniversity StudentsWorking Adults
C11
309 ประโยค
Claude Code: The Advanced Guide (99% of Devs Skip These Features)
Business EnglishUniversity StudentsWorking Adults
B2344
28 ประโยค
Weekly Team Meeting: Project Status Update
American AccentBusiness EnglishWorking Adults
C12
20 ประโยค
Is prompt engineering dead? Advice on optimizing AI interactions | Amazon Web Services
Business EnglishUniversity StudentsWorking Adults
C11
108 ประโยค
How I Learned Procedural Generation
Business EnglishUniversity StudentsWorking Adults
C11
157 ประโยค
The Weird Design Playbook of 6 App Outliers
Business EnglishWorking Adults
C11
218 ประโยค
Next.js 16.3 got good (if you care)
Business EnglishUniversity StudentsWorking Adults
C12
182 ประโยค
We Let $200 GPT-Pro Think for 7 Days on Unsolved Math
Business EnglishUniversity StudentsWorking Adults
C11
254 ประโยค
Figma Agent Skills | How to write skills you will actually use
Business EnglishUniversity StudentsWorking Adults
C12
540 ประโยค
Incremental Cooking in UE 5.7: A Dive Into the UE Cook Pipeline | Unreal Fest Chicago 2026
Business EnglishUniversity StudentsWorking Adults
เป้าหมายการพูดสำหรับคลิปนี้
คลิปนี้มุ่งเน้นไปที่การพัฒนาทักษะการพูดภาษาอังกฤษด้วยการใช้เทคนิค "shadow speech" ที่ช่วยให้คุณเรียนรู้การออกเสียงและจังหวะได้อย่างมีประสิทธิภาพ ผ่านการฟังและพูดตามที่ได้ยินในวิดีโอ นอกจากนี้ ยังช่วยเพิ่มความมั่นใจในการใช้ภาษาอังกฤษในสถานการณ์จริง โดยเฉพาะอย่างยิ่งในการอธิบายแนวคิดและกระบวนการต่างๆ ที่เกี่ยวข้องกับการทำงานในชีวิตประจำวัน
ธนาคารวลี
- "implement spec" - การนำเสนอสเปค
- "orchestrate" - การจัดการหรือควบคุม
- "tickets" - ตั๋วหรืองานที่ต้องทำ
- "subagents" - ตัวแทนย่อย
- "deterministic loop" - วงจรที่แน่นอน
การใช้วลีเหล่านี้ในการสนทนาจะทำให้คุณดูเหมือนมีความรู้ความเข้าใจในเรื่องที่พูดมากขึ้น และสามารถใช้ในการอธิบายขั้นตอนหรือแนวคิดให้กับผู้อื่นได้อย่างชัดเจน
แก้ไขจุดอ่อนของคุณ
จะเห็นได้ว่า ในวิดีโอนี้มีการพูดในลักษณะเฉพาะที่อาจจะมีจังหวะและการเน้นเสียงที่ไม่เหมือนกัน การฝึก "shadow speak" จะช่วยให้คุณคุ้นเคยกับการออกเสียงที่ถูกต้องและสร้างจังหวะที่เหมาะสมสำหรับการพูดภาษาอังกฤษ โดยเฉพาะในส่วนที่เกี่ยวกับการแบ่งงานและขั้นตอนการทำงาน ซึ่งจะทำให้คุณสามารถสื่อสารได้อย่างมีประสิทธิภาพยิ่งขึ้น
การฝึกพูดตามจะช่วยให้คุณพัฒนาทักษะการฟังและการพูดไปพร้อมกัน คุณจะสามารถรับรู้ถึงน้ำเสียงและอารมณ์ที่ถูกต้องในแต่ละสถานการณ์ได้มากขึ้น ซึ่งจะทำให้การสื่อสารของคุณมีชีวิตชีวามากขึ้น
อย่าลืมลองฝึกพูดภาษาอังกฤษจากวิดีโอเหล่านี้อย่างต่อเนื่อง เพื่อพัฒนาทักษะการพูดและความมั่นใจของคุณในทุกครั้งที่คุณใช้ภาษาอังกฤษ!
ไวยากรณ์ในวิดีโอนี้
โครงสร้างที่ผู้พูดใช้บ่อยที่สุด พร้อมคำพูดจริงจากวิดีโอ:
| โครงสร้าง | ในวิดีโอ |
|---|---|
| Present perfect continuous have/has been + -ing — การกระทำที่เริ่มก่อนหน้านี้และยังดำเนินอยู่ | I've been reaching · have been wanting |
| Present perfect have/has + กริยาช่อง 3 — เหตุการณ์ในอดีตที่ยังเกี่ยวข้องกับปัจจุบัน | have become · I've just seen · has felt |
| Passive voice be + กริยาช่อง 3 — เน้นสิ่งที่เกิดขึ้น ไม่ใช่ผู้กระทำ | will be implemented · be grabbed · is done |
| Relative clauses who / which + อนุประโยค — ข้อมูลเพิ่มเติมเกี่ยวกับคนหรือสิ่งของ | there, which is · intro, which is · Wiki, which is |
เทคนิค Shadowing คืออะไร?
Shadowing เป็นเทคนิคการเรียนรู้ภาษาที่ได้รับการรับรองทางวิทยาศาสตร์ พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ วิธีการนี้เรียบง่ายแต่ทรงพลัง: คุณฟังเสียงภาษาอังกฤษจากเจ้าของภาษาและพูดตามทันที — เหมือนเงาที่ตามผู้พูดด้วยช่วงเวลาห่าง 1-2 วินาที การวิจัยแสดงว่าเทคนิคนี้ปรับปรุงความแม่นยำในการออกเสียง ทำนองเสียง จังหวะ การเชื่อมเสียง การฟังเข้าใจ และความคล่องแคล่วในการพูดได้อย่างมีนัยสำคัญ