Paper · Essay · 12 min · September 2026
Teach once: skills, rules files, and slash commands
Explaining the same standard every session is an architecture problem. A skill is an instruction that loads when the work matches. A rules file is always on. A slash command waits for you to type it.
If you explain the same review format, the same commit shape, the same brand voice at the start of every session, you are paying a tax. The model is not the problem. The architecture is. Nothing in the workspace remembers the standard unless you put it somewhere that loads on purpose.
Three places, three costs. Mix them up and you either burn the context window on rules nobody needs today, or you retype a slash command you forgot existed.
Always on
Rules file. Every turn. Pays rent in tokens.
On demand
Skill. Indexed by description. Loads when it matches.
Invoked
Slash command. You remember. You type.
01The tax
A team of five, twenty sessions a day, the same paragraph about error handling. That is not craft. That is a missing file. The second time you explain a standard, it belongs in the workspace. The fifth time, you are training the humans to distrust the agent.
02What a skill is
A skill is a short markdown document: a description the matcher reads, and instructions the model reads only after a match. You do not paste it. You do not invoke it by name unless you want to. The work arrives. The description fits. The instructions load. The rest of the library stays on disk.
Claude Code calls the file SKILL.md. Cursor has rules. Codex has skills. The filename is not the idea. The idea is conditional context: specialised knowledge that must not sit in every prompt.
# SKILL.md PR review
description: Use when reviewing a pull request, a merge
request, or a diff. Not for greenfield implementation.
## Checklist
- Breaking changes in public APIs
- Tests for new paths
- Secrets and hardcoded credentials
- Error handling matches the repo
- Names match the local convention
## Feedback shape
1. Verdict in one line
2. Must fix before merge
3. Optional
4. What was done wellAsk for a review. The matcher hits the description. The checklist loads. You do not explain the four-part format again. You still read the review before anything is merged. The file does not sign.
03Rules, skills, commands
| Always on (rules) | On demand (skill) | Invoked (slash) | |
|---|---|---|---|
| When it loads | Every conversation | When the description matches | When you type it |
| Context cost | Paid on every turn | Paid only on a hit | Paid when you remember |
| Fits | Invariants: language, safety, repo truth | A specialised job: review, commit, brand pass | A ritual you want to trigger yourself |
| Failure | Crowds the window. The model drowns in policy. | A vague description never fires. | You forget the name. The standard dies. |
TypeScript strict mode belongs in a rules file. It is true of this repo on a Sunday and on a ship day. A PR checklist is a skill. A one-shot “open the weekly crawl report” is a command you type because you mean it now.
The same split exists in retrieval. You do not inject the whole store into the prompt. You search, then you read. A skill is that pattern applied to instructions.
04Personal versus the repo
Personal
Follows you across projects. How you like a commit message. How you like an explanation. Yours. Do not commit it as if it were the team's.
Project
Lives in the repository. Clone gets it. Review shape, brand voice, API patterns. Institutional memory. Survives the person who wrote it.
If the standard is the company's, it belongs in the repo. If it is your taste, it belongs at home. Mixing the two is how a personal snark setting becomes a pull request on someone else's machine.
05The description is the matcher
The body of a skill can be long. The description cannot be vague. It is the job advert. Too narrow and a real review never loads it. Too broad and it fires on a memory-leak debug. Write the situation, not the vibe.
| Weak | Usable |
|---|---|
| Helps with code quality. | Use when reviewing a pull request or a merge request. |
| Writing. | Use when drafting public copy in the Glorics voice. Not for commit messages. |
| Frontend. | Use when changing CSS or layout in this repo. Not for API work. |
06What belongs in a skill
- A review checklist the team actually uses.
- A commit or changelog shape you have already agreed.
- A brand pass: words we do not use, claims we do not make.
- A test pattern that is local to the stack, not a lecture on testing.
- Anything you have typed twice and will type a third time.
A skill is a bad place for a novel, for secrets, and for policy that must hold on every turn. Those go in rules, or they do not go in a file an agent can load unsupervised.
What this is not
A skill is not the agent learning. You wrote it. You can open it. You can delete it. Dynamic “memory” that rewrites itself without a checkpoint is a different, worse product. I will not sell that.
The pattern is small and it is enough: specialised instructions, loaded when the work matches, signed by a person. Teach once. Apply when it is the job. A human is responsible for the line that leaves.
If you have said it twice, put it in a file. If the file cannot be read, it is not a standard.