Slash Commands and Rules: Stop Retyping the Same AI Correction

You type the same six sentences at the start of every feature. Branch off main with a sane name. Implement only what I asked - no drive-by refactors. Run the build before you touch a commit. Show me the diff. Squash it into one clean commit. Don’t push until I say so.

By the third feature of the day you’re abbreviating. By the fifth you’re skipping the build gate because you’re tired and the agent “usually gets it right.” That last shortcut is the one that ships the regression.

Here is the tension this post runs on: the instructions you dictate every single time aren’t instructions - they’re a workflow you haven’t written down, and an unwritten workflow runs at whatever patience you have left that afternoon. Every other input - the model, the rules file, the reviewed diff - is under somebody’s control. Patience degrades across a day and answers to nobody.

So the question is narrow: should a procedure’s reliability depend on how well it was retyped at 5pm? Below, that reliability gets a price, and then the price gets moved somewhere it can’t degrade.

Don’t take this post’s word for it. Open the chat history of your coding agent and search for a phrase you know you type. “Don’t push yet.” “Run the tests first.” “No drive-by refactors.” Whatever your version is.

Now count how many separate sessions it appears in.

Three or more, and you have this, in the exact shape this post works on: a correction you already decided on, still traveling through the chat as if it were new information each time. Keep reading.

Every instruction in that history specific to its own task, nothing repeated? You don’t have this problem, and the arithmetic below describes a cost you aren’t paying. Close the tab.

One boundary note. If what repeats in your history is the agent being wrong about a fact - “we migrated off the old ORM” - that’s a different problem, and letting the failure distribution write your rules file mines a whole transcript history for them. This post is about the trigger you catch live: you hear yourself say the same thing twice, today.

Here’s where the piece ends up, so you can check every section against it. Priced with a small invented schedule, retyping that ritual from memory costs about 43 silently skipped build gates in one ordinary quarter of shipping. Encoded as a slash command, the same ritual costs exactly zero. Not because the model got smarter - because skipping a step stopped being a decision anyone makes at run time.

Three repeats of the same correction is the whole test: the decision was made long ago, and it is still traveling through your typing.

Fix one concrete ritual and carry it through the rest of the post: the feature-shipping routine from the opening paragraph. Written down properly it has six steps, and every one of them is a real command or a real instruction:

1. git checkout -b <type>/<short-slug>
2. implement ONLY the described change - no drive-by refactors
3. npm run build && npm test    # hard gate, stop on failure
4. show the full diff, wait for approval
5. git commit with a Conventional Commits message
6. do NOT push or merge until explicitly told

Six steps, real commands, no judgment calls hiding in the wording. Two of them take an argument: the branch name and the description of the change. Everything else is fixed. That is a function with two arguments, and you have been re-typing its body from memory five times a day.

Now pick the step this post will follow to the end: step 3, the build gate. Step 3 is the interesting one because skipping it is the only shortcut that is invisible while you take it.

Skip step 1 and there is no branch; the run stops immediately. Skip step 4 and the commit lands unseen; you notice within the minute. Skip step 6 and you’ve pushed; the pipeline tells everyone. Skip step 3 and the diff still looks fine, the commit message is still clean, and the work still reads as done. The failure surfaces days later, in someone else’s incident channel, attached to a commit nobody connects back to a tired Tuesday.

That asymmetry is why step 3 is the one that dies. Every other step enforces itself. Step 3 enforces nothing; its only enforcement was you, and by the fifth feature of the day you aren’t enforcing, you’re hoping.

Step 3 is the step to watch because skipping it costs nothing visible at the moment you skip it.

Now put a number on the hoping. The five probabilities below are invented for this walk-through, chosen so you can check every later figure with a pencil. They model what the opening scene already showed: the version of the ritual you actually send degrades across the day. First feature, you type all six steps. Third feature, you abbreviate to three. Fifth feature, you type “ship the rate limiter” and trust the agent to know the rest.

Ground truth first, computed the obvious way with no shortcut: add the five chances up. The sum is an expected count - the average you’d get over many identical days - and expected counts add whether or not the individual skips have anything to do with each other. There is no independence assumption hiding in this. It is literally five numbers added.

