쉐도잉 연습: Can Cursor's HARDCORE Review Skill Stop The Slop? - 영상으로 영어 말하기 배우기

연습 모드 선택

각 모드는 전체 화면 연습실로 열립니다.

230 문장

문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.

Automated code review is one of the most impactful ways that you can improve the code quality coming out of your agent.

I've known this for a while, but it's taking me a while to kind of implement it

and figure out a reusable skill that I can give to people to review their code.

I've got this review skill here in my skills repo, which is currently sitting at 109,000 stars,

and it is currently marked as in progress.

I'm sort of okay with it, but I'm not terribly happy with it.

So I've been looking around for inspiration in other skills that I can copy from, steal ideas from, and one crossed my path that I want to show you.

It is this one from the Cursed team.

It is the Thermonuclear Code Quality Review.

Use this skill for an unusually strict review focused on implementation quality, maintainability, abstraction quality and codebase health.

And one thing I think is notable about this skill is how ambitious it asks the reviewer to be.

asking it to be very ambitious and look for code judo moves throughout the review.

The skill itself is simply one file.

It's just a skill.md up here.

And what I thought I'd do is I would copy it to my local system, try it out on some actual code of mine, and see what it comes up with.

Yesterday, I spent a lot of time working on Sandcastle, my open source software factory.

And so I figure I would review the last X number of commits and see what it thought about them.

So I'm going to be pretty loose here.

I'm just going to say thermonuclear code quality review.

Review the last five PRs that made it to main.

I'm going to stick it on auto mode and

while it's doing this let's go and actually read the skill because that should explain the skill a bit more.

So it starts from this baseline.

Perform a deep code quality audit of the current branch's changes.

Rethink how to structure implement the changes to meaningfully improve code quality without impacting behavior.

Work to improve abstractions, modularity, reduce spaghetti code.

Improve succinctness and legibility. Be ambitious.

If there is a clear path to improving the implementation that involves restructuring some of the code base, go for it.

Be extremely thorough and rigorous.

Measure twice, cut once.

What I've often found with review skills like this is that the agent is not ambitious enough.

If you pass an agent a diff, then it will usually treat that diff as its bounds within which it can work.

Whereas this prompt appears to be going beyond that.

It's essentially saying look throughout the entire code base for opportunities, but starting from this current branch's changes.

It also goes on to add a bunch of non-negotiable additional standards.

Be ambitious about structural simplification.

Again, the ambition.

Do not let a PR push a file from under 1K lines to over 1K lines without a very strong reason.

This is really interesting.

I've actually reached this conclusion myself as well large files are just quite hard for agents to navigate

because they need to ingest the entire file into their context

window in order to find the thing that's actually useful within it.

A much better way to structure that is to split them into multiple files

and let the file name of the file be the context pointer

that tells it what's in that file and whether it might need to open it.

This ends up being a lot more context efficient.

I have generally split my files if if they go over 5K tokens, but this 1K lines is sort of, I guess, a similar rubric.

Do not allow random spaghetti growth in existing code.

Okay, I see, It's sort of arguing against nesting here.

If a change adds weird if statements in random places, treat that as a design problem, not a stylistic knit.

Prefer pushing the logic into a dedicated abstraction helper state machine policy object or separate module instead of tangling an existing path.

Interesting.

This is another way of telling it to be aggressive about, you know, if there's a bunch of nested if statements and weird conditionals,

maybe abstract that into a cleaner abstraction or a helper or something.

It's arguable whether I prefer that.

I suppose sometimes I do, sometimes I don't.

But let's assume it's a good thing for now.

Bias towards cleaning the design, not just accepting working code.

Again, pushing it to be ambitious.

Prefer direct, boring, maintainable code of a hacky and magical code.

This is like a classic one in these prompts.

This comes from, I think, Simplify in Claude Code.

Not the same wording, I think, but a similar idea that you want simple, direct code that's easy to read.

I really like this one, actually.

Push hard on type and boundary cleanliness when they affect maintainability.

So we're specifically talking about types here.

Question unnecessary optionality, unknown, any, or cast heavy code when a clearer type boundary could exist.

This is kind of TypeScript focused here.

Unknown and any are specifically TypeScript terms.

And the unnecessary optionality is one that always gets me.

Whenever an agent adds a prop onto a React component, let's say, it always adds it as optional.

I don't know why.

It's so stupid.

Even when it's always required, it will add it as optional just to make it backwards compatible or something, or to lessen the blast radius of the change.

