Day 13: Advanced Slash Commands - Parameters and Chaining

Hey, it's G.

Day 13 of the Claude Code series. Final day of the Slash Commands track.

Basic slash commands are just saved prompts.

But once I learned about parameters and chaining, they became something closer to actual tools.

Parameters let a command accept input so it behaves differently depending on what you pass it.

Chaining lets you run multiple commands in sequence to handle complex multi-step workflows.

This is where slash commands stop feeling like shortcuts and start feeling like a system.

The Problem (Static Commands Have Limits)

After building my command library, I hit a wall.

I had /review for code review. But sometimes I needed to focus only on security. Other times only on performance. Other times only on TypeScript types.

My options were:

1. Create separate commands: /review-security, /review-performance, /review-types
2. Make one giant /review that checks everything deeply every time

Option 1: Command bloat. Too many files.

Option 2: Slow and unfocused. Wastes time checking everything when I only care about one thing.

What I needed: One /review command that adapts based on what I tell it.

Same problem with workflows.

My end-of-session routine was always the same:

1. Review changes
2. Check conventions
3. Write commit message
4. Note follow-ups

But I was typing four separate prompts. Every single session.

What I needed: One command that runs all four steps automatically.

The Concept (Parameters and Chaining)

Two upgrades that take slash commands to the next level:

1. Parameters — Dynamic Placeholders

Dynamic placeholders inside your command that get replaced with real values when you call it.

Instead of a command that always does the same thing, you get a command that does the same type of thing but adapts to what you give it.

Mental model: Think of them like function arguments.

reviewFile() is less useful than reviewFile(filename, focus)

Same idea here.

2. Chaining — Multiple Commands in Sequence

Running multiple commands in sequence inside one session to handle workflows that have multiple distinct steps.

You're not writing one big messy prompt — you're composing smaller focused commands into a pipeline.

Mental model: Think of it like a Unix pipe.

grep | sort | uniq — each tool does one job, together they do something powerful.

Parameters: Using $ARGUMENTS

Claude Code has a special variable called $ARGUMENTS.

Whatever you type after the command name gets passed into this variable.

You reference it inside your command file.

Example: Review with Focus

Create the command:

touch ~/.claude/commands/review-focus.md

Inside the file:

Review the current file with a specific focus on: $ARGUMENTS

Be thorough only in the area specified. For everything else,
just flag obvious issues without going deep.

Report findings only — do not make changes.

Call it with different parameters:

claude

> /review-focus security

Claude focuses on security:

• SQL injection vulnerabilities
• XSS vulnerabilities
• Exposed API keys
• Authentication bugs
• Input validation

> /review-focus performance

Claude focuses on performance:

• Unnecessary re-renders
• Missing memoization
• Inefficient loops
• Slow database queries
• Large bundle contributions

> /review-focus TypeScript types

Claude focuses on TypeScript:

• Any any types
• Missing return types
• Unsafe type assertions
• Type errors

Same command. Different focus. Every time.

One file. Infinite variations.

Example: Explain To Different Audiences

Create the command:

touch ~/.claude/commands/explain-to.md

Inside the file:

Explain the current file as if you are talking to: $ARGUMENTS

Adjust your language, depth, and examples accordingly.

Cover:
- What the file does
- How it works
- Why it exists

Call it for different audiences:

> /explain-to a junior developer

Claude uses: Simple language, basic concepts, step-by-step logic

> /explain-to a non-technical client

Claude uses: No jargon, business outcomes, high-level overview

> /explain-to someone who knows Python but not JavaScript

Claude uses: Python analogies, highlights JS-specific patterns, compares syntax

One command. Adapts to who you're explaining to.

Example: Write Tests For Specific Things

Create the command:

touch ~/.claude/commands/write-tests-for.md

Inside the file:

Write tests specifically for this function or feature: $ARGUMENTS

Use Vitest. Cover happy path, edge cases, and error states.
Place the test file next to the source file.
Do not modify the source file.

Call it for specific targets:

> /write-tests-for the login function

Claude writes tests for: Login logic only

> /write-tests-for the payment webhook handler

Claude writes tests for: Webhook handler only

> /write-tests-for all exported utility functions

Claude writes tests for: Every utility in the file

One command. Scopes to what you specify.

More Parameter Command Ideas

/refactor-for

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

Refactor the current file optimizing for: $ARGUMENTS

Rules:
- Do not change function signatures
- Do not change logic or behavior
- Focus specifically on the optimization goal
- Flag any trade-offs made

Usage:

> /refactor-for readability
> /refactor-for performance
> /refactor-for testability

/document-for

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

Add documentation to this file aimed at: $ARGUMENTS

Include:
- High-level purpose
- Key functions and what they do
- Usage examples appropriate for the audience