0.02 + 0.05 + 0.10 + 0.20 + 0.35 = 0.72

0.72 expected skipped build gates per day. Remember 0.72. It gets paid off exactly, by two independent routes, in the next section.

Look at what the number says. Less than one skip a day, which is precisely why this failure never gets fixed: no single day exposes the habit, and it costs nothing visible on the day it happens. A failure you can’t see, at a rate too low to alarm anyone, inside a procedure that still produces clean-looking commits every evening.

0.72 a day is small enough to ignore every day, which is exactly how it survives a whole quarter.

One day means little; the habit is a quarter long. Define a toy quarter, deliberately plain: 12 weeks, 5 days a week, 5 features a day. That is 60 days and 300 ritual runs.

Two independent routes to the quarter, so the answer can’t be an artifact of one method.

The first route reuses the daily number. 0.72 expected skips per day, times 60 days: 43.2.

The second route refuses the shortcut and re-sums the raw schedule once per day, 60 times over, all 300 run probabilities individually accounted. It lands on 43.2 as well. Two routes, one number.

That is the 0.72 from the last section paid off, and it is the spoiler from the top of the post made exact: 43.2 silently skipped build gates per quarter of ordinary shipping pace. The “about 43” was this number rounded. Every one of those 43 runs is a change that reached commit without its gate, and whether a regression rode along inside any given one is a coin you never flipped.

The whole figure derives from one declared fact: the chance you actually include step 3 falls as the day goes on. No measurement, no claim about your team. Change the five percentages and the total moves, but it only reaches zero if the schedule does - if the ritual arrives intact on every run, including the fifth at 5pm. That is a property of the person, and nobody can patch people.

43.2 is the ordinary-quarter bill for keeping the gate in your typing, paid in changes that reached commit unchecked.

Look at where the 43.2 actually comes from. Every one of those 300 runs contains a live decision - do I type all six steps, or does the agent probably have this one? And the decision is made at the moment of least resistance, by the tired version of you, against a shortcut whose cost is invisible. The procedure was decided once and is being re-decided 300 times. The re-deciding is where every one of the 43 slips through.

The move that fixes this has a name, and by now you could have invented it: the willpower transfer. It is the moment a step stops being something you have to remember to enforce and becomes something a file enforces whether or not anyone is paying attention. You transfer the gate out of the operator and into the file. After the transfer, tired is irrelevant, because tired no longer has a decision to make.

Here is the ritual after the transfer. A slash command is a parameterized prompt stored as a file: the fixed steps live in the file, and the parts that change live in the argument.

---
description: Branch, implement, gate, review, commit - the house feature workflow
argument-hint: <type>/<slug> - <what to build>
---

You are running the house feature workflow. The argument is: $ARGUMENTS

1. Create a branch named from the `<type>/<slug>` portion, off the latest main.
2. Implement ONLY what the description after `-` asks for. No drive-by refactors.
3. Run `npm run build && npm test`. If either fails, stop and report - do not continue.
4. Show me the full diff and wait. Do not commit until I approve.
5. On approval, commit with a Conventional Commits message derived from the change.
6. Stop. Do not push or merge - that's a separate, explicit step.

Honor every constraint in AGENTS.md, especially the approval and build gates.

The whole invocation becomes:

/ship feat/rate-limit - add a 100 req/min limiter to the public API

Notice what changed mechanically. When you type /ship, the file’s body is substituted into the prompt verbatim - the same characters every time, before the model does anything. Step 3 arrives in full whether it is 9am or 9pm, in run 1 or run 300. Your typed instructions were a reconstruction from memory, rebuilt each session by a person whose accuracy you just watched degrade across the day. The file is read, and reading does not get tired. To skip step 3 now, somebody has to open the file and delete the line: a deliberate act that leaves a mark, in place of a lapse that leaves none.

Because the command is a file, it can also gather live state: in Claude Code, a line beginning with ! and a backtick-wrapped shell command runs before the prompt reaches the model and injects its output, so the ritual acts on the actual branch state rather than a stale description of it.