So yeah, question unnecessary optionality is a great one.

Keep logic in the canonical layer and reuse existing helpers.

Prefer existing canonical utilities and helpers over bespoke one-offs.

Yes, I suppose it's basically just telling it to look for

places where this has already been solved in the code base and use those instead.

Makes sense.

Treat unnecessary sequential orchestration and non-atomic updates as design smells when the cleaner structure is obvious.

If independent work is serialized for no good reason, ask whether the flow should run in parallel instead.

I see.

This is about performance, essentially.

Obviously, when two things that are independent, if they run in parallel, then it's going to be faster than if they run sequentially.

So that's kind of what it's going for here.

But it's also saying do not over-index on micro-optimizations.

Okay, so it's basically telling it don't go too far.

I think if this was my skill, I would definitely rewrite this to be a lot more direct.

Treat unnecessary sequential orchestration, non-atomic updates as design smells.

That's just word salad to me.

I don't know what that means.

So this is really cool.

Primer review questions.

For every meaningful change, ask, is there a code judo move that would make this dramatically simpler?

That's great.

I love that.

Can this be reframed so that fewer concepts, branch or helper layers are needed?

100

Lovely.

101

I don't love this.

102

Does this improve or worsen the local architecture?

103

You've got to say exactly what good

104

and bad looks like to an agent in order for improve or worsen to mean anything.

105

Overall, this set of questions, along with the kind of rules above, give the agent a nice kind of way in to talking about the code, which is what you need.

106

And now it talks about really bad stuff.

107

Escalate findings when you see a complicated implementation where a cleaner reframing could delete whole categories of complexity.

108

Refactors that move code around but fail to reduce the number of concepts a reader must hold in their head.

109

Yeah, there's a bit of repetition going on here unnecessary casts, any unknown or optional params.

110

What sort of scares me about these big review-based prompts is

111

that this is a huge ball of mud for the agent to read.

112

Like, there's a lot of instructions in here, and it's hard to know what to prioritize for the agent.

113

So I don't know.

114

This makes me a little bit nervous.

115

I do like this, though.

116

When you identify a code quality problem, perverse suggestions like delete a whole layer of indirection rather than polishing it.

117

Again, ambition.

118

Split a large file into smaller focused modules.

119

Again, you know, making things easier to navigate for the agent.

120

Again, duplication.

121

Make type boundaries more explicit so the control flow gets simpler.

122

There's a lot of duplication throughout a lot of this.

123

This could be cut down, I think, quite a lot.

124

Review tone.

125

I don't know why this is here.

126

This is just sort of saying choose your tone, I suppose.

127

Be direct, serious, and demanding about quality.

128

Do not be rude.

129

This seems like a crazy thing to add to a skill.

130

I don't know why that's here.

131

What this does do is it does really punch the language that the agent should be using.

132

So we're really emphasizing code judo, saying decompose, pushes the file past, makes the surrounding code more spaghetti.

133

I like that.

134

But the down we can say output expectations.

135

Right.

136

This is nice.

137

It's saying to prioritize findings in this order.

138

It's saying to float the important stuff to the top and legibility and maintainability concerns are at the bottom.

139

Structural code quality regressions right at the top.

140

Right.

141

And it is asking for an approval here.

142

So it's approving or rejecting the PR.

143

And again, tons and tons of repetition here.

144

This skill could be a lot shorter.

145

So what we have is a large block of text that basically says be more ambitious.

146

Here are some specific things that you can focus on in your review.

147

Really go nuts here and propose a ton of structural changes.

148

Make sure that you prioritize your findings in a certain order so you don't flood it with useless crap.

149

And then approve or reject based on these conditions.

150

What I don't like here is there's no mention of testing.

151

There's no mention of scenes.

152

There's no mention of any kind of improving the feedback loops to make future runs better,

153

which in my view is the entire point now of having a good code base

154

or having a code base that's easy to change and modular and easy to navigate.

155

All of this appears to be focused on actual source code, none of it on tests.

156

Interesting.

157

But okay, let's read what it said here.

158

So it's taken the last five PRs to main and it has found some blocker class structural issues.

159

Okay, it's found that an init service is now a big file, so it's over 1,000 lines and it mixes a bunch of stuff here

160

and it should have been preceded by a split and it's proposed a nice split there.

161

Oh, it's also trying to create an abstraction here,

162

a little make registry generic function returning this would delete 20 lines of duplicated boilerplate at the same time.

