Slash Commands, Custom Skills and Context Management

Why Slash Commands Matter

Claude Code's slash commands are shortcuts to actions that would otherwise require multiple steps or careful phrasing. The difference between knowing them and not knowing them is the difference between a developer who feels in control of the tool and one who feels like they are fighting it.

There are two categories: built-in commands that ship with Claude Code, and custom commands you create for your own workflows.

The Built-in Commands You Will Use Every Day

Understanding /compact — The Most Underused Command

Every Claude Code session has a context window — a limit on how much conversation history, code, and output Claude can hold in memory at once. In a long session, this fills up. When it does, Claude starts forgetting earlier parts of the conversation and the quality of its responses degrades noticeably.

/compact solves this by summarising the conversation into a much shorter form. It preserves what matters:

• All instructions from your CLAUDE.md files
• The current task and your progress toward it
• Recent edits and decisions
• Key context about the codebase Claude has discovered

What it discards: early exploratory messages, repeated attempts, long tool outputs that are no longer relevant. That is fine — those things have served their purpose.

When to run /compact:

• Every 50–100 messages in a long session, proactively
• After an exploration phase, before a focused implementation phase
• When Claude starts repeating itself or giving lower-quality answers
• Before any major new task in the same session

Think of it as clearing the whiteboard while keeping the important notes.

Creating Custom Slash Commands

Custom commands are markdown files stored in .claude/commands/ in your project directory, or in ~/.claude/commands/ for commands available across all projects.

A simple deployment command

Create .claude/commands/deploy.md:

---
name: deploy
description: Deploy the application to staging
---

Deploy the application to staging:
1. Run the test suite: npm test
2. If any tests fail, stop and report the failures — do not proceed
3. Build the application: npm run build
4. Check the build output for errors
5. If the build is clean, run: ./scripts/deploy-staging.sh
6. Tail the deployment log for 30 seconds and report success or failure

Invoke with /deploy. Claude follows the steps exactly, stops if tests fail, and reports the result.

A command with arguments: creating a React component

Create .claude/commands/new-component.md:

---
name: new-component
description: Scaffold a new React component with styles and exports
arguments: [name]
---

Create a new React component named $name:
1. Read src/components/Button/Button.tsx as a template to understand our patterns
2. Create src/components/$name/$name.tsx using the same structure
3. Create src/components/$name/$name.module.css with a starter class
4. Add an export to src/components/index.ts
5. Show the user all created files and confirm the export was added correctly

Invoke with /new-component UserAvatar. Claude reads your existing component as a template and creates the new one following the same patterns. The $name placeholder is replaced with your argument.

A code quality check command

Create .claude/commands/check.md:

---
name: check
description: Run all quality checks and report results
---

Run a full quality check on the current working tree:
1. Run TypeScript type checking: npx tsc --noEmit
2. Run ESLint: npm run lint
3. Run the test suite: npm test
4. Report each check as PASS or FAIL with details on any failures
5. If all checks pass, confirm the code is ready to commit

Invoke with /check before any commit. One command runs your entire quality gate.

Advanced: Using Dynamic Context in Commands

Commands can include dynamic content using the ! prefix to run shell commands inline:

---
name: pr-review
description: Review the current pull request
---

Review the open pull request:

Current branch status:
!`git log main..HEAD --oneline`

Files changed:
!`git diff main --name-only`

Review for:
1. Security vulnerabilities
2. Performance issues (especially N+1 queries)
3. Missing test coverage
4. Code style inconsistencies
5. Anything that could break in production

Provide a summary with PASS / NEEDS WORK / FAIL verdict.

The !`command` syntax runs the shell command and inserts its output into the prompt when the command is invoked. This means the review always uses the actual current state of your branch.

The /ultrareview Command

/ultrareview is different from the other commands — it does not run locally. It launches a multi-agent review in Anthropic's cloud, where several specialised Claude instances review your code simultaneously:

• One reviews for security vulnerabilities
• One reviews for performance issues and architectural concerns
• One reviews for code correctness and logic errors
• One reviews for test coverage gaps

The results are combined into a single comprehensive review report.

How to use it:

• /ultrareview — Reviews the current branch (compares to main)
• /ultrareview 123 — Reviews GitHub PR #123 (requires a GitHub remote)

Requires a git repository. For the PR number form, you need a connected GitHub remote. This command is billed separately — it consumes more Claude usage than a regular session. Use it for significant changes before merging into main.

Organising Commands for a Team

A well-organised team ends up with a commands directory that encodes their entire workflow:

.claude/commands/
├── deploy.md           # /deploy — deploy to staging
├── deploy-prod.md      # /deploy-prod — deploy to production (with extra checks)
├── new-component.md    # /new-component [name] — scaffold a React component
├── new-api.md          # /new-api [resource] — scaffold a REST API resource
├── check.md            # /check — full quality gate
├── migrate.md          # /migrate [env] — run database migrations
└── security-audit.md   # /security-audit — check for common vulnerabilities

New team members run /help and immediately see the team's entire workflow described in plain English. They do not need to read the deployment runbook or ask a senior developer how to scaffold a new component. The commands are the documentation.