Custom Commands and Slash Commands

Slash commands are shortcuts inside the Claude Code prompt. Built-in ones handle common tasks. Custom ones let you encode your team's recurring QA workflows as reusable, version-controlled commands that any engineer can run with a single word.

Built-in slash commands

These are available in every Claude Code session:

• /init — generate a CLAUDE.md draft for the current project
• /clear — reset conversation history without ending the session
• /cost — see token usage for the current session
• /model — switch between Claude models (Sonnet, Opus, Haiku)
• /permissions — view and edit the current permission settings
• /mcp — list and manage connected MCP servers
• /help — list all available commands

These are the ones worth learning on day one. /cost is particularly useful when you are managing token budgets across a team.

Custom slash commands

Create your own commands in .claude/commands/. Each command is a Markdown file. Its filename becomes the slash command name.

Create .claude/commands/run-smoke.md:

Run the smoke test suite and report results.
 
1. Run: npm run test:smoke
2. If any tests fail, summarise the first three failures including file name and error message
3. Save the full log to logs/smoke-$(date +%Y%m%d-%H%M).log (create the logs/ directory if needed)
4. Report: how many passed, how many failed, total duration

Now in any Claude Code session: /run-smoke triggers this workflow. Claude executes the steps in order, reads the output, and delivers the summary.

QA command library worth building

/new-test — guided test generation:

Guide me through creating a new Playwright test.
 
Ask me:
1. Which feature or page does this test cover?
2. What scenarios should it test? (list at least 3)
3. Is there an existing test I should follow as a style reference?
 
Once I've answered, generate the test file and save it to the correct location.
Follow the conventions in CLAUDE.md.

/triage-failures — CI failure analysis:

Analyse the most recent CI test failures.
 
1. Read the latest test results from test-results/ or ask me to paste the CI log
2. Group failures by likely root cause (selector breakage, timeout, state pollution, environment issue)
3. For each group, identify the specific files affected
4. Prioritise by: frequency × business importance
5. Suggest fixes for the top 3

/refactor-pom — Page Object cleanup:

Refactor the Page Object I specify to meet current standards.
 
Ask me which POM to refactor. Then:
1. Read the file
2. Identify: methods that should be broken out, assertions that should be removed,
   outdated locator strategies, missing TypeScript types
3. Show me the planned changes before applying them
4. Apply after my approval

/pre-release — release validation checklist:

Run the pre-release validation checklist.
 
1. Run the smoke suite: npm run test:smoke
2. Check for any tests with .skip or .only (these must not be in main)
3. Check for any console.log statements in test files
4. Report: smoke results, any .only/.skip found, any debug logs found
5. Give a go/no-go recommendation

Commands can take arguments

When you type /new-test login, Claude Code receives "login" as context and uses it:

Guide me through creating a new test for the feature: $ARGUMENTS
 
[rest of the command...]

The $ARGUMENTS placeholder gets replaced with whatever follows the command name. This makes commands flexible without requiring a new file for each variant.

Sharing commands with the team

Commit .claude/commands/ to your version control repository. Every engineer who checks out the project gets access to the full command library immediately. Document the available commands in your project's README so people know they exist.

This is the leverage point: one person writes a good /triage-failures command, and the entire team benefits from it every sprint without anyone having to remember the full prompt.

⚠️ Common Mistakes

• Commands that are too broad. "Fix everything" is not a useful command. Commands that work well are specific about inputs, steps, and outputs. "Run smoke suite, summarise failures, save log" is a command. "Make the tests better" is not.
• Not committing the commands directory. Commands that live only on one machine help only one person. Commit .claude/commands/ and treat it as team infrastructure.
• Forgetting to update commands when workflows change. A /pre-release command that checks for the old CI script name silently fails to check what it should. Review commands when your project's tooling changes.

🎯 Practice Task

Build one custom command for a workflow you repeat. 20 minutes.

1. Think of a multi-step QA task you have typed out as a Claude Code prompt more than twice — a test run, a triage sequence, a reporting task.
2. Create .claude/commands/ in your project if it doesn't exist.
3. Write a command file for that task. Be specific about each step and the expected output.
4. Test it in a Claude Code session.
5. Commit the file.

The next lesson adds another layer of power: MCP servers, which extend Claude Code's reach to browsers, databases, GitHub, and any other tool your QA workflow touches.