Skills: automating your workflows

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 /check-diff (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 /check-diff, 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 lives in the repo: your teammates (and their agents) use it as-is.

How it works, concretely

The principle is now the same everywhere: a skill is a folder containing a SKILL.md file. At the top, a small YAML header gives its name and a description; below, your instructions in markdown. The folder can also carry scripts, templates or documentation the agent will consult when needed.

The description matters more than it looks: at startup, the agent reads only the names and descriptions of all your skills, then loads the full content of the one that matches the task. So you can have plenty of them without cluttering its context.

.claude/skills/<name>/SKILL.md    # project skills (shared via the repo)
~/.claude/skills/<name>/SKILL.md  # global skills (all your projects)

.opencode/skills/<name>/SKILL.md           # project skills
~/.config/opencode/skills/<name>/SKILL.md  # global skills
# It also reads .claude/skills/ and .agents/skills/ (project and global)

.agents/skills/<name>/SKILL.md     # project skills (Codex looks up to the repo root)
~/.agents/skills/<name>/SKILL.md   # global skills (all your projects)

An example: the /review command

Let’s take the request from the start, your own review. Watch the name: Claude Code already ships a built-in /review (an alias of /code-review, see Review, audit, secure). So give your homemade version another name, check-diff for instance (Codex also has a built-in /review), and write it down once in .claude/skills/check-diff/SKILL.md, or in .agents/skills/check-diff/SKILL.md for Codex and OpenCode:

---
name: check-diff
description: Reviews the current diff and lists the problems without fixing anything. Use when I ask for a review before a merge.
---

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, /check-diff (or $check-diff in Codex) reruns this exact protocol every time. No more paragraph to retype, no more forgotten step.

The procedure

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.