Day 12: Building Your Slash Command Library

Hey, it's G.

Day 12 of the Claude Code series.

One slash command is useful.

A full library of them is a superpower.

Today I sat down and thought through every repeated workflow I run in Claude Code and turned them into commands.

The result: a personal library I now carry into every project.

It took about an hour to build. It saves me that every week.

Let me show you what's in it.

The Problem (Reinventing the Wheel Every Session)

Before I had a command library, every Claude Code session looked like this:

Starting a task:

> Before you start, tell me your plan for implementing this...

After making changes:

> Review what you just did for TypeScript errors, logic bugs, and...

At the end:

> Look at the git diff and write a commit message that...

Every. Single. Session.

Same workflows. Different tasks. Always retyping the same detailed prompts.

The Concept (Your Personal Toolkit)

A slash command library is a curated collection of your most repeated Claude Code workflows.

Saved once. Available forever.

Think of it like building your own toolkit.

A carpenter doesn't reach for a new hammer every job — they have their tools ready before work starts.

Your slash command library is the same thing.

You build it once. Refine it over time. It gets more valuable the longer you use Claude Code.

There are four categories of commands worth building:

1. Code Quality

Review, lint, refactor

2. Understanding

Explain, summarize, document

3. Workflow

Git operations, standup, planning

4. Project-Specific

Commands unique to how your project works

Where they live:

Personal commands (~/.claude/commands/) → Your universal library. Works in every project.

Project commands (.claude/commands/) → Anything specific to one codebase.

Start with personal commands. That's your core toolkit that follows you everywhere.

The 8 Essential Commands Every Developer Should Have

Let me walk you through the library I use daily.

Command 1: /review

File: ~/.claude/commands/review.md

Review the current file thoroughly:
- TypeScript errors or unsafe types
- Logic bugs and unhandled edge cases
- Security issues (exposed keys, unsanitized inputs, etc.)
- Performance problems
- Violations of clean code principles

Report findings only. Do not make any changes.
List each issue with a suggested fix.

When to use: Before committing. After Claude makes changes. When reviewing someone else's code.

Why it matters: Catches bugs before they hit production. Enforces standards consistently.

Command 2: /refactor

File: ~/.claude/commands/refactor.md

Refactor the current file for readability and maintainability.

Rules:
- Do not change any function signatures
- Do not change any logic or behavior
- Do not add new dependencies
- Improve naming, structure, and clarity only
- Flag anything that looks like a bug but don't fix it — 
  just note it so I can review separately

When to use: When code works but is messy. When improving readability without touching logic.

Why it matters: Keeps codebase clean without risking behavioral changes.

Command 3: /explain

File: ~/.claude/commands/explain.md

Explain the current file as if I'm coming to it fresh.

Cover:
- What this file does and why it exists
- How the main functions work
- Any patterns or conventions being used
- Anything unusual or worth flagging

Keep it practical — not a line-by-line breakdown, 
just what I need to understand it quickly.

When to use: Jumping into unfamiliar code. Onboarding to a new project. Understanding legacy code.

Why it matters: Saves hours of manual code reading. Gets you up to speed fast.

Command 4: /document

File: ~/.claude/commands/document.md

Add JSDoc comments to all functions and exported types 
in the current file.

Rules:
- Don't change any existing code
- Keep comments concise and accurate
- Include @param, @returns, and @throws where relevant
- If a function's purpose is already obvious from its name, 
  keep the comment short

When to use: Before merging. When building a library. Anytime docs are missing.

Why it matters: Good documentation without the tedium of writing it manually.

Command 5: /test

File: ~/.claude/commands/test.md

Write tests for the current file.

Rules:
- Use Vitest (already configured in this project)
- Test each exported function
- Cover happy path, edge cases, and error states
- Place the test file next to the source file
- Do not modify the source file

When to use: After writing new utilities. When adding test coverage. Before refactoring.

Why it matters: Gets you from 0 tests to comprehensive coverage fast.

Note: Adjust the testing framework to match your project (Jest, Vitest, etc.).

Command 6: /standup

File: ~/.claude/commands/standup.md

Look at today's git commits and summarize what was 
accomplished in standup format:

- What was done today
- What is planned next
- Any blockers or open questions

Keep it to 5 bullet points maximum. 
Write it in first person, past tense for completed work.

