Foundations · Lesson 12 — Slash commands you'll actually use
F12Foundations
Foundations · Lesson 12● live

Slash commands you’ll actually use

Six worth memorizing on day one. Plus how to write your own.

10 min read · 15 min applyno prereq

What slash commands are

A slash command is a short, exact string you type at the start of a message that fires a built-in or project-defined workflow. /help lists what’s available. /compact summarizes the conversation. /ship (custom) runs an end-to-end ship workflow.

Two categories. Built-ins ship with Claude Code and work in every project. Custom commands are markdown files in .claude/commands/ that you (or your team) wrote. Custom commands are projectful — what works in your QC repo doesn’t work in your MHG vault unless you’ve also defined it there.

The leverage is compression. /ship in my Website repo runs tests, builds the diff summary, bumps version, updates changelog, drafts a commit message, and awaits approval before push. Eight steps, one slash. The cost of writing the command was 20 minutes. It’s fired ~80 times.

Most operators only use 2-3 slash commands and miss the rest. This lesson covers the six worth installing in muscle memory on day one.

The six worth memorizing

CommandWhat it doesWhen you’ll reach for it
/helpLists every command available in this project — built-in and custom.First minute of any new project. Once a month after that as a re-orientation.
/compactSummarizes the conversation, frees context, preserves intent. Reversible damage.Long sessions where context is getting heavy. Default to this — almost always what you actually want.
/clearWipes conversation. Starts fresh. Irreversible.Genuinely starting a new task with no prior context. Rare. If unsure, use /compact.
/initBootstraps a CLAUDE.md for this project by scanning the codebase.First day in any new repo. Don’t hand-write CLAUDE.md from scratch — let /init draft, then trim.
/reviewCode review of pending changes against the base branch.Before you ship. Catches structural issues, missing tests, sloppy edits.
/security-reviewSecurity audit of pending changes — secrets, SQL injection, auth bypass, etc.Before you ship anything that touches auth, money, secrets, or user data.

Beyond the six: every project has its own custom commands. In my QC repo, /qc-daily refreshes the Golden Board kanban with the day’s progress. In my Website repo, /ship runs the eight-step push workflow. Different projects, different verbs.

Run /help on day one in any new project. The custom commands are the local idioms. Knowing them saves 30+ minutes of guessing what the team’s patterns are.

Three slash-command failure patterns

The mistakes that turn slash commands from leverage into footguns.

01

Inventing slash commands

claim looks like"/refactor this for me" — operator types this expecting magic.
what’s missingSlash commands are exact strings. /refactor isn't a built-in and the agent reads it as plain text. The operator wonders why nothing happened.
the moveSlash commands you didn't write yourself only fire if they exist. Use /help to list what's actually available before relying on a guess.
02

Custom commands that go stale

claim looks likeOperator wrote /qc-daily six months ago. Now half its references are broken paths.
what’s missingCustom commands are markdown files. They drift like any other doc. References to old folder structures or deprecated agents quietly produce wrong outputs.
the moveQuarterly: list custom commands, run each one, check the output. Delete or update anything that references stale paths or roles.
03

Using /clear when you meant /compact

claim looks likeOperator runs /clear mid-session to free context, loses everything they were working on.
what’s missing/clear nukes the conversation; /compact summarizes and continues. The two look similar, do opposite things. Recovery from /clear is sometimes impossible.
the moveMemorize: /clear ends the session, /compact preserves it. If unsure, /compact — it's almost always what you actually want.

The fix in all three: treat slash commands as an inventory, not a wish. Run /help. Audit custom commands quarterly. Memorize the difference between /clear and /compact.

The custom-command audit

The quarterly check that keeps custom commands from going stale.

Run quarterly on any project with 2+ custom commands
Audit my custom slash commands.

For each file in .claude/commands/ (and any project-local
slash command definitions):
1. When was it last modified?
2. Does it reference any folder paths, agent names, or
   files that no longer exist?
3. When was it last fired (best estimate from session
   history)?
4. Does its description match what it actually does?

Output a table with columns:
slug | last-modified | last-fired | health (green/yellow/red) | recommendation (keep/update/delete)

Health rated by reference validity, last-fired recency, and description accuracy.

Most operators’ first audit deletes 30-50% of their custom commands. The deleted ones were either redundant with built-ins, referenced paths that have moved, or were never fired more than twice.

