The workflow you run every week should be a skill, not a habit

There's a specific kind of work that eats your week and never shows up on a to-do list: the tasks you do the same way every time. The weekly status report. The competitive teardown before a deal. The bug report you have to turn into something an engineer can actually action. You know the steps cold. You've done each one fifty times. And every single time, you start from a blank page and rebuild the whole thing from memory.

That's not a habit. A habit runs itself. This is the opposite: a process that lives entirely in your head and has to be reloaded, by hand, on every use. The cost isn't the work. It's the reloading.

A habit is automatic. A process is not.

Brushing your teeth is a habit. You don't decide the steps; your hands know them. But "write the Friday status report" isn't automatic, even after a year of Fridays. You still have to remember which five sections, in which order, for which stakeholders, in what tone, and then do the actual assembly. The knowledge is real and it's yours, but it's tacit. It never got written down, so it can't run without you carrying it.

Tacit process has three quiet taxes:

• The reload tax. Every use starts with "okay, how do I do this again," even when the answer is always the same.
• The drift tax. Do it from memory enough times and the steps quietly change. You drop the check you used to run. The output gets a little worse and you don't notice.
• The bus tax. It only exists in one head. Nobody else can run it, and if you're out, it doesn't happen.

The fix for all three is the same move: stop carrying the process and start declaring it.

What "declaring it" actually means

A skill is a process written down in a shape a model can execute. Not a vague description. A contract, with four parts:

• Goal. What "done" looks like, in one sentence.
• Trigger. When you'd reach for this. ("A raw bug report just landed and needs triaging.")
• Steps. The actual moves, in order, including the checks you make without thinking.
• Output format. The exact shape of the result, so it comes out the same every time.

Take a real one. Turning a messy bug report into a triage summary is a workflow most people do by feel, badly, in a Slack thread that dies mid-argument. Written as a skill, it stops being a vibe:

1. Extract every factual detail from the raw report first: component, environment, actions taken, error text.
2. Rebuild the reproduction steps as a numbered sequence, flagging anything implied rather than stated.
3. Write expected vs. actual as two flat sentences, no interpretation.
4. Only then assign severity and priority, each with a one-line justification tied to impact, data risk, frequency, and workaround availability.
5. Assign an owner and a mitigation last, because they depend on everything above.

Notice what happened. The severity rating stopped being an opinion and became the conclusion of the four lines above it. That's what declaring a process buys you: the judgment gets baked into the order of the steps, so it survives even when you're tired, rushed, or handing it to someone junior.

Why a skill beats a saved prompt for this

You might already keep a good prompt for some of these. A prompt is a great start, but a repeated workflow usually isn't one prompt. It's a sequence with judgment between the steps, a specific output contract, and a trigger that tells you when to run it. A saved prompt captures the words. A skill captures the process: the order, the checks, the shape of the result.

The practical difference shows up the third time you use it. A prompt you tweak a little every time slowly drifts. A skill you run the same way every time compounds. It gets sharper as you refine the steps once, and everyone downstream inherits the improvement.

How to turn your next repeated task into a skill

You don't need to plan a system. Just catch yourself the next time you start a task you've done before, and instead of doing it from memory, narrate it:

1. Name the trigger. What just happened that made you start this? That sentence is your trigger.
2. Talk through the steps out loud as you do it once. Every "and then I always check…" is a step you'd otherwise have lost.
3. Write down the output shape you actually want: sections, order, length, tone.
4. Save it as a skill, not a note. Next time, you run it instead of rebuilding it.

Describe the workflow in plain English and Korvai drafts the goal, steps, and output format for you, then installs it into Claude Code and Cowork as a slash command you run on demand. The gallery is full of these already: Contract Review, Competitive Teardown, PRD Writer, the bug triage above. Not because they're clever, but because they're the boring, repeated, every-week work that should have been declared a long time ago.

The test for whether something should be a skill is simple: if you've done it the same way twice, you'll do it again. Stop carrying it in your head. Write it down once and run it.