When to use: Every morning. Before team standups.

Why it matters: 5 minutes saved every single day = 20+ hours per year.

Command 7: /plan

File: ~/.claude/commands/plan.md

Before making any changes, create a detailed plan for 
the task I just described.

Include:
- What files will be created or modified
- What the changes will be in each file
- Any dependencies or risks to flag
- Estimated number of steps

Do not write any code yet. Wait for my approval 
before proceeding.

When to use: Before any non-trivial task. Before touching multiple files. When you're not sure of the approach.

Why it matters: This is the most important command in my library.

It forces Claude to think before acting. Saves hours of back-and-forth. Catches scope creep early.

Command 8: /commit

File: ~/.claude/commands/commit.md

Look at the current git diff and write a commit message.

Format:
- First line: short summary under 50 characters (imperative mood)
- Blank line
- Body: what changed and why (not how)

Keep it factual and specific. No emojis.

When to use: After every session. Before pushing.

Why it matters: Good commit messages without the mental effort.

How To Build Your Library (Step-by-Step)

Step 1: Create Your Personal Commands Folder

mkdir -p ~/.claude/commands
cd ~/.claude/commands

This folder will hold your universal command library.

Step 2: Create Each Command File

One at a time:

touch review.md
touch refactor.md
touch explain.md
touch document.md
touch test.md
touch standup.md
touch plan.md
touch commit.md

Step 3: Fill In Each File

Copy the prompts from above into each file.

Or write your own variations that match your workflow.

Step 4: Verify Setup

ls ~/.claude/commands/

You should see:

review.md
refactor.md
explain.md
document.md
test.md
standup.md
plan.md
commit.md

Step 5: Test One Command

cd ~/projects/any-project
claude

> /standup

If it works, you're set. Keep going and test the rest.

Real Session Using the Library

Let me show you a real Claude Code session with these commands.

Task: Add rate limiting to all API routes

Step 1: Plan First

claude

> I need to add rate limiting to all API routes
> /plan

Claude responds:

Plan for adding rate limiting:

Files to modify:
1. /app/api/middleware/rateLimit.ts (create new)
   - Create rate limiting middleware using upstash-ratelimit
   - Configure limits: 10 requests per 10 seconds

