Day 4 gave the agent what it always needs to know; today is the home for what it only sometimes needs to do.
The most useful piece of AI work I have shipped is not a test I wrote. It is a skill that writes test plans, and the whole team uses it. You point it at a feature, a ticket, or a spec and say “write me a test plan”. It reads the ticket, climbs up to the parent epic when the ticket is a thin stub, weighs risk area by area, and hands back a structured plan with every case written as a Verify that row, published where the team actually works. I built it over five rounds, and now anyone on the team can plan testing the same way without me in the room. The payoff is not really speed. It is that the whole team plans the same way instead of each person inventing their own format.
The signal that you have a skill to build
You have a procedure you run every time: how you turn a spec into a plan, how you write a bug report, how you decide what to automate. And every time you open a chat, you type it out again, or dig through old conversations for the version where you finally got the wording right. That re-pasting is the signal. The split between yesterday’s file and today’s folder is one sentence:
A fact every session needs goes in your rules file. A procedure you invoke goes in a skill.
If a section of your rules file has quietly grown from a fact into a numbered procedure, that section wants to be a skill.
A skill is a folder, not a framework
.claude/skills/qa-test-plan/
├── SKILL.md required: frontmatter + instructions
├── reference/ optional: long detail, loaded on demand
└── examples/ optional: real worked outputs
The SKILL.md is the whole brain: YAML frontmatter at the top, markdown instructions below. No build step, no install command. If you can write markdown, you can write a skill. Commit the folder to the repo and the whole team gets it. Two fields earn special attention:
- The description is the whole game. It is the only part of the skill loaded all the time, and it is how the agent decides whether your skill is relevant at all. Write it in third person, state both what the skill does and when to use it, and put in the real phrases your team actually says: “create a test plan”, “what should we test for this”. The best instructions in the world do nothing if the skill never loads.
- allowed-tools is the guardrail. My plan skill reads the codebase and the spec and publishes the page. It cannot edit code or run arbitrary commands, because a test-plan skill has no business doing either. Give it exactly what the job needs and nothing more.
Build it by doing the task once
Do not start by writing the skill. Do the task once, in a chat, with a real ticket, and correct the agent as you go. That correction work is the real content of the skill. When the output is genuinely good, have the agent capture it. This is the exact prompt I use:
Based on everything I corrected in this session, write a
SKILL.md for a skill called qa-test-plan. Put the trigger
phrases I would actually use in the description, in third
person, and state both what it does and when to use it.
Capture the gather-context step, the risk pass, the
"Verify that..." case format, the Open Questions step, and
the publish step as numbered instructions. Keep the body
tight and point it at an examples/ folder for house style.
Copy it, with your own steps in place of mine. Then test the skill in a fresh session with no memory of your corrections. The cold session is the real exam, because it only knows what you wrote down, and where it stumbles is exactly where your instructions were thin. Feed that back in and run it again. Mine took five rounds, including one that taught it to gather context before writing a single case, because a thin ticket kept producing a thin plan.
One caution before you fall in love with your own skill: it amplifies whatever procedure you give it, good or bad, and it does not supply the judgment. The skill makes your output faster, not automatically better, so you still read what it produces.
The triangle, complete
- The rules file carries what the agent always knows.
- A skill carries what it does on demand.
- MCP carries what it can see and touch.
Everything in the rest of this course runs on those three.
Try this today
Name the procedure you re-paste the most, in one line, and write down the three corrections you always end up making to the output. That is the seed of your first skill. The full worked skill, ready to copy or install, is at the AI test plan generator, and the long build story is how to build a Claude skill for QA.
Tomorrow: what a good plan out of that skill actually looks like, and the rule that decides how many cases it gets.