シャドーイング練習: New Skills! /handoff, /prototype, /review and /writing-* | Skills Changelog - 動画で英語スピーキングを学ぶ

But the skills repo continues to go absolutely freaking nuts, cresting 70k stars just the last couple of days.

And of course I have continued working on it, so there is plenty more to look at in this week's changelog.

The big news is that I have added two brand new skills, the first one being this handoff skill which I showed on Twitter and people went absolutely nuts for.

Let's just read the skill, because actually reading the skill really explains the skill this time.

The description is, we're going to compact the current conversation into a handoff document for another agent to pick up.

Write a handoff document summarising the current conversation so a fresh agent can continue the work.

Save it to a path produced by mictemp t handoff blah blah blah and read the file before you write to it.

So what's going on here is we're going to end up

with a temporary file inside our temporary directory of this name here.

So the idea of this skill is it's creating some documents which is not designed to be kept around.

It's just a handoff document between two agents.

The reason we have read file before you write to it is because in Claude Code, it will error if it hasn't read the file before it attempts to write to it.

So it's just an awkward little bit of Claude Code handholding there.

And then it says suggest the skills to be used, if any, by the next session.

That's an important part of what the handoff document needs to do.

It needs to not only hand off the content of the context window, it also needs to hand off the vibe of the context window and the intent of the context window.

So this means that if you're doing a grilling session and you hand off to another agent, then it will suggest that it continues doing the grilling session.

Another crucial thing here is do not duplicate content already captured in other artifacts.

Reference them by path or URL instead.

And then if the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

Now, why did I create this?

Well, what I found, I was basically doing this manually.

So I was saying, okay, we're inside a grilling session, let's say, and we want to answer a question that can only be answered really by working with code.

Now we could just inside the grilling session just do some prototyping or something, but I always felt that was pretty awkward because it meant that the grilling session,

let's say we were on 60k tokens or something, then I would only have another 40k tokens to prototype and give feedback and iterate

before I started getting worried about the context window.

What I really wanted to do is just open up another context window

with all of the context from the grilling session and just focus on that prototype.

And that's why a handoff really comes into its own.

The way you use this is you just say, okay, Claude Co., just hand me off to another agent and it will produce the document.

And then you take the path of that document and you just pass it into the new agent.

You open up a new terminal and you've got it working in there.

So that means then that you can do your work inside there

and you can even hand back to the previous document just

by saying here's what we learned from prototyping now go back to grilling.

There are two main patterns here.

There's fire

and forget where you basically just go okay I need to

work on something in the middle of another grilling session or you notice a bug during implementation.

Okay you just get it to hand off and this new agent will go and fix the bug.

Then another version of this is kind of what I call DIY subagent, which is kind of what I've just described, where you're inside a grilling session or a planning session,

you realize you need to alter some code, you go off to another agent's context window, and then you hand off back to the original.

So it's kind of like you've got a subagent, but you are in control of the subagent, and the subagent is not hampered in the same way that sub-agents are.

It's got all of its own context window.

It can spawn sub-agents itself.

You get the idea.

And of course, then it can hand off to other agents if you need to.

So handoff, an incredibly cool skill, really useful, obviously, in engineering, but also useful outside of engineering, to be honest.

That's why it's in the productivity section up here.

The next one that I'm really excited by is in the engineering section, and it is a prototype skill.

Prototyping is really critical in especially AI engineering because you essentially need to use prototypes as research,

as spikes, as a way to essentially flush out design decisions before committing to them.

So these are throwaway prototypes.

That's the theory.

And what this is really cool, because you think prototype and you immediately think UI, right?

And obviously this is really, really good for UI.

But UI prototypes are really good for deciding what should this look like or what should this feel like?

How should it behave on the page?

But there's many other situations where prototyping can be really beneficial.

For instance, in business logic, when you have any kind of stateful logic that changes over time,

for instance, an entity in a database that needs to change based on user actions, you can answer that with a logic prototype.

And the theory here is that you can build a tiny interactive terminal app

that pushes the state machine through cases that are harder to reason about on paper.

This has been really, really cool because it just allows you, you can basically say, okay, I've got a vague concept of how this should work.

Build me a prototype here.

And then it will build the prototype.

You can give feedback on the prototype.

It will update the prototype.

And then you can hand off back to another agent that will actually build the thing based on your prototype.

So you should use this when you have some unknown unknowns that you can really only figure out by looking at code.

If you have, let's say, a question that you kind of know the answer to, but maybe you don't, then you can just go, So let's prototype this.

The UI one is really cool because it generates several radically different UI variations

and it also does it actually in the root where you want it to be.

And what you'll get is a kind of floating button at

the bottom of the page where you can click left and right and choose and toggle between the variations.

You can then pick a variation and walk down the design tree and go, okay, I like this about this variation, maybe this from that variation.

take a bit of A and B and combine it into a new one and discard the others.

So this is really, really good for just figuring out what a UI should look like before your AFK agent,

maybe powered by Sandcastle, goes and implements it.

People often ask me like what's the best way to make AFK agents really good at front end

and the answer is prototyping.

You really do need a human to sit in the loop

with the agent to give it feedback on what looks good because UI is so dependent on taste,

so dependent on style in the application and often the AI just simply can't see what it's building.

So you need a human there to really apply their taste to it.

So that is prototype and it is real real good and I hope you enjoy it.

Let's quickly talk about a couple of bug fixes that came up during this as well.

