Build Your Own Slash Commands: The Prompt Templates Behind the Magic

intermediate 20 min 📋 Copy-paste ready

Sources not yet verified

slash-commandspromptstemplatesdiyclaude-codeworkflow

Scenario

Context: You've seen /specify, /plan, and /session-start commands but want to understand how they work and customize them for your team

Goal: Learn that slash commands are just reusable prompt templates, and build your own from scratch

Anti-pattern: Treating AI tools as black boxes instead of understanding the prompts underneath

Tools: Claude CodeGitHub CopilotCursor

Conversation

The Secret: It's Just Prompts

Every fancy slash command you've seen - /specify, /plan, /session-start - is just a Markdown file containing a reusable prompt. There's no magic. Understanding this lets you:

1. Customize existing commands for your team's workflow
2. Create entirely new commands for repetitive tasks
3. Share prompt templates across your organization

Where Commands Live

Location	Scope	Command Prefix
.claude/commands/	Project (shared via git)	/project:
~/.claude/commands/	Personal (your machine only)	/user:
.github/prompts/	GitHub Copilot	Varies by tool

---

Building a /specify Command from Scratch

Let's create the /specify command that generates Product Requirements Documents.

👤 You

I want to create a /specify command for my team. Where do I start?

Understanding the file structure is the first step.

🤖 AI

Create a Markdown file at .claude/commands/specify.md. The filename becomes the command name:

mkdir -p .claude/commands
touch .claude/commands/specify.md

Now you can invoke it with /project:specify. Let's fill in the template.

The command name comes from the filename - specify.md becomes /project:specify.

👤 You

What goes in the file?

Now we write the actual prompt template.

🤖 AI

The file contains your prompt template. Here's a complete /specify command:

---
description: Generate a Product Requirements Document
argument-hint: <feature description>
---

Create a Product Requirements Document (PRD) for the following feature.

## What to Include

1. **Problem Statement** - What user problem does this solve?
2. **User Stories** - As a [user], I want [goal] so that [benefit]
3. **Functional Requirements** - Label as FR-1, FR-2, etc.
4. **Non-Functional Requirements** - Performance, security, scale
5. **Out of Scope** - Explicitly list what this does NOT include
6. **Success Metrics** - How will we measure success?

## What NOT to Include

- Technical implementation details
- Database schemas or API designs
- Time estimates

## Feature Description

$ARGUMENTS

The $ARGUMENTS placeholder captures everything after the command name.

The frontmatter (---) provides metadata. The body is the actual prompt. $ARGUMENTS injects user input.

👤 You

So when I type /project:specify A notification system for our app, what happens?

Understanding the substitution mechanism.

🤖 AI

Claude receives this expanded prompt:

Create a Product Requirements Document (PRD) for the following feature.

## What to Include

1. **Problem Statement** - What user problem does this solve?
2. **User Stories** - As a [user], I want [goal] so that [benefit]
...

## Feature Description

A notification system for our app

That's it. The "magic" is just prompt template + user input.

$ARGUMENTS is replaced with whatever comes after the command name.

---

Building a /session-start Command

Now let's create session management from scratch.

👤 You

How would I build /session-start myself?

Building a more complex command with file creation.

🤖 AI

Create .claude/commands/session-start.md:

---
description: Start a tracked development session
argument-hint: <session-name>
allowed-tools: Bash(mkdir:*), Bash(date:*), Write
---

Start a new development session called "$ARGUMENTS".

## Your Tasks

1. Create the session tracking file:
   - Path: `.claude/sessions/$ARGUMENTS.md`
   - Include: Session name, start timestamp, initial git status

2. Ask me about:
   - What I'm working on today
   - Current blockers or context I should know
   - Specific goals for this session

3. After I respond, summarize the session context at the top of the tracking file.

## Session File Template