Do not modify code — add comments and docs only.

Usage:

> /document-for API consumers
> /document-for maintainers
> /document-for new team members

/security-check

File: ~/.claude/commands/security-check.md

Security audit focused on: $ARGUMENTS

Check for:
- Common vulnerabilities in this area
- Misconfigurations
- Missing protections
- Best practices violations

Report findings with severity (critical/high/medium/low).

Usage:

> /security-check authentication
> /security-check data validation
> /security-check API endpoints

Chaining: Running Commands in Sequence

Chaining isn't a built-in feature with special syntax.

It's a workflow habit.

You run commands one after another inside the same Claude Code session, where each command builds on the context of the previous one.

Complete Feature Workflow

Building a new feature from start to finish:

claude

# Step 1 — Understand what you're working with
> view app/components/LoginForm.tsx
> /explain

# Step 2 — Review it before touching anything
> /review

# Step 3 — Describe the task, plan before acting
> I need to add input validation to this form
> /plan

# Claude shows detailed plan — you review and approve

# Step 4 — Claude executes the plan

# Step 5 — Review what changed
> /review

# Step 6 — Write the commit message
> /commit

Six steps. Five of them are single commands.

Each command:

• Does one focused thing
• Builds on previous context
• Keeps the workflow clean

No repeated typing. No messy mega-prompts. Just a clear pipeline.

My Real End-of-Session Workflow

Before I learned chaining:

Every session ended with 10 minutes of manual prompting:

> Review what changed in this session for any issues

[Claude responds]

> Check if anything violates our CLAUDE.md conventions

[Claude responds]

> Write a commit message based on what we changed

[Claude responds]

> Are there any follow-up tasks I should note?

[Claude responds]

Four separate prompts. Every time.

After I learned chaining:

I built a /ship command that does all four at once.

The /ship Command (My Favorite Chain)

Create the command:

touch ~/.claude/commands/ship.md

Inside the file:

We are about to finish and commit the current work.
Run through these steps in order:

1. Review the changes made in this session for any issues
2. Check that nothing violates our CLAUDE.md conventions
3. Suggest a commit message based on what changed
4. List any follow-up tasks worth noting before we close this out

Do all four steps without waiting for confirmation between them.
Report everything together at the end.

Use it at the end of every session:

> /ship

Claude responds with everything:

Pre-Commit Workflow Complete

1. REVIEW FINDINGS:
✅ No TypeScript errors
✅ No logic bugs
✅ No security issues
✅ No performance problems

2. CONVENTION CHECK:
✅ All exports are named exports
✅ No `any` types used
✅ All components under 150 lines
✅ Tailwind utility classes only

3. SUGGESTED COMMIT MESSAGE:
add input validation to login form

Implemented Zod validation for email and password fields.
Added error messages for invalid inputs.
Returns 400 with validation errors before authentication.

4. FOLLOW-UP TASKS:
- Add rate limiting to login endpoint
- Write tests for validation logic
- Update API documentation with new error codes

One command. Complete pre-commit workflow. Every time.

Review → Conventions → Commit message → Follow-ups

10 minutes saved per session = hours per week.

Real Session Using Parameters and Chaining

Let me show you a real session building a new API route.

Step 1: Understand the Pattern

cd ~/projects/resiboko
claude

> view app/api/users/route.ts
> /explain

Claude explains the existing route pattern.

Step 2: Plan the New Route

> I need to build a similar route for /app/api/subscriptions/
> /plan

Claude responds:

Plan for new subscriptions route:

Files to create:
1. app/api/subscriptions/route.ts
   - GET: fetch user subscription status
   - POST: create new subscription
   - DELETE: cancel subscription

Pattern to follow:
- Same middleware stack as users route
- Same error handling approach
- Same response format
- Add rate limiting (10 req/min)

Dependencies:
- Uses existing Stripe client in /lib/stripe.ts
- Uses Supabase auth for user verification

Estimated steps: 8

Proceed?

I review. Approve.

Step 3: Claude Builds It

Claude creates the route following the plan.

Step 4: Security-Focused Review

> /review-focus security

Claude responds:

Security Review — app/api/subscriptions/route.ts

✅ Authentication checked before all operations
✅ User can only access their own subscription
✅ Stripe secret key not exposed client-side
✅ Input validation on all POST/DELETE requests
⚠️ Line 45: Error messages expose internal details
   Fix: Return generic "Unable to process request"

1 issue found. Fix suggested above.

I fix the error message.

Step 5: Ship It

> /ship

Claude responds with full pre-commit workflow:

Pre-Commit Workflow Complete

1. REVIEW FINDINGS:
✅ No issues found