163

Feels good.

164

That's nice.

165

So we now go to the next one, the feature specific if issue tracker name custom scattered across three layers.

166

Interesting.

167

It's basically saying that instead of this being a special case if statement here, we should instead do a bit of code judo

168

and push the custom tracker variations into a type itself and then it can be read later.

169

I think in terms of suggestions here, I happen to know this code quite well.

170

I think we are at two out of two here.

171

That seems like two really good suggestions.

172

Down here we have an inconsistent contract.

173

Template args carries both shell commands and prose markers.

174

It's basically saying that some of these are runnable but some of these are not runnable here.

175

And it's saying that maybe we should widen the type to either a command

176

or a to-do marker discriminated union or use a different field entirely for unfilled markers.

177

So basically, it's basically trying to strengthen the type boundary here

178

so that we don't later pass in a prose marker into something else.

179

That's interesting.

180

I think that this comes from an inaccurate understanding of the whole system, which is okay.

181

You're going to get some false positives, I suppose, to the false positive in any review prompt.

182

So this is the kind of thing, if it came up in a PR, I would say, this is fine.

183

Don't worry about it.

184

So two out of three, not bad.

185

Let's look at the strong code quality issues.

186

Aha, we do have a weird bug here that it's, well not a bug, just a weird bit of code design.

187

We essentially have different templates in Sandcastle that each declare the dependencies that they need.

188

And mostly they declare Zod as their dependency.

189

So we have this weird code path in here that looks like it just hardcodes Zod.

190

And then, interesting.

191

Yeah, overall this is quite hard to explain, but it's definitely pulled up something weird here.

192

So I think we're at three out of four, which is good.

193

Oh, it's found some swallowed errors here.

194

Exact sync inside effect.sync with swallowed errors.

195

Interesting.

196

We can see it's trying something inside here.

197

And if it fails, then it just like returns false inside here.

198

So yeah, this is definitely another thing that I would like the reviewer to look at.

199

Looks like we started decomposing a large file into small files, but only half finished.

200

So this again is a good one.

201

This is five out of six so far.

202

And it's now saying there is a bit of prompt duplication within some prompts that were changed here.

203

So the change is byte identical for two different prompts here.

204

It's saying that we should refactor those into an issue list preamble.

205

I don't think that's right.

206

I think that prompts should just be independently changeable.

207

So not bad though.

208

Five out of seven.

209

Then it's got a list of smaller items worth fixing here.

210

I've done a quick scan and I would say most of those look pretty good and interesting.

211

I'm kind of intrigued by the approval bar here.

212

Under the skills stated bar, a couple of the PRs should not have landed in their current shape.

213

The behaviour is correct in all three substantive PRs, but the code base is meaningfully messier than it was a week ago.

214

Well, cool.

215

I mean, we got some really good feedback from this skill, I think.

216

I think what this is teaching me is

217

that actually getting the review to be super ambitious and getting it to push a lot of different options

218

will give you more false positives, but those false positives are pretty easy just to say no to, right?

219

It's the ones that you miss that you never know about, the opportunities for improvement that you never see, those are the dangerous ones.

220

Overall, I will clean up this skill so it's not quite so duplicative, so there's a bit more dry.

221

And I would also just get it to focus a lot more on tests as well.

222

Think about the seams in your codebase, kind of like what my improved codebase architecture does.

223

But overall, I think this is worth pulling down, experimenting with, and just seeing what comes out of it.

224

Now, if you dig this stuff, then I'm running a cohort starting next week, starting June 1st, on AI coding for real engineers.

225

This has been my most subscribed to course ever.

226

People are going nuts for this.

227

We're going to have, I think, around 4,000, 4,500 people in there.

228

So yeah, it's absolutely wild.

229

But if you're enjoying this stuff, if there's a skill that you want me to review, I really like making that content because it lets me steal ideas from other people's great skills, then let me know.

230

Nice work, and I'll see you very soon.

앱 다운로드

유창하게 말하는 데 필요한 모든 것

AI 발음 평가문장마다 점수 확인

IPA 발음 연습모든 소리 마스터

단어 학습나만의 단어장 만들기

단어 게임놀면서 외우기

QR 스캔

Download on theApp Store Get it onGoogle Play

같은 채널

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

Business EnglishUniversity StudentsWorking Adults

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

Business EnglishUniversity StudentsWorking Adults

Most devs don't understand what agents are