```markdown
# Session: $ARGUMENTS

**Started:** [current timestamp]
**Status:** In Progress

## Context
[To be filled after discussion]

## Progress Log
- [timestamp] Session started

## Git Status at Start
[git status output]

Create the sessions directory if it doesn't exist.

The `allowed-tools` frontmatter restricts which tools the command can use.

The prompt instructs Claude what to do, including creating files and asking follow-up questions.

👤 You

And /session-end would read that file and summarize?

Commands can work together by reading/writing shared files.

🤖 AI

Exactly. Create .claude/commands/session-end.md:

---
description: End current session with summary
allowed-tools: Read, Edit, Bash(git:*)
---

End the current development session.

## Your Tasks

1. Find the most recent session file in `.claude/sessions/`

2. Generate a session summary including:
   - **Duration**: Calculate from start timestamp
   - **Completed**: What was accomplished (check git diff)
   - **In Progress**: Unfinished work
   - **Next Steps**: Recommended actions for next session
   - **Key Decisions**: Any architectural or design decisions made
   - **Blockers**: Issues that prevented progress

3. Update the session file:
   - Change status to "Completed"
   - Add end timestamp
   - Append the summary

4. Show me the summary and ask if I want to add anything.

## Git Commands to Run

- `git status` - See current changes
- `git diff --stat` - See what files changed
- `git log --oneline -5` - Recent commits this session

The commands form a workflow by reading/writing to the same .claude/sessions/ directory.

Session-end reads what session-start created, forming a cohesive workflow.

---

Advanced: Positional Arguments

For commands with multiple inputs, use $1, $2, $3:

👤 You

What if my command needs multiple arguments?

Handling more complex input scenarios.

🤖 AI

Use positional arguments like shell scripts. Create .claude/commands/review-pr.md:

---
description: Review a PR with specific focus area
argument-hint: <pr-number> <focus: security|performance|logic>
---

Review Pull Request #$1 with focus on $2.

## Review Checklist for $2

### If focus is "security":
- [ ] Input validation
- [ ] Authentication/authorization checks
- [ ] SQL injection prevention
- [ ] XSS prevention
- [ ] Secrets handling

### If focus is "performance":
- [ ] N+1 queries
- [ ] Unnecessary re-renders
- [ ] Memory leaks
- [ ] Bundle size impact

### If focus is "logic":
- [ ] Edge cases handled
- [ ] Error states covered
- [ ] Business logic correctness
- [ ] Test coverage

Fetch PR #$1 and provide a detailed review.

Usage: /project:review-pr 123 security

• $1 = 123
• $2 = security

Positional arguments enable commands with multiple structured inputs.

---

Sharing Commands Across Your Team

Since .claude/commands/ lives in your repo, commands are automatically shared:

git add .claude/commands/
git commit -m "Add team workflow commands"
git push

Now everyone on your team has the same /project:specify, /project:session-start, etc.

For Personal Commands

Put commands you don't want to share in ~/.claude/commands/. These appear as /user:command-name and stay on your machine only.

---

GitHub Copilot: Similar Pattern

GitHub Copilot uses .github/prompts/ with the same concept:

<!-- .github/prompts/spec.prompt.md -->
You are a product manager. Create a specification for:

{{ input }}

Include user stories, acceptance criteria, and edge cases.

The syntax differs slightly ({{ input }} vs $ARGUMENTS) but the pattern is identical: reusable prompt templates.

Key Takeaways

• Slash commands are just Markdown files containing prompt templates
• Put project commands in .claude/commands/, personal in ~/.claude/commands/
• Use $ARGUMENTS for single input, $1 $2 $3 for multiple arguments
• Commands can work together by reading/writing shared files
• Commit .claude/commands/ to git to share workflows with your team

Try It Yourself

Prompt Template

Create a custom slash command for a task you do repeatedly.

1. Create the file:
```bash
mkdir -p .claude/commands
```

2. Write your template in `.claude/commands/your-command.md`:
```markdown
---
description: [What this command does]
argument-hint: [Expected input]
---

[Your prompt here]

$ARGUMENTS
```

3. Test it: `/project:your-command [input]`

Copy template

Variations to Try

• Start simple: Create a /project:explain command that explains code you paste in
• Add structure: Create /project:plan that generates implementation plans
• Build workflows: Create /project:task-start and /project:task-done that work together

Related Content

📖 Structured Outputs & JSON Schema 📖 Tokens & Tokenization 📖 Context Windows 🏋️ prompt construction

Sources

✓ Anthropic: Custom Commands ⓘ

×

Claude Code: Best practices for agentic coding

Anthropic

Official best practices for Claude Code agentic development. Key for agentic_supervision dimension - demonstrates multi-file autonomous editing capabilities and supervision approaches.

Key Findings:

• Claude Code is a command line tool for agentic coding
• CLAUDE.md provides project-specific context and instructions
• Plan mode shows intentions before making changes

Credibility: high

View Source ↗