Part 7 of 7 · Chapter 3 of 4

Building Your Own Commands and Skills

Turning a workflow you repeat into a command the AI can run, so the good version happens by default.

Advanced12 min read

Worth reading first: Rules Files

Once a workflow is good, typing it out every time is waste — and worse, you will type a slightly worse version on the days you are tired. Custom commands make the good version the default one.

Start by noticing the repetition

You already have candidates. Look for the prompts you have written more than three times with only small changes:

1
“Review this for security issues, checking for…”
The security pass from Chapter 21.
2
“Write tests covering the normal case, empty input, and the boundaries”
Your standard test request.
3
“Explain what this file does and where it is used, then wait”
The comprehension pattern.
4
“Write a commit message from my staged changes”
Every single commit.

Each of those is a command waiting to exist.

Slash commands

Most agent tools let you save a prompt as a file and invoke it by name. In Claude Code that is a markdown file in .claude/commands/; other tools use their own directory but the idea is identical.

.claude/commands/security-review.md

Review the staged changes for security problems. Check specifically:- secrets or credentials in source- unvalidated input reaching a query, command, or the DOM- endpoints that check authentication but not ownership- errors that leak internals to users For each issue, give the attack and the fix. If a categoryis clean, say so explicitly rather than staying silent.

Now /security-reviewruns the full, careful version every time — including on the day you would have typed “check this for security stuff.”

Commit them to the repo

Keep commands in the project, not in your personal settings. Then everyone working on it — including future you on another machine — gets the same workflow, and improving a command improves it for the whole team in one commit.

It also makes the commands reviewable. A prompt that shapes how code gets written deserves the same scrutiny as the code.

When a script beats a prompt

Important boundary: if a task is fully deterministic, do not use a model for it. Write a script. It is faster, free, and cannot have an off day.

1
Deterministic — write a script
Formatting, renaming by pattern, generating an index file, checking for forbidden strings.
2
Requires judgement — write a command
Reviewing, explaining, naming things, deciding what to test.

This repository has both: scripts/validate-learn-nav.mjs checks curriculum data mechanically and fails the build, because that check has one right answer and should never be a matter of opinion.

The part that compounds

Each command you write makes the next task slightly cheaper. After a few months the accumulated set is more valuable than any individual model improvement, because it encodes how your project specifically wants to be worked on — which no vendor can ship you.

That is also the thing you take with you. Models will keep changing. A well-shaped workflow outlives whichever one you are using this year.

Key takeaways

A prompt you have typed three times is a command waiting to be written.
The value is consistency: your best prompt applied every time, not a shortened version from memory.
Commit commands to the repo so the workflow is shared and reviewable.
Deterministic work belongs in a script, not a prompt. Judgement work belongs in a command.
Accumulated commands encode how your project wants to be worked on — that is yours, and it outlasts the model.