2. /app/api/*/route.ts (modify all API routes)
   - Import rateLimit middleware
   - Add rate limit check at top of each handler
   - Return 429 if limit exceeded

3. package.json
   - Add @upstash/ratelimit dependency

Dependencies:
- @upstash/ratelimit
- @upstash/redis

Risks:
- Need Upstash Redis configured (check env vars)
- All existing API routes need modification (9 files)

Estimated steps: 11

Proceed?

I review the plan. Looks good. I approve:

> Approved. Proceed.

Step 2: After Changes, Review

> /review

Claude reviews all modified files and reports:

Review findings:

app/api/middleware/rateLimit.ts:
✅ No issues found

app/api/users/route.ts:
⚠️ Line 12: Error handling doesn't return proper status
   Fix: Wrap in try-catch, return NextResponse with 500

app/api/posts/route.ts:
✅ No issues found

[... continues for all files ...]

Summary: 1 issue found across 9 files. Fix suggested above.

I fix the one issue, then re-review:

> /review

All clear.

Step 3: Write Commit Message

> /commit

Claude responds:

add rate limiting to all API routes

Implemented rate limiting using @upstash/ratelimit across
all API endpoints. Configured limit of 10 requests per 10
seconds to prevent abuse.

Changes:
- Created rate limit middleware in /app/api/middleware/
- Applied middleware to all 9 API route handlers
- Added upstash dependencies to package.json
- Returns 429 Too Many Requests when limit exceeded

Perfect. I copy and commit:

git add .
git commit -m "add rate limiting to all API routes

Implemented rate limiting using @upstash/ratelimit across
all API endpoints. Configured limit of 10 requests per 10
seconds to prevent abuse.

Changes:
- Created rate limit middleware in /app/api/middleware/
- Applied middleware to all 9 API route handlers
- Added upstash dependencies to package.json
- Returns 429 Too Many Requests when limit exceeded"

Step 4: End of Day Standup

> /standup

Claude responds:

Daily Standup — March 12, 2026

What was done:
- Added rate limiting to all API routes (10 req/10s limit)
- Fixed error handling in users endpoint
- Configured Upstash Redis integration

What's next:
- Monitor rate limit metrics
- Add rate limit headers to responses

Blockers:
- None

One session. Four commands. Zero repeated typing.

Plan → Execute → Review → Commit → Standup

That's the workflow.

Beyond the Core 8 (Commands I Added Later)

After using the core 8 for a few weeks, I added these:

/security

Review the current file for security issues:
- SQL injection vulnerabilities
- XSS vulnerabilities  
- Exposed API keys or secrets
- Authentication/authorization bugs
- Input validation missing

Flag anything suspicious with severity (low/medium/high).

/perf

Review the current file for performance issues:
- Unnecessary re-renders (React)
- Missing memoization
- Inefficient loops or algorithms
- Database queries that could be optimized
- Large bundle size contributions

Suggest optimizations for each issue found.

/todos

Find all TODO, FIXME, HACK, and NOTE comments in the 
current file.

For each:
- Line number
- Comment text
- Suggested priority (high/medium/low)
- Quick recommendation

Sort by priority.

/deps

List all dependencies used in the current file.

For each:
- Import statement
- Where it's used
- If it's actually necessary or could be removed

Flag any that seem unused or redundant.

How To Discover What Commands You Need

Don't try to build your entire library on day one.

Instead, notice patterns:

Pattern 1: You Type the Same Prompt Three Times

If you've typed a prompt three times across different sessions...

→ That's a command.

Pattern 2: You Have a Pre/Post Ritual

Every time you start a task: "Plan this out first"
→ Create /plan

Every time you finish a task: "Review what changed"
→ Create /review

Every time you commit: "Write a commit message"
→ Create /commit

Pattern 3: You Wish You Did Something More Consistently

"I should write tests more often" → /test

"I should document my code" → /document

"I should check for security issues" → /security

Commands make best practices automatic.

Best Practices (What Actually Works)

1. Start With the Core 8

Don't reinvent the wheel. The 8 commands I shared work for almost every developer.

Copy them. Use them for a week. Then customize.

2. Keep Commands in Version Control

Add your personal commands to your dotfiles:

# In your dotfiles repo:
ln -s ~/.claude/commands ~/dotfiles/claude-commands

# On new machine:
ln -s ~/dotfiles/claude-commands ~/.claude/commands

Now your command library follows you to every machine.

3. Refine Commands Based on Usage

After using a command 5-10 times, you'll notice:

• Parts you always ignore (remove them)
• Things you wish it included (add them)
• Better phrasing (update it)

Commands should evolve with your workflow.

4. Share Project Commands With Your Team

Project-specific commands go in .claude/commands/:

# In your project:
mkdir -p .claude/commands
touch .claude/commands/migrations.md

Then commit:

git add .claude/commands/
git commit -m "add claude slash commands for team"

Now everyone on your team has the same commands.

My Raw Notes (Unfiltered)

Spent an hour building this properly and immediately felt the difference.

The /plan command is the one I use most — forces Claude to think before acting which saves so much back-and-forth.

The /commit command sounds small but writing good commit messages is something I always rushed before.

/review before every commit is now a non-negotiable habit.

Add these to your dotfiles if you back those up — your command library should follow you to every machine.

The library starts small (3-5 commands) and grows naturally as you notice patterns.

Don't create commands you think you should have. Create commands you actually use.

Tomorrow (Day 13 Preview)

Topic: Advanced Slash Commands — adding parameters, dynamic content, and chaining commands for complex workflows.

What I'm testing: Can you pass arguments to slash commands? Can commands call other commands? How far can you push this system?

Following This Series

Phase 2 (Days 8-14): Getting Productive ⬅️ You are here

So far in Phase 2:

• Day 8: CLAUDE.md structure and sections
• Day 9: Writing rules Claude actually follows
• Day 10: Evolving CLAUDE.md over time
• Day 11: Slash commands basics
• Day 12: Building your command library (today)
• Day 13: Advanced slash commands (tomorrow)

G

P.S. - Build the core 8 today. One hour of setup. Permanent productivity gains.

P.P.S. - The /plan command changed how I work with Claude Code. Plan first, execute second, zero surprises.

P.P.P.S. - If you only create one command from this list, make it /review. Code review before every commit catches so many bugs.