Shadowing Practice: 5 Claude Code skills I use every single day - Learn English Speaking with Video
Les maken...
1
I've been an engineer for nearly a decade and in all of that time, right now, process has never been more important.
2
At your fingertips now, you have access to a fleet of middling to good engineers that you can deploy at any time.
3
But the weird thing about these engineers is they have no memory, they do not remember things they've done before,
4
and so you need extremely strict and well-defined processes to get those agents to actually do things that are useful.
5
So this means that you as a developer are looking constantly for ways to steer your agents, to keep them on the right track.
6
And for me that has resulted in a lot of skill building.
7
Here is the repo of all the skills that I'm using right now, each of which I have gone through and designed.
8
Some of these I use relatively rarely, but some of them I use every single day.
9
And these skills help me encode my process so
10
that AI has a really strict path it can walk down every single time.
11
And as a result of using all of these skills, the code quality that the AI is producing has shot up.
12
Now if you think that process is important and
13
that real engineering skills are important then boy do I have a course for you.
14
This course is called Claude Code for Real Engineers.
15
It's a two week cohort that starts on March 30th and for seven more days it is 40% off.
16
If you feel like you're behind the curve on Claude Code
17
and you want to get way ahead of the curve in just two weeks then blimey this is the place for you.
18
But let's start talking about our skills with number one which is maybe my favourite.
19
This This is the grill me skill.
20
This skill, yes, it is just three sentences long.
21
And let's just read it out in full to describe what it does.
22
Interview me relentlessly about every aspect of this plan until we reach a shared understanding.
23
Walk down each branch of the design tree, resolving dependencies between decisions one by one.
24
And finally, if a question can be answered by exploring the codebase, explore the codebase instead.
25
The concept of a design tree comes from this book by Frederick P.
26
Brooks, which is the design of design.
27
Actually, I don't know if it comes from this book, but this book is where I saw it first.
28
The design tree is this idea
29
that as you're coming towards a design you need to walk down all of the branches of a design tree.
30
For instance, you might be designing a search page
31
and you need to decide whether you want an advanced search or a text box.
32
If you choose advanced search then you need to figure out all of the filters
33
and all of the sorting methods that you need on advanced search.
34
And you keep on walking down the tree until you figure out your design kind of in full
35
or as full as you can before actually committing to code.
36
This grill me skill, when I invoke it, I invoke it when I want to reach a shared understanding with the LLM.
37
I found that relatively recently Claude Code will tend to just spit out a plan really early
38
when I go in plan mode, and it tends to just create a document before I feel I've reached a shared understanding with the LLM.
39
But the grill me skill forces that conversation, it forces the LLM to interview me about every single part.
40
Here's a conversation I had with Claude recently about adding a feature to my course video editor codebase.
41
I gave it some research that I'd done in a markdown file and I said grill me, I'd like to think about adding this to the right page.
42
It loaded up the skill and the thing I want to show you is just how many questions it asked me.
43
So the first thing it did is it just explored the relevant stuff in the codebase, which is good.
44
And we zoom down, we can see it asks question 1, where does the document live?
45
Question 2, what's the UI layout?
46
Question 3, which modes get the document panel?
47
Question 4, the document lifecycle?
48
Question 5, what does the write document tool look like?
49
Question 6, the edit tool shape?
50
7, question all the way down to question 9, question 10, question 11, question 12, all the way down to question freaking 16 here.
51
And this is a relatively short grilling session in my book.
52
I've had sessions where I've sat there for nearly half an hour, 45 minutes with the AI answering questions on really complex features.
53
You know, that could be 30, 40, 50 questions, all from this absolutely tiny skill.
54
That's one thing I want you to take from this.
55
Skills don't have to be long to be impactful.
56
You've just got to choose the right words for the LLM at the right time
57
and this design tree resolving dependencies has just been absolutely great for me.
58
By the way, if you want these skills then they will be at a link below.
59
Once I have reached a shared understanding with the LLM, once I have grilled my idea and sort of understood all of its ramifications,
60
if I then decide I want to implement it then I invoke my next skill which is a write a PRD skill.
61
I actually did this in the conversation we were just looking at.
62
So it said anything I've missed or got wrong and I said write a PRD.
63
I was suffixing it with user because I have some
64
that sort of live in the project so that's the reason why I did that.
65
Here's what the skill looks like.
66
This will be invoked when the user wants to create a PRD.
67
You may skip steps if you don't consider them necessary.
68
So for instance in the previous conversation it said we've already done a deep interview let's move to step four.
69
So step one is to ask the user for a long detailed description.
70
Number two is to explore the repo to verify their assertions.
71
Number three is basically to interview the user relentlessly.
72
So just a copy of the grill me skill again.
73
Next we sketch out the major modules you will need to build or modify to complete the implementation.
74
We're going to look at this later
75
because it links to skills I'm going to show you in a bit in this video.
76
And finally once you have a complete understanding of the problem and the solution, use the template below to write the PRD and the PRD should be submitted as a GitHub issue.
77
The way that my dev flow works is I take these PRDs in GitHub.
78
I turn them into more GitHub issues that reference the parent PRD.
79
And then I have a Ralph loop that just loops over each issue until it's done.
80
If we go back to the conversation where we were before, we can see that it created this PRD here.
81
This was four days ago, as you can see.
82
We've got a problem statement.
83
The article writing page currently regenerates the entire document on every AI interaction.
84
And the solution was to add a split pane document editing experience to the article writer.
85
Chat stays on the left, a new document plan, blah, blah, blah.
86
So this is a big feature.
87
We're adding document editing to a kind of AI chat feature.
88
The important thing here is the user stories.
89
There are many, many user stories as part of this.
90
And this comes from Agile methodology.
91
And we're basically trying to describe the kind of desired behavior of our system in language, which is not an easy thing to do.
92
I still haven't properly like landed on the right format for these.
93
This is just something I sort of like.
94
But you could easily use like Cucumber Language for these or whatever you're kind of used to do, used to working with.
95
We then zoom down to the bottom and we just sort of pass in some implementation decisions.
96
The implementation decisions here, we don't want to be like over prescriptive because we want these to be durable.
97
Because if the code ends up getting out of date with the PRD, then we're going to have issues when we actually go to implement it.
98
But you can see the theory here.
99
This is the kind of, it's a really good description of the destination that we're going to.
100
But what we don't have from the PRD is the actual journey, is the way we're going to get to this destination.
101
And if we leap back to that conversation, this is where I use my next one, which is PRD to issues.
102
What this does is it takes a PRD, takes the destination, and it turns it into a Kanban board of different issues that can be independently grabbed.
103
So the first step in here is it locates the PRD.
104
If the PRD is not already in your context window, fetch it with this instruction.
105
Explore the code base if you need to.
106
And then, oh, oh, oh, oh, draft vertical slices.
107
It's not always clear how you should break a PRD down into individual tasks.
108
This is something that developers have been doing for Yonks, right?
109
And we've developed a kind of intuition for how to do it.
110
In my opinion, the best way to do it is to break it into tasks
111
that flush out the unknown unknowns really quickly.
112
For instance, if you're integrating with a new kind of service or integrating two things which you haven't integrated before,
113
then you should do that work first because it's going to give you feedback on whether your approach is even valid.
114
The right analogy here is the tracer bullet analogy.
115
I won't go into what that means but basically each issue is a thin vertical slice that cuts through all integration layers, not a horizontal slice of one layer.
116
In the conversation it broke down that really complicated PRD into just four slices.
117
It first created a kind of engine with some tests applied to it.
118
This is actually quite a good vertical slice because this was the engine
119
that was going to then power the rest of the setup.
120
If this engine wasn't working for whatever reason or it wasn't feasible then we would need to flush that out quickly.
121
And this is what this breakdown does.
122
The PRD2 issues also establishes blocking relationships between the tasks.
123
For instance, number 2 here is not actually blocked by anything, so it can be picked up independently to 1.
124
This is really useful if you have a parallel agent setup where you can actually fire two agents at it at once, for instance in background tasks.
125
And it also means that in the future you can add other issues to this, like QA issues that you find or things that need to be improved,
126
and you can then establish blocking relationships between that and all the other things.
127
We can see that number three here is blocked by 1, the editing engine, and the number 4, the Monaco editor toggle, is blocked by number 2.
128
So I said yes to all of these and it created then all of these GitHub issues.
129
These issues reference the parent PRD so that the local agent can fetch it and view it.
130
And it sort of just breaks down what to build really.
131
And crucially, it references the previous user stories in the PRD.
132
We can then see a comment actually from ClaudeCode that ended up implementing this.
133
It's a pure function document editing engine with 28 tests covering all acceptance criteria.
134
And we can then take a look at the commit that references this issue.
135
So this was basically my Ralph loop came and just implemented this based on the issue, commented on it, closed it, and then the next issue was unblocked.
136
So so far the grill me skill can help you flesh out an idea, the writer PRD skill can help you take that idea and turn it into a document,
137
and then the PRD to issue skill helps you then turn that destination document into an actual journey.
138
But then how do you actually execute on that skill?
139
How do you make it like, how do you make the implementation really rock solid and increase the code quality of what gets produced?
140
We have got a TDD skill.
141
TDD means Test Driven Development.
142
And when you invoke this skill, it basically forces the agent, or encourages the agent rather, to follow a red-green refactor loop.
143
Unusually for my skills, there is actually a lot in here.
144
So it's not just the skill itself, it's also ideas on refactoring, on mocking, on what deep modules are.
145
Doing really, really good TDD has been the most consistent way that I've improved agents' outputs.
146
So let's have a look at what's actually in here.
147
What we can see is, I'll just skip over the philosophy stuff, I'll let you guys read that.
148
We are basically looking at this workflow.
149
Now the first one here is really important.
150
Confirm with the user what interface changes are needed.
151
Now I made a video on interfaces and implementations recently, but let me just give you the pricing.
152
When an AI looks at a bad codebase it will look at
153
or it will see something like this where it has a ton of tiny modules here that are kind of undifferentiated.
154
They're not really grouped together, it doesn't really understand how these things relate.
155
And so it has to do a lot of work kind of working out, okay what's responsible for what, what are the dependencies, how does this actually, how does the codebase even function.
156
Whereas if you restructure this into several larger modules with just kind of thin interfaces on top,
157
the interface being the functions that are actually exported from this, the things that the callers actually call, then it's a lot easier for AI to navigate this codebase
158
and it's a lot easier to work out how to test these modules.
159
Because you just test them at their interfaces, you test them at their boundaries.
160
You can check out the whole video on that below.
161
So what this TDD skill is encouraging here is basically trying
162
to make these interface changes really top of mind for the AI.
163
To get it to understand that when it changes an interface that's an important decision it needs to take time over.
164
You confirm with the user which behaviours to test.
165
You design the interfaces for testability, linking to a dock.
166
And then we have some more stuff around planning here.
167
It then goes into a lovely loop where it writes one test at a time.
168
And it writes the test first.
169
Now I've talked about red green refactor before so I'll link the video below if you're interested.
170
But I've found that red green refactor with agents is incredible.
171
And it basically does this loop until it's complete.
172
It just writes a the failing test, then writes the code to make that test pass.
173
And finally it goes through and looks for refactor candidates.
174
I haven't found that this is amazing, it hasn't been brilliant, because often LLMs are quite reluctant to refactor their own code.
175
If you were to clear the context of the LLM then it would wipe its own memory
176
and it would be a lot less precious about the code that it's just written.
177
But while its own code is sitting in its own context window, it's quite reluctant to change it.
178
is what I prompt my RALF loops with in order to get them to do red-green refactor.
179
Now, TDD demands a lot of you, or rather it demands a lot of your codebase.
180
TDD is really hard to do in a badly structured codebase, because the test boundaries of this are really unclear.
181
Should it just sort of test these modules on their own?
182
Should it test these modules on their own?
183
What are the boundaries here?
184
Whereas when your codebase looks more like this, then it's a lot easier to test because the module boundaries are really clear.
185
So wouldn't it be great if there was a skill that made your codebase look more like this?
186
Well isn't it nice?
187
We've got an improved codebase architecture skill.
188
The process for this one is that we explore the codebase and explore it naturally as an agent would.
189
We're trying to find confusions.
190
We're not like… we're trying to surface naturally what the AI finds confusing so that it can then help it out later.
191
Where does understanding one concept require bouncing around between many small files?
192
Where have pure functions been extracted just for testability but the real bugs hide in how they're called?
193
Where do tightly coupled modules create integration risk in the seams between them?
194
All of these are questions that a senior engineer would be asking about your codebase.
195
Number two is you present candidates, so you present a numbered list of deepening opportunities.
196
In other words, opportunities to deepen shallow modules in your codebase into deeper ones.
197
The user then picks a candidate and then you design multiple interfaces, so it says to spawn three sub-agents in parallel,
198
each of which must produce a radically different interface for the Deepen module.
199
In other words, we're extracting that code and designing possible ways that it could look in the future.
200
Designing it in multiple different ways is a really great way that you can then decide on the right idea.
201
I've seen this agent spawn like five different sub-agents for a really big refactor.
202
The coolest thing about this is you don't need to know a lot about interface design in order to get this working.
203
After comparing, give them your recommendation which design you think is strongest and why.
204
And if elements from different designs would combine well, then propose a hybrid.
205
Notice that I've made this really language agnostic, really kind of sort of everything agnostic, really.
206
You can just run this in any code base and just get a decent answer for how it could be improved.
207
There might be four or five candidates that really could use some work, but really I think you should only be sort of doing one of these at a time because
208
They really are quite hard to get your head around
209
and they require a human in the loop to sit with them
210
and improve the code base because these decisions do require taste.
211
Finally it creates a GitHub issue.
212
So it creates a refactor RFC as a GitHub issue using ghissue create.
213
Usually once this is done I will then go with my prd2issues skill, reference that GitHub issue that's just been created and get it to, you know, this describes the destination.
214
We then need a journey to get there.
215
So just doing this every so often in a codebase, once a week, just to identify opportunities.
216
Or if you have a sudden surge of development and you create a whole extra wing of features,
217
then this skill will be really useful in just making sure it conforms to the rest of the codebase, making sure that it's not too sloppy.
218
And as you keep running this, as you keep refining your codebase, you're going to notice the quality of the agent's output goes up.
219
Because the old adage really does apply.
220
If you have a garbage codebase then the AI is going to produce garbage within that codebase.
221
Because to be honest if you took all of these skills
222
and just said okay this is like a little mini markdown
223
book of processes for humans then it wouldn't look out of place.
224
I've found that the most successful way to get code quality up from agents is just to treat them like humans.
225
Humans with weird constraints, sure, humans that have no memory and are just sort of cloned come out of the birthing pod and go right to work.
226
But if you, like me, think these real engineering skills are super important, then this course is absolutely for you.
227
What I noticed while I was creating the course is that I'm really not teaching clawed code that much.
228
I'm teaching kind of what our sub-agents, I'm talking about the constraints of LLMs, the sort of weird smart zone, dumb zone stuff with the context window.
229
We're talking about steering, which is essentially just a way of documenting stuff inside your codebase.
230
How to tackle massive tasks, understanding tracer bullets and building those into our skills.
231
Understanding how to build really great feedback loops and doing exercises with them, and crucially how to hook these up to an autonomous agent.
232
Every part of this course just sort of like leads onto the other and I'm super happy with how it turned out.
233
So over the course of two weeks you'll be working through
234
that self-paced material with me as your guide in Discord and on live office hours.
235
And if that sounds fun to you then the link is below.
236
Thanks for watching folks, I'll be coming back with a lot more stuff this week.
237
What would you you like me to cover next?
238
I find the intersection between this real engineering and AI is such an awesome place to make content about.
239
But anyway, thanks for watching and I'll see you in the next one.
📺 Zelfde Kanaal
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.3 brings /pr, /implement-spec, and /retro
Business EnglishWorking 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
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
✨ Aanbevolen Video
C11
126 zinnen
How I use AI as a senior software engineer and 5 principles of AI explained in 10 minutes
Business EnglishUniversity StudentsWorking Adults
B21
202 zinnen
How to Learn Anything FASTER
British AccentBusiness EnglishUniversity StudentsWorking Adults
C12
182 zinnen
We Let $200 GPT-Pro Think for 7 Days on Unsolved Math
Business EnglishUniversity StudentsWorking Adults
B22
261 zinnen
Your Life as Every Industrial Engineer Rank
Business EnglishUniversity StudentsWorking Adults
C11
96 zinnen
The hottest programming skill in 2026
Business EnglishUniversity StudentsWorking Adults
C12
213 zinnen
The Technical, Business and UX Skills Every Product Manager Needs
Business EnglishUniversity StudentsWorking Adults
C11
309 zinnen
Claude Code: The Advanced Guide (99% of Devs Skip These Features)
Business EnglishUniversity StudentsWorking Adults
C12
540 zinnen
Incremental Cooking in UE 5.7: A Dive Into the UE Cook Pipeline | Unreal Fest Chicago 2026
Business EnglishUniversity StudentsWorking Adults
B21
196 zinnen
I cloned 3 apps and now make $35K/month
Business EnglishInterview EnglishUniversity Students
C13
443 zinnen
Complete Roadmap for Backend Software Engineers (START HERE!)
Business EnglishUniversity StudentsWorking Adults
Woordenschat en spreektips bij deze les
Deze spreekles op niveau C1 is gebaseerd op de video “5 Claude Code skills I use every single day”. Deze woorden komen het vaakst terug: skill, prd, codebase, issue, code. Deze video bevat 239 zinnen en 3622 woorden om na te spreken. Het gesproken deel duurt 16:41. De spreker praat snel, ongeveer 217 woorden per minuut, dus reken op verbonden en ingeslikte klanken. 82% van de woorden hoort bij de 3.000 meest gebruikte Engelse woorden; de rest kun je beter vooraf bekijken.
Belangrijke woorden in deze video
De 15 moeilijkste woorden uit de video, met uitspraak en betekenis:
| Woord | Uitspraak | Betekenis |
|---|---|---|
| module zelfstandig naamwoord | /ˈmɑd͡ʒul/ | module |
| grill zelfstandig naamwoord | /ɡɹɪl/ | raster, rooster |
| slice zelfstandig naamwoord | /slaɪs/ | plak, schijf |
| invoke werkwoord | /ɪnˈvoʊk/ | aanroepen |
| deepen werkwoord | /ˈdiːpən/ | verdiepen |
| dependency zelfstandig naamwoord | /dɪˈpɛndənsi/ | afhankelijkheid |
| agnostic zelfstandig naamwoord | /aɡˈnɒstɪk/ | agnosticus |
| constraint zelfstandig naamwoord | /kənˈstɹeɪnt/ | beperking, inperking |
| spawn werkwoord | /spɔn/ | kuitschieten, paaien |
| tracer zelfstandig naamwoord | /ˈtɹeɪsɚ/ | tracer, lichtspoormunitie |
| fetch werkwoord | /fɛt͡ʃ/ | halen |
| analogy zelfstandig naamwoord | /əˈnæləd͡ʒi/ | analogie |
| steer werkwoord | /stɪɹ/ | besturen |
| flush werkwoord | /ˈflʌʃ/ | spoelen |
| reluctant bijvoeglijk naamwoord | /ɹɪˈlʌktənt/ | aarzelend, schoorvoetend |
Phrasal verbs die je zult horen
| Woord | Uitspraak | Betekenis |
|---|---|---|
| break down werkwoord | stukgaan, kapot gaan | |
| end up werkwoord | belanden, terechtkomen | |
| figure out werkwoord | uitvogelen, er achter komen | |
| work out werkwoord | /ˌwɝk ˈaʊt/ | uitrekenen |
| check out werkwoord | onderzoeken | |
| pick up werkwoord | oppakken, optillen | |
| turn out werkwoord | uitvallen, resulteren |
Zinnen om te herhalen
Korte, volledige zinnen uit de video die je in alledaagse gesprekken kunt gebruiken:
- We've got a problem statement.
- We've got an improved codebase architecture skill.
- We're trying to find confusions.
- What would you you like me to cover next?
Grammatica in deze video
De structuren die de spreker het meest gebruikt, met de exacte woorden uit de video:
| Structuur | In de video |
|---|---|
| Voorwaardelijke zinnen if + zin, will/would + werkwoord — een voorwaarde en het gevolg | if elements from different designs would combine |
| Present perfect have/has + voltooid deelwoord — iets uit het verleden dat nu nog telt | I've been · they've done · has resulted |
| Lijdende vorm be + voltooid deelwoord — het gaat om wat er gebeurt, niet om wie het doet | is called · can be answered · will be invoked |
| Betrekkelijke bijzinnen who / which + zin — extra informatie over een persoon of ding | one which is · Brooks, which is · codebase, which is |
Uitspraak om op te letten
De spreker gebruikt 67 samentrekkingen en verkorte vormen, zoals I've, we're, don't. Spreek ze kort uit, zoals je ze hoort.
- De klanken “sh” en “zh”: crucially /ˈkɹuːʃəli/, flush /ˈflʌʃ/, intuition /ˌɪn.tjuːˈɪʃ.ən/, assertion /əˈsɜɹʃən/, unusually /ʌnˈjuːʒuəli/
- Lange woorden — let op de klemtoon: dependency /dɪˈpɛndənsi/, relentlessly /ɹɪˈlɛntləsli/, analogy /əˈnæləd͡ʒi/, independently /ˌɪndɪˈpɛndəntli/, criterion /kɹaɪˈtɪɹ.i.ən/
Klanken die Nederlandstaligen lastig vinden:
- Stemhebbende eindmedeklinker — /b/, /d/, /g/, /z/, /v/ niet verscherpen: encode /ɪnˈkoʊd/, confuse /kənˈfjuːz/, surge /sɝd͡ʒ/, propose /pɹəˈpəʊz/
- /æ/ — opener dan de Nederlandse “e”: analogy /əˈnæləd͡ʒi/, extract /ˈɛkstɹækt/, radically /ˈɹædɪkli/, navigate /ˈnæv.ɪ.ɡeɪt/, shallow /ˈʃæloʊ/
- /g/ — een harde plofklank, geen Nederlandse “g”: grill /ɡɹɪl/, integrate /ˈɪn.tɪ.ɡɹeɪt/, agnostic /aɡˈnɒstɪk/, fingertip /ˈfɪŋɡɚˌtɪp/, navigate /ˈnæv.ɪ.ɡeɪt/
Zo oefen je met deze video
- Luister de hele video één keer zonder te spreken en noteer de woorden die je niet kent.
- Begin op 0,75× snelheid, spreek zin voor zin na en ga terug naar normale snelheid zodra het makkelijk gaat.
- Neem jezelf op en vergelijk met het origineel; let daarbij op woorden als module, grill, slice.
Wat is de Shadowing-techniek?
Shadowing is een wetenschappelijk onderbouwde taalleermethode die oorspronkelijk is ontwikkeld voor professionele tolkentraining en gepopulariseerd door polyglot Dr. Alexander Arguelles. De methode is eenvoudig maar krachtig: je luistert naar native Engelse audio en herhaalt het onmiddellijk hardop — als een schaduw die de spreker volgt met slechts 1–2 seconden vertraging. In tegenstelling tot passief luisteren of grammaticadrills, dwingt shadowing je hersenen en mondspieren om echte spraakpatronen tegelijkertijd te verwerken en te reproduceren. Onderzoek toont aan dat het de uitspraaknauwkeurigheid, intonatie, ritme, verbonden spraak, luisterbegrip en spreekvaardigheid aanzienlijk verbetert — waardoor het een van de meest effectieve methoden is voor IELTS Speaking-voorbereiding en echte Engelse communicatie.