One Command a Day: The Skills That Run the Vault

The entire control layer of my work system, the part that decides what runs and when, is a folder of markdown files. No web framework. No job scheduler. No glue code holding an API together. I write what I want in plain English, Claude Code turns it into commands I can run, and one of those commands runs 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 entire skill. No code, just instructions precise enough that the output is consistent. I covered the mechanics of writing them in a separate piece on reusable commands. 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 score an email's importance, 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 automatically when they're relevant, so the skills don't have to restate them.

Keeping those two apart is the part I'd most recommend copying. When I want to change how strictly an email gets scored, I edit one rule, and every skill that touches email follows the new standard. The procedures and the policies never get tangled.

One front door

I could have a command per source, one to pull email, one for transcripts, one for documents. I don't. Everything funnels through /w-daily. I run it once, and it takes in the night's email, yesterday's meeting transcripts, any documents I dropped in, and the loose notes I typed to myself, then writes the day's briefing. One command, the whole morning, which is the entire point of building it.

A briefing I read in two minutes, on the back of a command I run in one.

It spawns its own workers

/w-daily doesn't grind through all of that itself. It hands the bulk processing to specialized sub-agents that run in parallel: one that handles email, one that handles transcripts, one that handles documents. Each is its own small skill with a narrow job and its own limited set of tools. The master command coordinates and composes; the workers do the repetitive reading. Splitting the work this way keeps a busy morning down to a few minutes instead of one long serial slog.

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 of the day's tokens run cheap, and the expensive model only shows up where it earns its cost.

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 "platform" is small enough to read in one sitting.

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.

It also stays mine in the most literal sense. It's a folder. It copies to a new laptop the way any documents folder does, and nothing has to be running on a server somewhere for my morning to work.

The system is legible

That legibility is the real win, and it's easy to undersell. 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 local transcription, the script-first processing, 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.