2. CONVENTION CHECK:
✅ Named exports only
✅ No `any` types
✅ Tailwind utility classes
✅ File under 150 lines

3. SUGGESTED COMMIT MESSAGE:
add subscriptions API route

Implemented GET/POST/DELETE endpoints for subscription management.
Uses Stripe for payment processing and Supabase for user verification.
Includes rate limiting (10 req/min) and proper error handling.

4. FOLLOW-UP TASKS:
- Write tests for all three endpoints
- Add webhook handler for Stripe events
- Update API documentation

Perfect. Copy the commit message. Done.

Entire session:

• /explain → understand pattern
• /plan → plan new route
• /review-focus security → targeted security check
• /ship → complete pre-commit workflow

Four commands. Full feature. Clean process.

Advanced Chain: The /deep-review Command

For high-stakes code that needs multiple review passes:

touch ~/.claude/commands/deep-review.md

Deep multi-pass review of current file.
Run these reviews in sequence:

1. TypeScript type safety review
2. Security vulnerability review
3. Performance optimization review
4. Clean code principles review
5. CLAUDE.md conventions compliance

For each pass, report findings separately.
At the end, prioritize all findings by severity.

Do all five passes without waiting for confirmation.

Usage:

> /deep-review

Claude runs five separate focused reviews and consolidates findings.

Advanced Chain: The /prep-pr Command

Before opening a pull request:

touch ~/.claude/commands/prep-pr.md

Prepare this work for pull request review.
Run through these steps:

1. Review all changed files for issues
2. Check test coverage — flag untested code
3. Check for TODO/FIXME comments that should be resolved
4. Suggest PR title and description based on changes
5. List potential reviewer concerns to address proactively

Do all steps without waiting. Report everything together.

Usage:

> /prep-pr

Gets you PR-ready in one command.

Best Practices (What Actually Works)

1. Keep Individual Commands Focused

❌ Bad (tries to do everything):

# mega-review.md
Review for types, security, performance, conventions,
tests, documentation, and also suggest improvements

✅ Good (focused commands you can compose):

# review-focus.md
Review focused on: $ARGUMENTS

# ship.md
Run pre-commit workflow steps in sequence

Focused commands chain cleanly. Mega-commands don't.

2. Use Parameters for Variations, Not Different Tasks

❌ Bad (different tasks):

# do-thing.md
Do this thing: $ARGUMENTS

This is too vague to be useful.

✅ Good (same task, different focus):

# review-focus.md
Review current file focused on: $ARGUMENTS

Same task (review). Different focus (security, performance, types).

3. Chain Commands in Session, Don't Make One Giant Command

❌ Bad (one giant command):

# everything.md
Understand the file, review it, refactor it,
document it, write tests, and commit it

Too much. Too rigid. No control.

✅ Good (compose in session):

> /explain
> /review
> /refactor
> /document
> /test
> /commit

Each step visible. Can skip steps. Can adjust between steps.

4. Build Chains for Your Most Repeated Multi-Step Workflows

Notice the workflows you run every time:

Every session ends with: Review → Conventions → Commit → Follow-ups
→ Build /ship

Every PR prep includes: Review → Test coverage → TODOs → PR description
→ Build /prep-pr

Every new feature starts with: Explain → Review → Plan
→ Build /start-feature

My Raw Notes (Unfiltered)

The $ARGUMENTS thing is simple but powerful.

The /explain-to command is one I use a lot when preparing docs for non-technical stakeholders.

The /ship command is my favorite chain — one command at the end of every session that handles review, conventions check, commit message, and follow-up notes all at once.

Realized that chaining is really just a workflow habit more than a technical feature — the power comes from having focused single-purpose commands that you can compose.

Keep individual commands focused so they chain cleanly.

The /review-focus command eliminated the need for five separate review commands I was building.

Parameters work best when the command does the same type of thing but with different targets or focuses.

Tomorrow (Day 14 Preview)

Topic: What Vibe Coding Actually Is and the Mindset Shift That Makes It Work

What I'm sharing: The most requested topic in the series. What "vibe coding" actually means, why it's not just "AI writes your code," and the mental shift that makes it productive instead of chaotic.

Slash Commands track complete. 🎉

Next track: Vibe Coding (Days 14-17)

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
• Day 13: Advanced slash commands (today)
• Day 14: Vibe coding mindset (tomorrow)

G

P.S. - Build the /ship command today. It's one command at the end of every session that handles your entire pre-commit workflow automatically.

P.P.S. - Parameters with $ARGUMENTS turn one command into infinite variations. /review-focus security vs /review-focus performance — same command, different focus.

P.P.P.S. - Chaining isn't a feature, it's a habit. Compose focused commands in sequence instead of building one giant mega-command.