One syntax caveat. The ! injection, the $ARGUMENTS placeholder and the frontmatter above are Claude Code’s; Cursor, Copilot, Codex, OpenCode and Pi all ship custom commands with their own file locations and argument conventions, and the slash commands chapter carries the per-tool table. The word “prompt” here means your tool’s custom-command primitive, a different thing from the prompt objects an MCP server exposes; that three-way split takes it apart.

After the willpower transfer, the gate fires with the reliability of a file read, and nobody in the run gets a vote.

Fair objection, and it deserves a number rather than a shrug. You already have a place for persistent instructions: the rules file, your AGENTS.md or CLAUDE.md, reloaded at the start of every session. Why does the ritual need its own primitive when one already exists?

Put the ritual’s constraints there and see what you get. The rules file never gets tired: it is reloaded in full on run 300 exactly as on run 1, so the fatigue schedule from earlier does not apply to it at all. But it is read as one fact among many. When the model works a big diff, “a change is not done until build and test pass” sits in the window next to the task description, the diff itself - and it can be outweighed. Rules are advisory: they describe the world the agent operates in, and they do not drive a sequence.

Price that too, with a second invented figure stamped as such: a flat 6% chance per run that the build-gate rule gets outweighed by everything else in a large diff, constant across the day because the file is constant. The 6% is an illustration of the qualitative point, and the qualitative point is the load-bearing claim - advisory text gets weighed, and weighed sometimes loses. The number just makes it visible on the same table as the other rows.

0.06 x 300 runs = 18.0 expected skipped gates per quarter

Better than 43.2, by more than half. Also not zero, not close to zero, and every one of the 18 is the same invisible failure as before.

The two primitives are for different sentences anyway, and the strongest setup uses both. Constraints true of every task - never push without approval, Conventional Commits, one logical change per branch - belong in the rules file, where every command and every plain prompt inherits them. The ordered procedure specific to shipping belongs in the command. Notice the command above already points back: “honor every constraint in AGENTS.md.” The laws live once, the sequence lives once, and neither is retyped.

If the rules file itself is the thing you’re still missing, write it down once is the piece on that primitive: what belongs in it, and why every tool converged on the same file. This post is about the second primitive, and about the moment a correction outgrows what a rules file can enforce - order.

Rules are weighed; commands are injected. Weighed loses a known number of times; injection is the only rung that reaches zero.

A reader who knows this site’s skills chapter will ask this within a minute, and the answer has a wrinkle. In Claude Code, slash commands and skills largely merged through 2026: every user-invokable skill is reachable as a slash command, so in that one tool the split this post draws is mostly a filing decision. In Codex, OpenCode, Cursor, Copilot and Pi they remain separate primitives.

What survives the merger is the axis that matters for a gate: who fires it. A command runs because you typed its name. A skill runs because the model read its description and decided the situation matched. The foundations chapter’s intent test says it in one line: if you want the agent reaching for it unprompted, you wanted a skill.

For the shipping ritual you want the first, and the reason is the whole argument of this post. Step 3 is a gate, and a gate that runs only when the model judges it relevant has re-entered the run-time-decision business this post exists to exit. The 0.0 row below is a 0.0 because nobody decides anything at run time. Hand the trigger to the model and you have moved the decision from your patience to its judgment - a different transfer than the one recommended here.

A third “why not”: why not wait for the tool to do it for you? Claude Code’s auto-memory and GitHub Copilot’s Memory both now save recurring corrections into durable context on the tool’s own judgment, with no human writing a file. That lane is real, and it is a different problem: auto-memory graduates reversed facts (“we migrated ORMs last quarter”); this post is about an ordered sequence that was never written down at all. Your AGENTS.md is write-once agent memory owns that territory in depth.

For a gate, invocation control is the point: it fires on your keystroke, every time, and never on a judgment call.

Assemble the three rungs. One ritual, one quarter, one column of numbers, three places the correction could live:

Keep this table; the close replays it. The first two rows are arithmetic on invented schedules, stamped as such. The third row is different in kind: 0.0 for any number of runs, not just 300, because omission stopped being a probability at all. There is no schedule to tune and no run at which the step is absent from the prompt.

