Claude Code skills: building a workflow that runs itself

The control layer of my work system, the part that decides what runs and when, is markdown plus a set of small scripts. No web framework of my own. No app server or job queue to maintain. I write what I want in plain English, the scripts handle deterministic work, Claude Code handles judgment, and one command processes my whole morning.

The work itself lives in a vault, which is Obsidian's word for a folder of plain notes sitting on your own disk. Mine holds the email, meetings, and documents from my week.

A skill is just a markdown file

In Claude Code, a skill, also called a slash command, is a markdown file full of instructions. You describe what the command should do in the same words you'd use to brief a colleague, and it becomes something you run with a slash. One of mine, stripped down, reads roughly like this:

# w-1on1: one-on-one prep

When I run /w-1on1 [name]:
1. Pull this person's last few interactions from the index.
2. List the open action items they own, and the ones I owe them.
3. Draft three talking points from the recent threads.
Keep it to one screen. Link to the source notes instead of restating them.

That is the core of the skill. The real version is longer: it builds the indexes, prepares a small data bundle, and hands the synthesis to an Opus worker with limited tools. The procedure itself is still plain instructions rather than application code. I covered the mechanics of writing them in Creating reusable Claude Code skills. Here I want to show what a real set of them looks like.

Mine all start with w-:

Seven commands, and the first one does most of the work.

Skills do, rules define

The other half of the system is rules. Where a skill is a procedure (do this, then this), a rule is a standard the work has to meet: how to turn a name into a link to the right person, what actually counts as an action item, who sits in which tier of seniority. Rules live in their own folder and load with the project, so the skills don't have to restate them.

Keeping those two apart is the part I'd most recommend copying. When I change how names resolve to people, or what counts as a verified action, I change the shared rule rather than every command. The procedures and the policies don't get tangled.

One front door

I could have a command per source, one for email, one for transcripts, one for documents. I don't. Everything funnels through /w-daily, but the sources arrive in different ways. A scheduled Windows task copies captured email into the inbox. I drop documents and loose notes there too. Plaud recordings can be pulled when the command runs. /w-daily does not fetch email. It processes whatever is waiting and writes the day's briefing. One command, the whole morning, which is the entire point of building it.

I run one command, then read the resulting briefing.

It spawns its own workers

/w-daily doesn't grind through all of that itself. For larger batches it dispatches general-purpose sub-agents that run in parallel: one prompt handles transcripts, another email, another documents. Smaller email and document batches stay in the main context. The master skill coordinates and composes, while the prompt files keep each worker focused on one kind of note. Splitting the work this way avoids processing everything one by one.

A cheap brain and a smart brain

Not every job deserves the best model. The high-volume workers, the ones reading an email or condensing a transcript, run on a fast and cheap model that follows clear rules well. The judgment-heavy skills, the weekly review or the one-on-one prep, run on the strongest model I have, because that is where writing quality and real synthesis matter. The command doing the orchestrating mostly just routes each job to the right brain. Most tasks use the cheaper model. I use the expensive one only where the extra quality matters.

Why not a real app?

A custom application doing the same thing would need a web framework, a job queue, an API client, authentication, somewhere to deploy it, and a pile of code to keep alive. The markdown approach has none of that. The skills and rules are version-controlled text. When the workflow changes, and it changes constantly, I edit a file in plain language instead of refactoring a service. The whole system is small enough that I can read all of it.

There's a blunter version of that argument. Building the app would cost me more hours than the problem is worth. What I need shifts every few weeks, so I'd be maintaining software about my own habits, and the maintenance would outlive most of the habits. Writing down what I want takes minutes, and the writing is the thing that runs.

The files also stay mine in the most literal sense. The vault copies to a new laptop the way any documents folder does, and I don't run my own server for it. Claude Code still sends the note content to Anthropic for the model work and uses my plan quota. Local files do not mean local processing.

The system is legible

Being able to read the whole system is the real win. The thing running my work is a folder of instructions a careful person could follow by hand. I can read exactly what a command will do before I run it. I can change its behavior by editing a sentence. And because it's all plain language, I can hand a piece of it to the AI itself and ask it to extend the system it runs inside. If you'd like to read the actual skills and rules, a sanitized copy of the whole vault is public on GitHub.

If you've used Claude Code to knock out a one-off task, this is the same tool with the tasks made permanent. That is the whole series, really. Not one clever trick, but a stack of small, legible, boring parts, each doing a job it's actually good at: the capture, the transcript processing, the script-first preparation, and the handful of commands that tie them together. None of it is the thing from the keynote. All of it is mine, and I can read every line.