Turning Routines Into Skills
From prompt macros to /brainstorm, and the difference between storing knowledge and encoding behavior
Five files. Five questions. A CLAUDE.md that ties them together. The setup works. Claude picks up where you left off, every session, for every project.
But you’re still the one holding it all together.
“Read the specs first.”
“Update status when we’re done.”
“Check the pipeline.”
“Commit the changes.”
Every time you add something new to the system (a new file, a new convention, a new check), that’s one more thing to remember to tell it.1
The files hold the knowledge. But they don’t carry the session forward on their own. You still have to remember what Claude should read first, what to update at the end, and what changed since last time.
That’s what skills are for. But to get there, we start with something simpler.
Shortcuts
One thing that made a real difference early on, before models that code, was codifying instructions I found myself repeating. goodalexander called these “prompt macros.”2
One of the first ones I used: OPTIMIZE. The problem it solves: you braindump a flurry of thoughts into a chat, knowing well the model would give you a much better response if your request were cleaner, more structured. But you don’t want to rewrite it. So instead, you type OPTIMIZE, and the model restructures your prompt into something precise, then answers that.
But how does it know what OPTIMIZE means? You define it.
Here’s the definition, abridged from the one I actually use:
OPTIMIZE: Analyze the prompt that follows for ambiguities and missing context. Rewrite it as a detailed, actionable specification: add defaults, specify output format, include operational requirements. Then execute the refined version.
You save this somewhere the model can access it. Claude has project instructions; ChatGPT has custom instructions. Or just tell it in a chat: “remember this definition for OPTIMIZE.” Most LLMs now have memory that persists across conversations, even if it’s not always the most reliable.
If you have never tried a version of this, try it now. Paste that definition into your project instructions in Claude or ChatGPT. Then braindump something messy and type OPTIMIZE before it.
Or try VARIANTS, to get structurally distinct alternatives instead of slight variations. And PUSHBACK, to force the model to disagree with you (an anti-sycophancy protocol). Ask your favourite model to help you define these macros, and to commit them to memory. Then use them.
I built a much larger set of shortcuts over time.3 And of course, once you get the idea, you may have Claude itself suggest and create macros for how you work. At the very least it will help you structure them properly.
From macros to skills
Shortcuts are a great beginning, but skills are what you’re really working toward. The gap between them is smaller than you’d think.
Anthropic’s Thariq Shihipar put it neatly: “Using Skills well is a skill issue.” The hard part isn’t writing the command. It’s recognizing which repeated moves deserve to be encoded.4
I find it useful to think of skills as shortcuts that Claude Code (or Codex) knows to read.
Claude Code has a dedicated place for them: a .claude/skills/ directory that it knows how to find and read automatically. Each skill is a markdown file. Not code. Not a plugin. Just structured instructions in plain language that Claude follows when you type a slash command — /log, /end, /brainstorm. Claude Code is built to work with skills: it knows where to find them, reads them on demand, and Anthropic spends real effort helping you write good ones.
The idea is the same as macros. PUSHBACK the macro became /pushback the skill. VARIANTS became /variants.
The instructions look similar. The reach is different. A skill can read your project files, check past decisions, produce structured output, update your specs. A macro can’t do any of that — it only shapes how the model responds within a single conversation.
If you wrote a macro, you can write a skill. Same thinking, different reach.
The first routine worth encoding
The first thing I wanted off my plate was session continuity.
In the last post, the promise was simple: Claude picks up where you left off. But that only works if someone reliably reads the right files at the start and updates them at the end. /start and /end turn that from a repeated instruction into a routine.
/start reads your spec files, detects what you’re here to do from your opening message, and surfaces relevant context. /end updates status.md and pipeline.md so the next session doesn’t begin cold.
You saw these in the last post. Now you know what’s inside: a markdown file in .claude/skills/ that Claude reads when you type the name. The routine you used to perform manually, encoded once, invoked forever.
That alone is useful. But it’s also the expected example. The more interesting move is what happens at the beginning of a project.
How every project begins
Before Claude writes a line of code, I want it to grill me — ask the hard questions, surface what I haven’t thought through, and save the result as a design.md.
That interview is a template. Here’s what it looks like:
The Idea — What are you building? What triggered this? Walk me through using it step by step.
Context Check — Does this overlap with something you already have? Who uses it? Where does it fit?
Scope Boundaries — What’s the minimum version that’s useful? What are you explicitly not building? Push back on “it should also...”
Technical Constraints — What does it integrate with? Any hard limitations?
Success Criteria — How will you know it’s done enough to use?
Synthesis — Reflect back, surface tensions, propose boundaries, draft the spec files.
You can use this today. Paste it into any LLM and run the interview yourself. You’ll get a better design.md than if you’d just said “help me plan my project.”
I folded this template into a skill called /brainstorm.5 Now I type one word and Claude runs the full interview — checks my existing projects for overlaps, grills me on scope, pushes back when I’m cramming two features into one, and produces a design.md at the end.
Same template. One word.
And it works for more than kickoffs. Mid-project, when I’m thinking about a new feature, /brainstorm runs the same interview adapted to what already exists. It reads the codebase, assesses impact, tells me if the feature is more invasive than I think.
CLAUDE.md, revisited
Once you have spec files and skills, you need one file that points to all of it. This is where the file you built in the last post becomes the index for the whole system.
When Claude Code’s source code was accidentally leaked recently, one thing became clear: the system prompt Claude sees isn’t just your CLAUDE.md. It’s a compiled artifact, assembled from safeguards, feature flags, memory layers, model-specific instructions, and more.6 Your CLAUDE.md is one piece of that assembly. But it’s the only piece you write.
Of everything that constitutes how Claude behaves in your session, CLAUDE.md is the one lever you actually control.
Here’s what mine looks like at the global level, the CLAUDE.md that applies across every project:
# CLAUDE.md — Global Constitution
This file is the entry point.
Behavioral rules live in ~/.claude/rules/.
Skills live in ~/.claude/skills/.
## Rules (always loaded)
| Rule | What it governs |
| critical-thinking | Verification protocol, anti-leaping |
| identity | Who I am, working style, values |
| coding-style | Python conventions, formatting |
| git-workflow | Commits, branches, .gitignore |
| security | SQL safety, secrets, auth |
...
## Specs Protocol
On session start: read design.md, status.md,
pipeline.md, decisions.md.
On session end: update status, pipeline, decisions.It’s an index. Pointers, not content. It tells Claude where to find the rules, where to find the skills, and what to do with the spec files at the start and end of every session. The actual substance lives in the files it points to.
Each project also has its own CLAUDE.md — narrower, project-specific. Run commands, folder structure, constraints that only apply here.7 Two layers, one principle: point, don’t dump.
The pivot
Two Files was about giving Claude files worth reading. A Five-Part System was about giving each of those files one job. This post is about teaching the system what to do with them.
And the scaffolding predates the tooling. The macros I wrote in a notes app — OPTIMIZE, PUSHBACK, VARIANTS — became the skills I use in Claude Code. Same cognitive patterns, wider reach. If you’re not using Claude Code, start with macros. Any LLM, today. When you outgrow them, they become skills.
The point is the habit: encode the move once, stop restating it every session.
This only grows. Once you start tracking decisions, managing a pipeline, committing code, syncing backups, the end-of-session checklist gets long. Forgetting one item (updating pipeline but not status, or committing but not syncing) means the next session starts with stale context. This is exactly the kind of routine that should be automated.
goodalexander’s 11 AI Prompting Heuristics were the seed for much of this thinking. His “Disagreeable Model” heuristic became my PUSHBACK macro, which became the /pushback skill.
I’m publishing a small starter set in dev-setup, with one file per macro: optimize.md, steps.md, variants.md, pushback.md, and snapshot.md. The internal set is larger.
Anthropic’s team has written about building skills at scale. Thariq Shihipar’s lessons from hundreds of production skills describes categories, progressive disclosure patterns, and the principle that good skills give goals, not step-by-step procedures. Anthropic’s official skills guide covers the mechanics.
I’m packaging the public version of this flow in dev-setup: trimmed versions of /start, /end, and /brainstorm, plus the kickoff reference it uses at .claude/skills/brainstorm/references/kickoff-flow.md.
When Claude Code’s TypeScript source was accidentally shipped in an npm package in March 2026, community analysis revealed that the system prompt is assembled from ~20 boolean switches — safeguards, feature flags, memory content, mode-specific instructions. CLAUDE.md is one input to that assembly. The rest is Anthropic’s.
Anthropic’s CLAUDE.md documentation recommends keeping it under 200 lines and focused on things the model can’t figure out from reading the code.