Daily ConversationUniversity StudentsWorking Adults

Most devs don't understand how LLM tokens work

Business EnglishUniversity StudentsWorking Adults

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

Business EnglishUniversity StudentsWorking Adults

FOR YOU

왜 이 영상을 통해 말하기 연습을 해야 할까요?

이 영상은 코드 리뷰라는 주제를 다루고 있지만, 그 안에 포함된 다양한 표현들은 영어 회화 연습에 매우 유용합니다. 특히 기술 관련 대화나 비즈니스 환경에서는 코드 품질, 리뷰 과정 등에 대한 이야기가 자주 오갑니다. 이 영상에서 말하는 방식과 언어는 실제 상황에서 자주 만나게 되는 표현들이므로, shadow speech 기법을 활용해 반복 연습하면 자연스러운 대화를 할 수 있는 기초가 다질 수 있습니다. 또한, 영상 속 질문이나 요청 방식은 의사소통 능력을 키울 수 있는 좋은 예시입니다.

문맥 속 문법과 표현

영상에서 사용된 몇 가지 주요 문법 구조와 표현을 살펴보겠습니다:

“Perform a deep code quality audit”: 이 표현은 '철저한 코드 품질 감사’를 의미하며, 전문적인 상황에서 자주 쓰입니다. 의사소통 시, ‘perform’ 대신 ‘carry out’와 같은 대체 표현도 좋습니다.
“Work to improve abstractions”: ‘추상화 개선을 위해 노력하다’라는 의미로, 문제 해결을 위한 사고방식이 잘 드러납니다. 이러한 구조는 비즈니스 영어에서 유용하게 쓰일 수 있습니다.
“Be ambitious”: '야망을 가지라'라는 설명은 개인의 자세를 강조합니다. 목표를 설정하고 이를 위해 풀어야 할 문제를 정의하는 데 도움이 됩니다.
“Treat that as a design problem”: 이 표현은 특정 문제를 디자인 문제로 보고 해결하라는 지침입니다. 사고의 유연성을 기를 수 있는 좋은 예입니다.

일반적인 발음 함정

이 영상을 통해 듣게 되는 몇 가지 발음과 억양의 함정도 주의해야 합니다:

“Thermonuclear”: 매우 긴 단어로, 발음이 어려울 수 있습니다. 이 단어를 분리하여 'thermo-nuclear'로 연습하는 것이 효과적입니다.
“Ambitious”: 이 단어는 '앰비셔스'로 발음되는데, 한국어 화자에게는 느리게 발음하려는 경향이 있습니다. shadow speak 연습을 통해 자연스럽게 발음해보세요.
“Spaghetti” : 단어의 억양이 매우 중요합니다. ‘스파게티’라고 단순히 읽지 말고, 각 음절에 주의를 기울여 연습해보세요.

영어 발음 교정은 자주 반복하는 것이 중요합니다. 이런 발음 함정을 집중적으로 연습하면, 더 자연스럽고 유창한 영어 구사가 가능해집니다.

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
조건문 if + 절, will/would + 동사 — 조건과 그 결과	if this was my skill, I would definitely
현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때	I've known · I've often found · I've actually reached
수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점	is currently marked · been solved · is serialized
관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보	repo, which is · code, which is · system, which is

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: Can Cursor's HARDCORE Review Skill Stop The Slop? - 영상으로 영어 말하기 배우기

연습 모드 선택

앱 다운로드

같은 채널

New Skills! v1.3 brings /pr, /implement-spec, and /retro

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

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

Learn anything with the /teach skill

5 Claude Code skills I use every single day

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

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

Most devs don't understand what agents are

Most devs don't understand how LLM tokens work

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

추천 영상

What is clean code? - Uncle Bob

Starship - Test Like You Fly

Can I remake those SH*TTY mobile games in 1 HOUR? ...again

Meta’s Llama 4 is mindblowing… but did it cheat?

How to Rewire Your Brain to Enjoy Discipline (Dopamine Detox Explained)

MCP Just Got a Whole Lot Better

SAC | Soft Actor Critic (SAC) architecture | SAC Explained

I've Changed My Opinion On DEVELOPERS Vibe Coding

Introducing Automations: always-on coding agents

Heuristic Evaluations: How to Plan, Conduct, and Report Results | Course Preview

왜 이 영상을 통해 말하기 연습을 해야 할까요?

문맥 속 문법과 표현

일반적인 발음 함정

이 영상의 문법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법