Annotated transcript

Three slash commands inside a single working session: /help, /compact, /ship. Watch how each one compresses what would otherwise be 5-10 manual steps.

Three slash commands in one session

/help (orient), /compact (free context), /ship (push). Total elapsed: ~3 minutes for what would be ~25 minutes of manual workflow.

  1. operator

    /help

  2. agent

    Available commands in this session:

    Built-in:
    - /clear — wipe conversation context (irreversible)
    - /compact — summarize and continue (preserves intent, frees tokens)
    - /help — this list
    - /init — bootstrap a CLAUDE.md for this project
    - /review — code review of pending changes
    - /security-review — security audit of pending changes

    Custom (project-local):
    - /qc-daily — refresh the Golden Board with today's QC progress
    - /ship — ship workflow: tests → diff review → commit → push → PR
    - /retro — weekly engineering retrospective
    - /investigate — systematic root-cause debugging

    Skill triggers (33 available):
    - /update-config, /codex, /design-review, /qa, /freeze, /ship, /careful, /guard, ... (truncated — type /skill-list for full)

  3. operator

    Two-thirds through this session, context is getting heavy. Want to keep going. /compact

  4. agent

    Compacting conversation. Preserving: current task (Foundations lesson 12 draft), key decisions made (six-command list locked, Parley ASR example moved to lesson 11), open threads (need to write transcript section).

    Discarding: full text of earlier-resolved questions, three abandoned drafts, repeated tool-list dumps.

    Resulting context: ~12k tokens (down from ~78k). Continue.

  5. operator

    About to push this work. /ship

  6. agent

    Running ship workflow:

    1. Detected base branch: main
    2. Running tests... 47 passed, 0 failed
    3. Diff review: 9 files changed, +1,847 lines (lessons.ts +56, 9 new lesson pages)
    4. Bumping VERSION: 0.4.2 → 0.4.3
    5. Updating CHANGELOG with the 9 new Foundations lessons
    6. Drafting commit message
    7. Awaiting your review of the commit message before push.

    Proposed commit message:

    feat(labs): ship Foundations lessons 09-17 (model routing through tool permissions)
    
    Nine new Foundations lessons completing the entry-tier curriculum.

Prompt kit

Three prompts: list what’s available, audit what’s stale, bootstrap what’s missing.

List what's actually available
Run: /help

Then: list any custom slash commands defined in this project under
.claude/commands/ along with their one-line descriptions.

If a command isn't in the list, it doesn't exist — don't try to
invoke it.
The custom-command audit
Audit my custom slash commands.

For each file in .claude/commands/ (and any project-local
slash command definitions):
1. When was it last modified?
2. Does it reference any folder paths, agent names, or
   files that no longer exist?
3. When was it last fired (best estimate from session
   history)?
4. Does its description match what it actually does?

Output a table with columns:
slug | last-modified | last-fired | health (green/yellow/red) | recommendation (keep/update/delete)
Bootstrap a new custom command
I want to create a custom slash command for this project.

Goal: <describe the workflow you want to invoke>

Walk me through:
1. What the trigger phrase should be (kebab-case, short)
2. What inputs it should accept (if any)
3. The 3-7 sequential steps it runs
4. The expected output (file paths, format)
5. Anti-patterns — what it should NOT do

Draft the command file at .claude/commands/<slug>.md in standard
format. Don't invoke it yet — show me the file first.

Apply this — install the six and audit your custom

15-minute exercise. Builds slash-command muscle memory. Saves hours over the next month.

Master your slash commands

Each step takes 2-5 minutes. Progress saves automatically.

0/5
  1. 01Run /help in your current project. Read every line.You'll find at least one custom command you didn't know existed.
  2. 02Memorize the six built-ins: /help, /clear, /compact, /init, /review, /security-review.These work in every project. The custom ones differ per project.
  3. 03Use /compact at the next long session. Compare context size before and after.If you've been hesitating to /compact because you're worried about losing state — try it once. The summary preserves what matters.
  4. 04Run the custom-command audit on any project where you've written 2+ custom commands.Half of them are probably stale. Update or delete.
  5. 05Pick one repeating workflow and write a custom slash command for it.Use the bootstrap prompt. Aim for 30-50 lines of definition.
Foundations tier · what's next

After this lesson