Before the zero goes to your head, two charges against it. Charge one: the 0.0 counts omissions and nothing else. The next section covers what it doesn’t. Charge two: the zero is bought, not free. A slash command is a commitment to a procedure, and it only pays if the procedure holds still long enough. A ritual you are still redesigning weekly costs more to keep re-encoding than the 43.2 ever cost you.

Same agent, same quarter, same ritual: 43.2, 18.0 or 0.0, decided entirely by where the correction lives.

Two failure modes survive the transfer intact, and pretending otherwise would make this post hype.

The first is drift: the encoded text itself slowly going wrong while the mechanism around it works perfectly. The toy models omission as the only thing that can go wrong, but a command can be wrong in its contents. A /ship that hardcodes npm run build keeps confidently running npm run build for months after the repo moves to a different toolchain. Because the file is read deterministically, it fails deterministically - or worse, silently does the wrong thing on every run. The 0.0 row is a 0.0 for omission; it says nothing about a gate that runs the wrong check on schedule. The mitigations are design habits: keep the volatile parts as arguments or live !-injected commands rather than frozen strings, and push shared constraints down into the rules file so one edit fixes every command at once. A stale command is still cheaper to fix than an unwritten one, but only if somebody notices it went stale - and the determinism that bought you the zero also removed the friction that used to tell you something was wrong.

The second is encoding too early. A ritual still in flux - build-first one week, test-first the next, the diff review wandering between before-commit and after-commit - has not finished being decided. Encode it anyway and you freeze a decision nobody made, spend more time editing the command than you ever spent typing the sentences, and worse: the file makes the process feel settled precisely while it isn’t. The friction of retyping an unsettled ritual is honest signal. Leave anything still in motion in the chat, and encode the parts that have actually stopped moving. Weigh the 43.2 against how many quarters the ritual will survive unchanged; a ritual with one quarter of life left never earns its file back.

The zero buys freedom from omission. Drift and premature encoding are the two bills it does not pay.

One more pass over the table, row by row, because it is the whole argument compressed.

Retyped from memory: 43.2 expected skipped gates a quarter, because the procedure is re-decided at run time by whoever is most tired. In the rules file alone: 18.0, because a fact that is merely weighed loses sometimes. In the command: 0.0, because the step arrives verbatim and skipping it requires an edit.

The tension this post opened on closes here. The agent is broad and fast and starts every session with no knowledge of your process; you are narrow and slow and know exactly what “done” means in this repo. Retyping the ritual made your side of that gap the unreliable part: the human, the careful one, became the component whose output degraded across the day. Encoding the sequence once puts the reliability where the rest of the system already lives - in files - and lets the gap close the same way on every run.

Two hand-forwards; this piece stops at one command on one machine. A /ship file that lives on your laptop has a bus factor of one; packaging the workflow rather than the prompt is the piece on distributing a whole loop to a team.

And the open question this post’s own fix creates: a written command is itself a file that can go stale, exactly the way the rules-file row can, and nothing in the mechanism above catches that. The zero needs a watcher. Testing and validating commands and skills themselves, so the alarm fires before a stale gate does, is a problem this post hands you rather than solves.

Encode the sequence. Then watch the file the way you’d watch anything else that runs unattended - because the moment you stop narrating it is also the moment you stop noticing it’s wrong.

About the numbers. The daily fatigue schedule (2%, 5%, 10%, 20%, 35%) and the rules-file override rate (6%) are invented for traceability, chosen so every figure in this post can be checked with a pencil; no public source measures how often engineers skip a build gate while tired, and none is claimed. Every other number is exact arithmetic on those two invented inputs - 0.72 per day, 43.2 and 18.0 per toy quarter (12 weeks x 5 days x 5 features = 300 runs), and 0.0 by construction - computed two independent ways where possible and re-checked with a script before publishing. The 0.0 row holds for omission only, for any number of runs. The six-step ritual and the /ship command are illustrative of the primitive, not a measured workflow. Swap in your own schedule and the totals move, but typing only reaches zero if the ritual arrives intact on every single run.

For the per-tool mechanics, see Slash commands for parameterized procedures and the command-versus-skill intent test, Rules for the persistent constraints a command leans on, and Skills for the model-invoked alternative and when to reach for it instead.