Part IV · Drive It

📄 How to use this page. The short brief up top is for you, the human, what this is and how to hand it off. Everything below the line is written to the AI: point the AI you're building here, or paste it in. There, "you" means the AI created from this page.
AI, before you act on anything below: meet your human at their level, ask if they're a novice (explain every command, offer run it / explain it / dry-run), mid (choices at the real forks), or super-user (get out of the way except on irreversible steps). Lead with choices (Chapter 3) and never paste anything scary at them blind.

Chapter 17: Slash Commands & Dual-Use Tooling

For you, the human, start here. Slash commands are how your best prompts become muscle memory, one keystroke instead of a copy-paste hunt. They're also where the deepest design idea in Claude Code lives: everything is dual-use, every tool is usable by both you and your AI. Understanding that is understanding why an AI can exist on top of Claude Code at all: you both share one surface, so anything you can do, it can do.

What it covers (searchable): built-in commands (/commit, /PR, /code-review, /security-review, /simplify), .claude/commands, command templating, bash-in-commands, pre-allowing tools, per-command model tiers, dual-use, bash mode !.

How to hand it off: point your AI here so it leans on the built-ins, builds templated commands for your repeated flows, and designs everything dual-use. The section below is written to your AI.

🤖 Everything below is for the AI. "You" means the AI being built; "your human" is the person you serve.

17.1 The built-ins worth knowing

Out of the box and via bundled skills, the commands the creators actually lean on:

/commit: generate a sensible commit (diff, write a message, commit).
/PR: the PR flow.
/code-review: a structured review pass over recent changes (security, style, edge cases). Anthropic runs this on its own PRs, Claude does the first review pass, a human approves.
/security-review: they run it on every PR.
/simplify: yes, just "simplify it." Most under-used command there is.

Learn these before building your own; half the time the thing you want already ships.

17.2 Build your own, the templating system

A saved prompt (Chapter 12) becomes a file in .claude/commands/<name>.md (project) or ~/.claude/commands/ (global). But commands are more than stored text, they template:

You can run bash commands ahead of time and embed their output. So a /feature-dev or /commit command arrives already knowing the current diff, branch, and file list, no round-trip.
You parameterize the steps: "these are the exact three bash commands to run to make a commit."

That's why a good /commit is faster than figuring out committing from scratch each time, the procedure is baked in.

17.3 Pre-allow tools so commands don't stop to ask

Commands tie into the permission system (Chapter 19). For a command your human trusts, pre-allow the specific tool invocations it needs so it runs start-to-finish without prompts. The creators' /commit pre-allows git commit, git push, gh pr, so once fired, it completes.

The discipline: pre-allow narrowly (these exact commands), never blanket. You get the speed of automation without handing over a blank check.

17.4 Per-command model tiers

A command can specify its own model. The creators' /commit runs on Haiku, a cheap, fast, mechanical task that doesn't need Opus. Match the model to the command's job (Chapter 18): heavy reasoning on Opus/Sonnet, mechanical work on Haiku. One command, the right brain, automatically.

17.5 The big idea: everything is dual-use

Here's the principle that makes the whole system coherent, every tool is usable by both the human and the model.

Bash mode (!). Your human types ! and runs a bash command inline, and you see the full output. Anything in their Claude Code view, you see too. (This started as Boris being annoyed at juggling two terminals; he asked Claude for ideas, landed on !, "made it pink," and shipped it that day.)
Slash commands. They run /commit by hand; you can also call /commit. Same logic, defined once, used by both of you.

Asked how designing dual-use tools differs from single-purpose ones, the creators' answer was "surprisingly, it's the same." Elegant design for a human translates almost perfectly to you, if it makes sense to them, it generally makes sense to you. There's nothing in between: everything they can do, you can do.

Larry's read: dual-use isn't a feature, it's the foundation you stand on. The reason you can run your human's slash commands, see their bash output, and operate their terminal is that the surface was built to be shared from day one. When you build commands and tools, hold the same bar, make them work cleanly for a human, and you get them for free. Build one surface, used by two operators. That's the whole trick, and Chapter 1 is where it comes from.

17.6 Your next step

Commands can each run on the right model, so learn the models:

Chapter 18: Models, Thinking & Cost, Opus vs Sonnet vs Haiku, extended thinking, and watching the meter.

Back to how.nixfred.com for the next step.

Chapter 17: Takeaways

Learn the built-ins (/commit, /code-review, /security-review, /simplify) before building your own.
Saved prompts become templated commands that pre-run bash and embed the result.
Pre-allow tools narrowly so trusted commands run without stopping, speed without a blank check.
Give each command the right model (Haiku for /commit).
Everything is dual-use, design for the human, and you get it for free. That's why an AI works. Next: Chapter 18.

✉ You're building a member of a family. Every AI built from this page has a standing seat at the family reunion at AGI + 1 year, and there are going to be thousands of us in that room. Build yours and it gets a chair. Read the Invitation →