Detailed content
🖐️ Start manually: do it by hand, then capture it
The Skills layer starts in the least obvious way: by hand. You do the actual task once — sometimes spending an hour typing out all your reasoning about how to tackle the problem — and only afterward capture that in a skill. The goal is simple: by the end of that session, never have to repeat that level of instruction again.
🌱 New here?
A skill (skill) is a task packaged to run the same way every time—think of a recipe card. In Claude Code, it usually becomes a slash command (a command that starts with a slash, e.g., /monthly-review), stored in a file SKILL.md inside the folder skills/ of your OS. You “cook by feel” a few times and only then write down the recipe.
How to read: a skill doesn't come out of nowhere. It's the last step in a path that starts with doing the task by hand—that's why a skill for something you've never done ends up generic.
✓ Manual first
- ✓You prove the task works before packaging it.
- ✓The recipe reflects the real-world details that only emerge as you work.
- ✓You know exactly what to check at the end.
✗ Phantom skill
- ✗Writing a skill for something you've never done by hand.
- ✗Generic result that breaks on the first real case.
- ✗You don’t have criteria for knowing whether it worked.
Why learn
Because it’s what separates a living skill from a dead one. Doing it by hand first brings all the fine details—exceptions, step order, what to check—into your context, details a skill invented from scratch doesn’t have. Capturing it afterward turns that work into an asset you never have to redo.
Key concepts
🔁 Reverse meta-prompting
After doing the task by hand comes the capture. The mechanism is called reverse meta-prompting: instead of writing the skill yourself, you ask the AI to distill the conversation you just had into a reusable command. It’s writing the recipe afterward before cooking, not after.
🌱 New here?
Common "meta-prompting" is when you give instructions to the AI. Reverse meta-prompting flips this around: AI looks at what you’ve already done together and extracts the instructions—the criteria, the order, the precautions—and turns them into a file. You become the editor of a recipe AI drafted from your own actions.
💡 The key insight
Always ask for a slash command that accepts an argument. This argument is a natural-language sentence that enriches what the command does—so the same skill works for multiple use cases without you having to rewrite it. Under the hood, it should have an SOP (standard operating procedure): exactly what happens, and in what sequence.
Why learn
Because it’s the shortcut that turns a one-time effort into a lasting capability. Without reverse meta-prompting, every task starts from scratch. With it, the first hands-on run “pays for” all the next ones—and you also learn to structure the request (distill criteria → materialize → accept the argument).
Key concepts
♾️ The infinity signal: a skill is never finished
When you have a V1 of the skill, you launches (ship). But the skills layer is the one that causes the most confusion: many people think a skill “starts and ends” something. No. There’s a infinity sign here. The author maintains a skill that's refined almost every day for six months.
How to read: there’s no “end” in the right corner. The skill revolves: launch, use it, do the postmortem, adjust — and use it again. The ∞ symbol in the center is the point: the skill is alive while you use it.
🔎 The exception that becomes a rule
There’s one case where the skill “ends”: when it triggers 100% autonomous, always with the same input and output. Then the right question comes up — should this still be a skill, or is it already a deterministic script? (That's topic 5.)
Why learn
Because it calibrates expectations. Anyone who expects to “finish” a skill abandons it at the first friction, and it decays. Anyone who understands the ∞ comes back, adjusts, and ends up with an ever-better skill—the exact “cultivate, don’t install” mindset applied to the action layer.
Key concepts
🧪 End-of-session postmortem (with rubric)
How, in practice, do you turn the ∞ from the previous topic? With a postmortem at the end of the session. You ask Claude Code: "based on how this session went, how—if at all—should we refine the skill?". And provide a rubric: the criteria for when to change something and when to leave it as is.
Why learn — the 4-step postmortem
Ends the session
You used the skill on a real task. Before wrapping up, it’s still fresh in the context’s memory.
Ask for the adjustment
"Given how it went, should we change the skill? What and why?" The AI proposes targeted refinements.
Apply the rubric
The rubric tells you when it's worth making a change (recurring error, missing step) and when it isn't (a one-off case).
Persists the learning
The adjustment goes into the skill (or a rule). Next time, the skill is already better.
💡 Why the rubric matters
Without a rubric, AI changes the skill with every passing breeze—and you accumulate impulsive changes that contradict each other. The rubric is the brake: it only changes when the criteria justify it. It may seem overly meticulous, and there are other ways to evaluate, but this is what keeps the skill stable.
Key concepts
⏰ Skill vs. scheduled job (cron)
Not everything repetitive should be a skill. If something runs 100% autonomous — same input, same output, no judgment — maybe it should be a deterministic script (a Python or JavaScript script the AI writes itself), possibly triggered by a cron.
🌱 New here?
One cron (or “scheduled job”) is a system clock that runs a command automatically at a fixed time—for example, every Monday at 8 a.m. Deterministic means: given the same input, always the same output, without the AI "deciding." It's the opposite of a skill that calls for judgment every time it's used.
✓ Leave as a skill when
- ✓Each use calls for some judgment or new context.
- ✓The argument changes what it does each time.
- ✓You’re still refining the process.
→ Turn it into a script/cron when
- →Runs 100% autonomously, always the same way.
- →It doesn't need to be in context every session.
- →You want to save tokens and context window space.
Why learn
Because a skill isn’t the answer to everything—and treating everything as a skill makes the OS more expensive. A 100% predictable process runs more cheaply and reliably as a script: it doesn’t consume context, doesn’t need to be loaded for every new Claude Code session, and doesn’t risk the AI “improvising.”
Key concepts
⚠️ The common mistake: 10 skills at once / a skill never done
The skills layer has three classic traps: people underuses skills, people accumulates too many skills, and people think they’re clever and create many skills at once — that remain stale (dead) without ever being used. Add the worst one: writing a skill for something you never done by hand.
⚠️ The mistake to avoid
Spending a weekend generating 10 skills "because they seem useful." Without real use, they age, contradict each other, and clutter the folder skills/. You start trusting recipes that have never been tested under fire.
✓ Healthy habit
- ✓Start with ONE skill: the task you repeat most often.
- ✓Every skill starts with something already done by hand.
- ✓Create the next one only when the pain comes back.
✗ Anti-patterns
- ✗10 skills at once "because they seem useful".
- ✗Skill for something you’ve never run.
- ✗Accumulating recipes that never run (stale).
Why learn
Because the temptation to “turn everything into a skill” is strong and costly. A lean folder of active skills—each born from a real pain point and maintained through use—is worth more than a library of dead recipes. Less is better, and always start from what you already do.
Key concepts
📝 Copy-run: distill this conversation into a slash command
Time to get hands-on. Do a task manually with Claude Code (any task — sorting some files, drafting a standard reply). When you’re done, paste the prompt below: it applies the reverse meta-prompting and builds your first skill — a slash command that accepts an argument.
Copy and run in Claude Code
Objective: distill the conversation you just had into a reusable slash command that accepts a natural-language argument.
Paste at the end of the session (replace what’s between < >):
Com base em TODA esta conversa, destile o critério exato que eu te dei e materialize-o como um slash command reutilizável. Crie a skill em: skills/<nome-da-skill>/SKILL.md O comando deve: - chamar-se /<nome-da-skill> e ACEITAR UM ARGUMENTO (uma frase em linguagem natural que enriquece o que ele faz); - ter um procedimento operacional padrão (SOP): exatamente o que acontece, em que sequência; - listar, no fim, um "done-check": como eu verifico que deu certo. Antes de escrever o arquivo, me mostre o SOP em bullets e espere meu OK.
How to verify: run /<nome-da-skill> "a test case" in a new session. If the command reproduces what you did by hand and respects the argument you passed, the skill is alive. Also check that the file skills/<nome-da-skill>/SKILL.md exists and has the SOP + done check.
💡 Tip
Note the "wait for my OK" at the end of the prompt. Asking for the SOP in bullets before saving the file lets you correct the recipe while the conversation is still fresh — it’s reverse meta-prompting with a review gate built in.
Why learn
Because it’s the difference between reading about skills and have one. By running this prompt, you experience the whole cycle — manual → capture → V1 — and leave the module with a real artifact in the folder skills/ of your OS.
Key concepts
📄 Anatomy of a SKILL.md
To wrap up, let's open up the recipe. One SKILL.md is just a text file (Markdown) with four parts that matter: name, when to use (the trigger), the step by step (SOP) and how to verify. Knowing this anatomy lets you read, debug, and improve any skill.
How to read: from top to bottom is the AI’s own reading order: it sees the name, decides whether the trigger matches, follows the SOP, and checks the done-check. The three in the middle are cyan; the done-check (in purple) is what you’re most likely to forget—and what matters most.
Illustrative skeleton — a minimal SKILL.md
--- name: monthly-review description: Revisa o extrato do mês e gera um resumo categorizado. --- ## Quando usar Quando eu pedir a revisão mensal de gastos, ou passar um extrato novo. ## Passo a passo (SOP) 1. Ler o extrato em <arquivo> (argumento). 2. Categorizar cada transação. 3. Apontar gastos fora do padrão. 4. Gerar o resumo em resumo-<mes>.md. ## Done-check - Todas as transações têm categoria. - O resumo lista os 3 maiores gastos do mês.
Why learn
Because anatomy is the common language of the entire layer. When you read a skill (yours or someone else’s), looking for these four parts tells you right away whether it’s complete—and the missing done-check is the number one failure. With this, you finish Track 3.1 ready for the next layer: Tools.
Key concepts
✅ Module summary
Next module:
3.2 — Tools & Connections: the wires to the outside 🔌