Claude Code Commands, Part 1: Audit Your Prompts Before You Blame the Model

New series: the Claude Code commands that actually change how a session goes, cut into four short parts so nobody has to doom-scroll a 20-minute post. Part 1 starts where most "the model got dumber" takes should start: your own prompts. Every fact below comes from Anthropic's Claude Code docs. The study-buddy app, its files and every example command are ours and purely illustrative. So are the jokes.

TL;DR

• A slash command only counts at the very start of your message. tidy this /simplify is just a sentence. Anything after the command name is its arguments.
• Two worlds: shell commands like claude update run in your terminal; slash commands run inside a Claude Code session.
• /claude-api prompt-audit (v2.1.221+) flags instructions written for older models in your prompts, skills and tool descriptions, then proposes fixes as a diff.
• Pin three things before auditing: a baseline task, a fence around the files in scope, and a check Claude can actually run.
• Judge every hunk, re-run the same task, keep what the check backs up. No check, no verdict. 🫡

Rule zero: the slash goes first

Anthropic's commands reference is blunt: "A command is only recognized at the start of your message." Text after the name becomes its arguments. Type / on an empty prompt to list what's available, and keep typing to filter. Commands sent mid-response queue until the turn ends (a few, like /status and /usage, run right away).

Some entries in that reference are marked Skill. Those are bundled skills: prompt-based instructions Claude follows, which the disableBundledSkills setting turns off. /simplify, /batch and /claude-api are all that kind.

claude --version
claude update

/effort status
/claude-api prompt-audit

Check your version before you start

Here's what each part needs. If something is missing from your / menu, run claude --version before assuming it's broken.

Pick your yardstick before you touch a prompt

Meet the running example for this series: study-buddy, an imaginary Next.js app that turns your class notes into flashcards. It calls the Claude API to write the cards, has a quiz mode with flip animations, and a CLAUDE.md full of all-caps rules from a few model generations ago. We made all of it up.

First, the best-practices line that matters most: "Give Claude a check it can run: tests, a build, a screenshot to compare." Without one, "looks done" is the only signal you get. So write the yardstick down:

BASELINE (study-buddy, illustrative)
Task:   add a "shuffle deck" button to quiz mode
Scope:  src/app/quiz/**, src/components/Deck*.tsx
Check:  npm test -- deck && npm run build
Record: pass/fail, follow-up prompts needed, rules Claude ignored

Run that task once with the prompts as they are and note the follow-ups and ignored rules. That's your before picture. Ask Claude to show evidence (test output, the command and its result) rather than just saying it worked; the docs call that the cure for the trust-then-verify gap.

What /claude-api prompt-audit actually does

/claude-api is a bundled skill that loads Claude API and Managed Agents reference material for your project's language. It switches on by itself when your code imports anthropic or @anthropic-ai/sdk, which study-buddy does, because that's how it writes flashcards. Its workflows start when you type a subcommand: /claude-api <subcommand>.

Today's subcommand is prompt-audit. Per the Skills page, it will "flag instructions written for older models" across your prompts, skills and tool descriptions, then propose the fixes "as a diff". A diff means you read every proposed line before you accept it. Its siblings include migrate, upgrade and cost-optimize (v2.1.247+), plus the build-eval and hillclimb pair waiting in Part 4.

/claude-api prompt-audit

So what would it chew on in study-buddy? Here's the vibe of the file, invented for this post:

# CLAUDE.md (study-buddy, illustrative)
IMPORTANT!!! You are a world-class senior engineer.
ALWAYS think step by step before EVERY answer.
NEVER EVER add a library that isn't installed. I mean it.
Cards must be JSON. ONLY JSON. NO OTHER TEXT. ONLY JSON.
Run `npm test -- deck` after touching src/components/Deck*.

And a diff in the shape an audit could propose. Also illustrative, not real tool output:

-IMPORTANT!!! You are a world-class senior engineer.
-ALWAYS think step by step before EVERY answer.
-NEVER EVER add a library that isn't installed. I mean it.
+Don't add dependencies without asking.
-Cards must be JSON. ONLY JSON. NO OTHER TEXT. ONLY JSON.
+Card output must match the schema in src/lib/cardSchema.ts.
 Run `npm test -- deck` after touching src/components/Deck*.

Judge every hunk, not the vibe

The best-practices page gives the test for each line: "Would removing this cause Claude to make mistakes?" It also warns that bloated CLAUDE.md files cause Claude to ignore instructions, so pruning isn't just aesthetics:

On our made-up file: the test command survives untouched, because it's a real project fact. The "no new libraries" shout becomes one calm rule, because the constraint is real even if the volume isn't. The JSON chant now points at an actual schema file instead of repeating itself. The "world-class engineer" line goes; it says nothing about the project.

Re-run the same task, then keep or revert

Start a fresh session (the docs recommend /clear between unrelated tasks anyway) and run the exact baseline task with the exact same check. Then compare: did it pass, how many follow-ups, any rules still ignored?

Equal or better with a shorter file? Keep it. Worse? Revert the unsure hunks with git. One run is a tiny sample, so if it's close, run it a couple more times. The docs say to test CLAUDE.md changes by watching how Claude behaves; this loop is that, written down. Part 4 grows it into a real eval.

How we do it at ByteVancer

This blog runs on the same energy: a research file of sourced facts, a builder agent, a scratch build, then a separate reviewer agent that fact-checks the draft against the research file before we commit, deploy and run live checks. The rule holding it together: a check only counts if it actually ran, with its output in the transcript.

The whole series

1. Part 1: Audit your prompts with /claude-api prompt-audit (this post)
2. Part 2: /effort, /simplify and /frontend-design
3. Part 3: ultracode, /batch, /compact and /rewind
4. Part 4: build-eval and hillclimb for your Claude app

Next up: Part 2 tidies study-buddy's flip-card component with /simplify, sets /effort on purpose, and builds the app a landing page with /frontend-design.