One of which is really interesting.

I took the very you well used skill grill with docs and I wrapped it in a couple of XML tags.

We can see this in the raw here.

So in the raw, basically the issue I was finding is

that grill with docs was a little bit too eager to implement sometimes.

And I think what was happening was that this supporting information here, basically these XML tags didn't exist.

These These XML tags are the new thing.

And what it was doing is

that all of this text down here was kind of being

treated by the LLM as more important than the actual text up here.

So I think of this as kind of like loudness in your prompts where you have some prompts

or some parts of prompts

100

that can often be like competing with each other in terms of the volume

101

and the amount of impact that they have on the final output.

102

And so what I did was I wrapped these in XML tags.

103

I said, OK, this bit up here is the what you're actually doing in this skill.

104

And the bit down here is then supporting info.

105

So this shows the LLM that this isn't like an official thing.

106

This tends to work pretty well with anthropic models.

107

That's certainly in their documentation.

108

And so it means that the stuff inside supporting info is just slightly less prioritized.

109

And that's important.

110

And that's had a really good effect, actually.

111

At least in terms of vibes.

112

I'm not doing evals here should be doing evals on this particular case, but what I'm seeing is that people aren't reporting this anymore since I added these XML tags.

113

One other bug fix that I added is that inside to PRD

114

and to issues I've added this instruction to apply the ready for agent triage label, no need for additional triage.

115

Previously it was saying, okay, add the needs triage label,

116

which just didn't make sense to me because once you've created these issues with to PRD and to issues, if we look at the two issues one,

117

then these are ready for agents.

118

That's the intent of them.

119

Some people have come back and said, should we make the to PRD skill?

120

Like, should we mark that as ready for agents?

121

Because the agent might implement it on its own.

122

And for that, you really need to just tell your agent, no, don't implement PRDs, only implement actual issues.

123

So that's sort of something on the PRD side.

124

Anyway, so that's a bug fix that's gone in on this version.

125

Now finally, I just wanted to show you something I'm working on when it comes to some in-progress stuff.

126

So there are a few, yeah, basically two sets of skills here that are in progress.

127

The first one is a try part skill here, which is me trying to break down what good writing looks like with AI

128

and trying to make that into a repeatable skill.

129

I was just using this this morning and I'm kind of fiddling with it and playing with it and I'm enjoying it.

130

The theory here is that you start by writing fragments.

131

These fragments are pieces of text that you kind of might want to structure into a final piece.

132

The theory here is that authors, they will often keep these long, long journals over many, many years,

133

noticing different things, thinking about their personal life, thinking about their outside life, thinking about their friends, all this stuff.

134

And these fragments end up working their way into stories almost verbatim.

135

And the theory here is that you can use AI for this

136

because AI can prompt you to come up with better fragments.

137

So I tend to just dictate ideas into this and it comes up with this little document of fragments.

138

From there, you can take those fragments and find your way through a potential arc by writing beats.

139

Now, these beats are essentially just beats through a potential story.

140

But, you know, if you imagine a story or an article or a newsletter in my case, where you might want to like, okay, you need to find some path through the many,

141

many possible paths, then writing beats allows you to do that

142

because it basically just gives you three options for where you want to go next

143

and then write those beats based on the fragments.

144

And then finally, there's this sort of writing shape here, which is a kind of review process where you go back through, make sure it doesn't sound too AIE,

145

make sure it's structured in the right way and you do a kind of final pass over it.

146

So that is the theory and I'm really interested to see how that shapes up.

147

I don't think they're going to be ready anytime soon.

148

I really, really need to put some work into developing those skills, but you're free to try them if you like.

149

Then we have one which I think a lot of people have anticipated for a while, which is this review skill, which is a code review skill.

150

And I've really been wanting to, I've been dragging my heels on this because writing a generic code review skill is really hard.

151

But the theory is that I've come up with two possible strands to make it work.

152

These two strands are essentially comparing it along two axes.

153

So either the standards set in the code base, so does the diff follow the repo's coding standards, and spec, does the diff actually faithfully implement the original issue or PRD.

154

I've found that if you only focus on standards, then you're going to miss spec stuff and if you only focus on the spec, then you're going to miss standards stuff.

155

So the theory is that the review skill will kick off two parallel sub-agents which check it along that.

156

Now standards is the trickier one because everyone's coding standards are different and people will need different things.

157

So I think I'm going to need to make a skill that tries to extract out coding standards from your repo

158

in order to give you a fighting chance of kind of making it the best it can possibly be.

159

and I think that will be a different skill itself.

160

So lots of work happening in this area.

161

Hope it's exciting.

162

Finally, we are working on a doc site here

163

which is going to have videos of each individual skill and it also has a newsletter here.

164

This is going to my main newsletter

165

and you can always opt out of the skill stuff but if you really enjoy these skill updates, if you want to follow everything that I'm doing, then this is the place.

166

Thanks so much for following along.

167

Thank you so much for giving me such good feedback about these skills.

168

It motivates me to keep working on them

169

and I really love just seeing people crack AI finally with these skills and also modifying them for their own uses.

170

So thanks for watching and I'll see you in the next one.

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

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

シャドーイング練習: New Skills! /handoff, /prototype, /review and /writing-* | Skills Changelog - 動画で英語スピーキングを学ぶ

なぜこのビデオでスピーキングを練習するべきか？

文法と表現のコンテキスト

一般的な発音の罠

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