🧩Skills: automating your workflows
When you catch yourself repeating the same instructions to the agent, turn them into a reusable skill. The step that takes you from 'assistant' to 'workshop'.
You’ll recognize the symptom fast. For the third time this week, you’re typing the same long-winded request: “review my diff, look for bugs and secret leaks, list the problems file by file, but don’t fix anything without my approval.” Word for word, every time. That’s precisely the moment to capture that request once and for all, and recall it with a single command.
That’s what a skill is: a reusable bundle of instructions the agent triggers on demand, often via a slash command. Where the memory file is passive context the agent always reads, a skill is an active capability you invoke when you need it. Picture /review (review my diff), /ship (run the tests, bump the version, commit, open the PR), /deploy. One name, and the whole workflow unfolds.
Why: repetition is a signal
The trigger for a skill is always the same: you catch yourself retyping a multi-step instruction. “Run the tests, and if it’s green, commit with a conventional message, then push…” If you’ve written it twice, you’ll write it twenty times.
Capture it once, and you gain three things at a stroke:
- One command instead of a paragraph. You type
/review, done. - Consistency. The workflow runs the same every time, you no longer forget the “check for secrets” step because you were in a hurry.
- Sharing. The skill is a file in the repo: your teammates (and their agents) use it as-is.
How it works, concretely
The details vary by tool, but the principle is the same everywhere: you write your instructions in a markdown file, and the agent exposes it as a command.
Claude Code reads custom commands from a dedicated folder. A deploy.md file becomes the /deploy command.
.claude/commands/ # project commands (shared via the repo)
~/.claude/commands/ # global commands (all your sessions)
There’s also a broader Skills mechanism: a folder containing a SKILL.md that describes when and how to use it, which the agent loads on its own at the right moment. For the exact fields of the format, check the docs, linked in Resources.
An example: the /review command
Let’s take the request from the start. You write it down once in a review.md file:
Review the current diff against the base branch.
Look for:
- obvious bugs and regressions,
- secret leaks (API key, password, token in plain text),
- unescaped SQL queries or other injections,
- `console.log` and other forgotten debug leftovers.
List the problems grouped by `file:line`, from most serious to most
benign. Be concrete: for each point, say why it's a problem.
Don't fix anything without my approval. End with a verdict: ready to merge, or not.
From then on, /review reruns this exact protocol every time. No more paragraph to retype, no more forgotten step.
The procedure
Spot the repetition
The reflex: the moment you think “hey, I’ve typed this before,” stop. That’s your skill candidate. Don’t create it preemptively, wait until the need shows up twice.
Write the instruction once
Create the markdown file in the right place (deploy.md → /deploy). Write the instructions the way you’d say them to the agent: clear, ordered, with the guardrails (“don’t fix anything without my approval”).
Invoke it by name
In the agent, type /review. The skill unfolds. You just turned a paragraph into a single word.
Refine it over time
As you use it, you’ll see what’s missing or what overflows. Add a criterion, tighten a directive. The skill matures like memory does: through real friction.
The big picture: your workshop composing itself
Sit back and look at what you’ve built across these three guides:
- Memory (memory files), what the agent knows at all times.
- Skills : what it knows how to do on command.
- Framing (framing with an LLM), the quality of what you ask it for in the first place.
Put end to end, this becomes a personal workshop that composes itself. Each project enriches your global memory, leaves you a skill or two to reuse, sharpens your framing patterns. The tenth project starts on the shoulders of the first nine. That’s the whole point: you’re not automating a task, you’re building yourself an environment that makes you a little faster every time.