Skills, Subagents and Tools
The primitives an agent actually gives you, what each one costs in context, and how to wire them into real work.
- Buy once, yours for good
- 28 lessons across 5 sections
- Progress tracking across devices
What you'll learn
- Tell a tool, a skill and a subagent apart, and pick the right one on purpose
- Work out what each primitive costs you in context before you add it
- Write a SKILL.md that fires when it should and stays quiet when it shouldn't
- Debug a skill that never triggers, which is almost always one specific mistake
- Brief a subagent so it doesn't hand back work you have to redo
- Build a verification agent that catches what the writer missed
- Recognise tautological tests, and the ordering that prevents them
- Know when none of this is worth it, from measurements rather than vibes
Course content
5 sections · 28 lessons
Four primitives, and what each costsThe one table that decides everything else, and the arithmetic behind it.7 lessons
- What this course assumesFree preview2m
Read this lesson
You have an agent. You have asked it to do something, watched it do a mediocre job, and wondered whether the problem was you.
Usually it was — but not in the way people assume. The failure is rarely a badly worded request. It is that the agent was carrying twelve tools it didn't need, no idea of your project's conventions, and forty turns of unrelated history, and then you asked it to be careful.
What you get here:
- A way to decide, in about ten seconds, whether a new capability should be a tool, a skill, or a subagent
- The file formats for each, with worked examples you can paste into a repository today
- The specific mistakes that make each one fail, and how to spot them from the symptom
- Honest limits: several measured cases where all of this makes things worse
What you don't get: a claim that any of it is transformative. There is a measurement at the end of the course that should make you cautious, and it is in here on purpose.
- Context is the budgetFree preview5m
Read this lesson
Every model has a context window, and every capability you add spends some of it before your actual question arrives.
This is the fact the rest of the course hangs on: an agent does not get better as you give it more. Past a point it gets measurably worse. The failure mode is not an error — the model does not refuse or crash. It just quietly starts missing things: forgetting a constraint you stated, using a tool it was told to avoid, summarising instead of reading.
Think of the window as a budget with three claims on it:
Claim Paid Typical size System prompt and instructions Every turn Small, and yours to control Tool schemas Every turn, for every declared tool The one that gets away from you Conversation history Grows with the session Bounded by compaction, eventually The middle row is where most people bleed. A tool's schema — name, description, every parameter, every type, every enum value — is re-sent on every single turn it is available, whether or not the model uses it. One tool is nothing. A well-meaning MCP server exposing forty of them is not nothing.
Practitioner measurements put a large tool set at 50,000 tokens or more of standing overhead, against roughly 100 tokens for a skill's metadata — about 96% less for equivalent reach.
That ratio is the reason the rest of this course exists. It is not an optimisation. At those sizes it is the difference between an agent that holds your requirements in mind and one that has spent its attention reading a catalogue.
- Tools: the schema tax5m
- Skills: a hundred tokens and a promise5m
- Subagents: a window you don't pay for5m
- The decision table4m
- Practice: which primitive?12m
Writing skills that actually fireThe format is trivial. Making one trigger reliably is not, and it comes down to one field.7 lessons
- Anatomy of a SKILL.md6m
- The description is the trigger6m
- A real skill, start to finish8m
- Bundling scripts and references5m
- Project skills: house rules every agent inherits5m
- Why your skill didn't fire6m
- Practice: fix the description12m
Subagents that earn their keepDelegation is easy to do and easy to do badly. The difference is almost entirely in the brief.6 lessons
- Defining a role6m
- Minimal tool sets5m
- The briefing problem6m
- Fan-out, and the serial trap6m
- Reading the result back5m
- Practice: spot the bad delegation12m
Putting them to workFive jobs worth delegating, and the specific trap in each.6 lessons
- The verification agent6m
- The adversary: three different jobs7m
- Docs from the diff6m
- Tests, and the tautological trap7m
- When none of this is worth it5m
- Practice: design the team12m
Where this meets the APIThe same three shapes exist a layer down, for when you are building rather than configuring.2 lessons
- The same ideas, one layer down5m
- Further reading
Requirements
- You already use a coding agent — Claude Code, Cursor, Copilot, or similar
- Comfortable in a terminal and a git repository
- No experience writing skills or configuring subagents needed
Description
Your agent has three ways to learn something new: you can give it a tool, give it a skill, or hand the job to a subagent. Most people reach for whichever one they read about most recently, and end up with a bloated context, a skill that never fires, and a subagent that hands back work they have to redo anyway.
The three are not interchangeable, and the difference is not stylistic. It is measured in tokens, and it decides whether your agent gets better or worse as you add to it.
This course is about picking correctly and then doing it properly. Every section is built on files you can copy — real SKILL.md bodies, real subagent definitions, real before-and-after prompts — because the gap between "I understand skills" and "my skill fires reliably" is entirely in the details.
It is written for someone who already uses a coding agent daily and wants to stop fighting it. There is no API code here: everything is configuration and prose you put in your repository. The last section points at the API equivalents for when you want to build the same shapes yourself.