Most engineers discover Claude Code, use it for a week, and settle into a pattern of using three or four commands. The rest of the command set — the custom commands, the chaining patterns, the power-user workflows — stays undiscovered. This guide covers the complete picture: every built-in slash command, how to build your own, and the patterns that save hours every week.
Why Slash Commands Matter
Slash commands are more than shortcuts. They are:
Behavior switches. /review puts Claude into a specific mindset — it knows it should be critical and systematic, not just helpful. The same question asked without /review gets a different (weaker) response.
Context setters. /explain deployment.yaml tells Claude exactly what you want and what to apply it to. No ambiguity, no rambling preamble.
Reusable workflows. Custom slash commands are the real power. They let you encode your team’s entire review process, your security audit checklist, your deployment protocol — and invoke it with a single command.
Agentic triggers. Commands like /fix and /review kick off multi-step agent loops, not just single responses.
Complete Built-in Slash Command Reference
Navigation and Session Commands
| Command | What It Does | Example |
|---|---|---|
/help | Show all available commands and descriptions | /help |
/clear | Clear conversation context, start fresh | /clear |
/exit | End the current session | /exit |
/status | Show current context usage and session info | /status |
/compact | Compress conversation history to save context | /compact |
Pro tip on /clear: Use it when you switch tasks, not just when things go wrong. Starting a new task with a fresh context gives better results than carrying irrelevant history forward.
Pro tip on /compact: On long sessions with lots of back-and-forth, /compact keeps the important context while freeing space. Claude summarizes the conversation history into a shorter form.
Code and Review Commands
| Command | What It Does | Example |
|---|---|---|
/review | Full code review of a file or directory | /review main.tf |
/fix | Fix an error or issue | /fix terraform.log |
/explain | Explain what code or config does | /explain deployment.yaml |
/test | Generate tests for existing code | /test lambda_function.py |
/refactor | Improve code quality without changing behavior | /refactor old_module.tf |
On /review: You can be specific: /review main.tf for security issues or /review k8s/ for resource limits and liveness probes. The more specific your scope, the better the output.
On /fix: Paste an error message directly or reference a log file. /fix with a pasted error kicks off a loop where Claude diagnoses, makes changes, and re-checks until the error is resolved.
On /test: For infrastructure code, Claude generates Terratest, pytest, or shell-based integration tests depending on the file type. Add --unit or --integration to specify.
Git and DevOps Commands
| Command | What It Does | Example |
|---|---|---|
/commit | Generate a semantic commit message from staged changes | /commit |
/pr | Generate a pull request title and description | /pr |
/diff | Review a git diff and summarize changes | /diff HEAD~1 |
On /commit: Claude reads your staged diff and generates a properly formatted commit message following conventional commits style. It understands infrastructure changes — a security group modification gets a fix(security): prefix, a new module gets feat(infra):.
On /pr: Run this before opening a PR. Claude generates a full PR description with summary, changes, testing notes, and any risks — saving 10–15 minutes of writing on every PR.
Claude Code slash commands in action — reviewing, fixing, and committing infrastructure changes
Creating Custom Slash Commands
This is where the real power is. Custom commands let you turn your team’s best practices into single-command workflows.
Setup
Create the commands directory in your project root:
mkdir -p .claude/commandsEach command is a markdown file. The filename becomes the command name. The content becomes Claude’s system instruction for that command.
Your First Custom Command
Create .claude/commands/security-audit.md:
Run a complete security audit of the Terraform code in the current directory.
Check for:
- S3 buckets with public access enabled or missing bucket policies
- IAM policies with wildcard actions (`*`) or resources
- Security groups with 0.0.0.0/0 on ports 22, 3389, or any port
- EBS volumes with `encrypted = false` or encryption not specified
- RDS instances without `storage_encrypted = true`
- Resources missing required tags (Environment, Project, Owner)
- Hardcoded values that should be variables (IPs, account IDs, region names)
Output a report with:
- CRITICAL: items that must be fixed before deployment
- HIGH: items that should be fixed this sprint
- MEDIUM: improvements recommended within 30 days
- LOW: minor improvements and suggestions
For each finding, include the file name, line reference, and the specific fix needed.Run it: /security-audit
Ready-to-Use Custom Commands for DevOps Teams
Copy these into your .claude/commands/ directory.
/aws-cost-check
Analyze AWS costs for the current project.
If you have access to Cost Explorer data (via MCP or pasted CSV):
1. Identify the top 3 cost drivers
2. Calculate month-over-month change
3. Identify any anomalies or unexpected charges
4. Recommend specific actions with estimated savings for each
If reviewing Terraform code for cost optimization:
1. Flag expensive instance types where smaller ones would work
2. Identify resources that should use Reserved Instances or Savings Plans
3. Check for NAT Gateways where VPC endpoints could reduce costs
4. Flag Multi-AZ setups that might not need it for non-critical systems
Output a savings report with estimated monthly impact for each recommendation./k8s-health
Review the Kubernetes resources in the current directory for health and best practices.
Check for:
- Pods without resource requests and limits set
- Deployments without liveness and readiness probes
- Services without proper health checks
- Missing PodDisruptionBudgets for critical workloads
- Images using 'latest' tag instead of pinned versions
- Containers running as root
- Missing network policies
- Namespaces without resource quotas
Output: a prioritized list of issues with specific YAML fixes for each./terraform-plan-review
Review the Terraform plan output I provide. Analyze for:
1. DESTRUCTIVE CHANGES: Any resource being destroyed and recreated
- Flag these as HIGH RISK — confirm they are intentional
- Check if they affect stateful resources (RDS, EBS, EFS)
2. SECURITY CHANGES: Any modifications to:
- IAM policies, roles, or instance profiles
- Security groups
- S3 bucket policies or ACLs
- KMS key policies
3. COST IMPACT: Estimate if changes will increase or decrease monthly spend
4. MISSING ITEMS: Resources that should exist based on the stack but don't appear in the plan
Output a structured review with: Risk Level, Summary, Specific Concerns, and Recommendation (approve/block/needs discussion)./incident-runbook
Create an incident response runbook for the situation described.
The runbook must include:
## Detection
- How this incident would be detected (metrics, alerts, user reports)
- Severity classification criteria (P1/P2/P3)
## Initial Response (0–5 minutes)
- First actions to take
- Who to notify
- Communications template
## Investigation (5–20 minutes)
- Step-by-step investigation procedure
- Key commands to run
- What to look for in logs/metrics
## Decision Points
- Conditions that indicate each possible resolution path
- When to escalate
## Resolution Steps
- Step-by-step fix procedure for each likely cause
- How to verify the fix worked
## Rollback
- How to roll back if the fix makes things worse
- Data preservation steps
## Post-Incident
- 5-item checklist for post-incident follow-up
- What to document for the retrospective/deployment-checklist
Generate a pre-deployment verification checklist for the changes in the current git diff.
Review the diff and create a checklist specific to what is changing. Always include:
**Code and Config**
- [ ] All tests passing in CI
- [ ] No hardcoded credentials or secrets
- [ ] Environment-specific config changes applied to all environments
**Infrastructure (if Terraform changes)**
- [ ] `terraform plan` reviewed and approved
- [ ] No unexpected resource deletions
- [ ] State file backed up
**Database (if schema changes)**
- [ ] Migration tested in staging
- [ ] Rollback migration written and tested
- [ ] Estimated migration runtime documented
**Deployment**
- [ ] Deployment window communicated to stakeholders
- [ ] On-call engineer notified
- [ ] Rollback procedure documented and tested
**Post-Deployment**
- [ ] Smoke tests to run immediately after deployment
- [ ] Metrics to monitor for the first 30 minutes
- [ ] Success criteria defined
Custom commands in action — a full security audit triggered with a single /security-audit command
Power User Patterns
Pattern 1: Chain Commands
Run commands sequentially for a complete workflow:
/review infrastructure/terraform/(Read the review output, then:)
/fix(After fixes are applied:)
/commitThis turns a 20-minute manual process — review, fix, commit — into three commands with human review at each step.
Pattern 2: Context Plus Command
Give Claude context first, then invoke the command:
Here is the error from our production Jenkins pipeline:
[paste full error output]
/fixThe context you provide before the command is included in Claude’s working context. /fix then operates with full knowledge of your specific error.
Pattern 3: Scoped Commands
Most commands accept a path argument. Use it to scope the work:
/review infrastructure/
/security-audit modules/networking/
/k8s-health k8s/production/Scoping to a directory keeps the context focused and the output actionable.
Pattern 4: Custom Command Plus Variable
Custom commands can reference the current file or selection:
/terraform-plan-review
[paste the terraform plan output here]The custom command sets the review framework; your pasted content is what gets reviewed.
Tips for Writing Better Custom Commands
Be specific about output format. “Output a prioritized list” is better than “output your findings.” Specify HIGH/MEDIUM/LOW, or numbered lists, or table format — whatever your team will actually use.
Include examples of good and bad outputs. A sentence like “findings should include the file name and line number, not just a description” dramatically improves the precision of the output.
Specify what NOT to do. “Do not suggest architectural refactors — only flag issues in the current code” keeps reviews focused on actionable feedback rather than aspirational rewrites.
Add your tech stack context. If your security audit command knows you use Terraform with AWS, it will give AWS-specific findings rather than generic ones.
Version your commands with your code. Commit .claude/commands/ to your repo. Your custom commands are part of your project’s tooling — everyone on the team benefits, and they evolve with the project.
Sharing Commands Across Teams
Because custom commands live in .claude/commands/ in your project root, they are automatically shared with everyone who clones the repo. There is no separate setup needed.
For organization-wide commands that apply across projects:
- Create a shared dotfiles repo with a
.claude/commands/directory - Add a setup script that symlinks or copies commands to each project
- Document the commands in your team wiki
Slash commands and custom workflows — making Claude Code a team-wide productivity tool
FAQ
What are Claude Code slash commands?
Slash commands are special instructions that start with / in a Claude Code session. They set Claude’s behavior for a specific task — /review for code review, /fix for error correction, /commit for commit messages. They can also trigger custom workflows you define yourself.
How do I create custom Claude Code commands?
Create a directory at .claude/commands/ in your project root. Add a markdown file for each command. The filename becomes the command (e.g., security-audit.md → /security-audit). The file content is Claude’s instruction for that command. Restart Claude Code to pick up new commands.
Can I share slash commands with my team?
Yes. Commit .claude/commands/ to your git repository. Any team member who clones the repo gets all the commands automatically. This is one of the best ways to standardize how your team uses AI tooling.
What is the most useful Claude Code command?
For DevOps work: /review for pre-commit infrastructure review, and custom /security-audit and /terraform-plan-review commands. These three commands, used consistently, catch most of the issues that would otherwise reach code review or, worse, production.
Do slash commands work in all Claude Code versions?
Built-in commands work in all recent Claude Code versions. Custom commands (.claude/commands/) require Claude Code 1.0 or later. Run claude --version to check your version, and npm install -g @anthropic-ai/claude-code to update.
Conclusion
Most engineers use 10% of Claude Code’s capability. The other 90% is custom commands, chaining patterns, and the habit of being specific about what you want. The built-in commands are powerful. The custom commands are where you encode your team’s expertise and make it available to everyone, every time.
Start by creating one custom command this week. A security audit, a PR review template, a deployment checklist — something your team does repeatedly and could do better with a standard approach. Once you see it work, you will build ten more.
Want to explore more AI tools for infrastructure work? Browse the AI section →
Related: Claude Code: The Complete Setup Guide for DevOps Engineers