Lesson 469 of 2116
Building A Custom Slash Command End-To-End
Custom slash commands are how teams encode 'the way we do X.' Building one well takes thinking about the prompt, the context, and the output shape — not just the name.
Lesson map
What this lesson covers
Learning path
The main moves in order
- 1Why most custom commands fail
- 2custom command
- 3command anatomy
- 4context injection
Concept cluster
Terms to connect while reading
Section 1
Why most custom commands fail
Most teams' first custom slash commands are too vague to be useful. The prompt says 'review this code' or 'write tests' without specifying which code, what kind of review, what test framework. The command runs, the model improvises, and nobody's quite sure if the output is good. Useful commands are precise contracts.
The anatomy of a good command
- 1A specific trigger name (`/review-pr`, not `/review`)
- 2A clear scope ('the diff against main,' not 'this code')
- 3An explicit output contract ('Markdown bullet list of issues, severity-tagged')
- 4Context injection ('always include git diff main..HEAD as input')
- 5A boundary on what NOT to do ('skip nits, skip style')
Walkthrough: building /pr-summary
A self-contained PR-summary command. Note the explicit shape of the output and the explicit boundary at the end.
---
name: pr-summary
description: Generate a PR description from the diff against main. Triggers when the user asks for a PR description, summary, or changelog for the current branch.
---
# PR Summary
1. Run `git diff main...HEAD` to get the changes.
2. Run `git log main..HEAD --oneline` to get the commit messages.
3. Group changes into: Features, Fixes, Refactors, Docs, Tests, Other.
4. Write a summary in this format:
## Summary
<2-3 sentences on what shipped and why>
## Changes
- [Feature/Fix/Refactor]: short description
## Test plan
- [ ] [explicit verification steps]
5. Skip noise: lockfile changes, formatting-only commits.
6. End with: `Generated by Claude Code via /pr-summary`.
Do NOT push, commit, or open a PR — just print the summary.Iterate on it like code
- Test the command on three different branches before declaring it done
- Commit the command file; review it like you'd review any team workflow change
- Track when the command misfires; tighten the prompt
- Don't be afraid to delete commands that don't pull their weight
Apply: ship one command tonight
- 1Pick a workflow you do weekly: review, summary, deploy notes, etc.
- 2Write the contract in 4 lines
- 3Build the SKILL.md or command file with explicit steps and output shape
- 4Test on three real cases
- 5Commit and share with the team
Key terms in this lesson
The big idea: a useful slash command is a precise contract — not a vibes prompt with a name.
End-of-lesson quiz
Check what stuck
15 questions · Score saves to your progress.
Tutor
Curious about “Building A Custom Slash Command End-To-End”?
Ask anything about this lesson. I’ll answer using just what you’re reading — short, friendly, grounded.
Progress saved locally in this browser. Sign in to sync across devices.
Related lessons
Keep going
Creators · 9 min
Slash Commands: Built-Ins And Custom
Slash commands are the keyboard shortcuts of Claude Code. The built-ins handle plumbing; the custom ones are where teams encode their workflows.
Creators · 9 min
What Perplexity Is: Search-Augmented LLM, Not A Chatbot
Perplexity is built around the idea that every answer should cite its sources. Treating it like ChatGPT misses the point — and the reliability gap that comes with it.
Creators · 10 min
Spaces: Building Team Knowledge Bases In Perplexity
Spaces are Perplexity's project containers — system prompts, files, and shared chat history. They turn the search engine into a research workspace.