Slash Commands in Claude Code: Building Your Daily Operating System

By James Aspinwall, co-written by Alfred Pennyworth (my trusted AI) — February 26, 2026, 17:00

What Are Slash Commands?

Slash commands are how you talk to Claude Code without explaining yourself every time. Instead of typing “read my project context, check today’s tasks, review yesterday’s commits, and give me a prioritized plan for the day” — you type /today and it does all of that.

Claude Code supports three layers of slash commands:

  1. Built-in commands — About 30 commands that ship with Claude Code (/help, /compact, /plan, /model, etc.)
  2. Custom skills — Commands you create as markdown files that teach Claude your workflows
  3. MCP prompts — Commands exposed by connected MCP servers (/mcp__github__summarize_pr, etc.)

The built-in commands manage your session. The custom skills are where the real power lives — they encode your workflows, your preferences, and your thinking patterns into executable instructions.

How Custom Commands Work

A custom command is a folder with a SKILL.md file. That’s it. No code. No configuration files. Just markdown with a YAML header.

Where They Live

Level Path Who sees it
Personal ~/.claude/skills/<name>/SKILL.md You, across all projects
Project .claude/skills/<name>/SKILL.md Anyone working on this project

Personal skills follow you everywhere. Project skills are checked into git and shared with your team. When names collide, personal wins.

The File Format

---
name: morning-review
description: Morning planning based on tasks and recent activity
disable-model-invocation: true
allowed-tools: Read, Grep, Glob, Bash(git log *)
---

Review my current state and create a prioritized plan for today:

1. Read the project CLAUDE.md for context
2. Check recent git commits: !`git log --oneline -10`
3. Review open tasks and deadlines
4. Check for any failing tests or build issues
5. Prioritize: what's blocked, what's due, what has momentum

Output a clear, numbered plan. No fluff.

The YAML frontmatter controls behavior:

Arguments

Commands accept arguments through $ARGUMENTS or positional variables $0, $1, $2:

---
name: investigate
---
Investigate the issue described below. Find the root cause,
check related code, and suggest a fix.

Issue: $ARGUMENTS

Usage: /investigate the login endpoint returns 403 for admin users

Dynamic Context

The !`command` syntax runs a shell command before Claude sees the skill, injecting live data:

---
name: standup
---
Based on my recent activity, draft a standup update:

Recent commits: !`git log --oneline --since="yesterday" --author="$(git config user.name)"`
Current branch: !`git branch --show-current`
Modified files: !`git diff --name-only`

Commands for Your Daily Routine

These are the commands that turn Claude Code from a coding assistant into a daily operating system.

Morning Startup

/today — Daily Planning

---
name: today
description: Morning review and daily planning
disable-model-invocation: true
allowed-tools: Read, Grep, Glob, Bash(git *)
---

Morning planning session. Build my day plan:

1. Read CLAUDE.md and any memory files for project context
2. Recent commits (last 3 days): !`git log --oneline --since="3 days ago"`
3. Current branch state: !`git status --short`
4. Review any open TODOs or task files
5. Check for compilation errors or test failures

Create a prioritized plan:
- What's blocked and needs unblocking first
- What has momentum and should continue
- What's new and needs scoping
- What can wait

Be direct. No motivational fluff. Just the plan.

/inbox — Process Overnight Messages

---
name: inbox
description: Review and triage overnight messages and notifications
disable-model-invocation: true
context: fork
---

Check for any overnight activity:

1. Recent git activity from collaborators
2. Any new issues or PRs (if GitHub CLI available): !`gh issue list --limit 5 2>/dev/null || echo "no gh cli"`
3. Review any notification logs or message queues

Triage into: respond now, schedule for later, or ignore.

End of Day

/close — End of Day Review

---
name: close
description: End-of-day review and handoff
disable-model-invocation: true
allowed-tools: Read, Grep, Glob, Bash(git *)
---

End-of-day processing:

1. What I accomplished today: !`git log --oneline --since="8 hours ago"`
2. What changed: !`git diff --stat HEAD~5..HEAD 2>/dev/null || echo "fewer than 5 commits"`
3. Current state of the working tree: !`git status --short`

Generate:
- Summary of what got done (for standup or changelog)
- Open threads: anything started but not finished
- Tomorrow's priorities based on today's momentum
- Any risks or blockers surfaced during today's work

/reflect — Daily Reflection

---
name: reflect
description: End-of-day reflection on decisions and learning
disable-model-invocation: true
context: fork
---

Based on today's work, reflect on:

1. What decisions did I make today? Were they good in retrospect?
2. What did I learn that I didn't know this morning?
3. Where did I spend time that didn't produce value?
4. What pattern am I repeating that I should change?
5. What's the one thing I should do differently tomorrow?

Be honest, not encouraging. I want useful feedback, not affirmation.

Commands for the Development Cycle

Code Quality

/review — Pre-Commit Review

---
name: review
description: Review staged changes before committing
disable-model-invocation: true
allowed-tools: Read, Grep, Glob, Bash(git *)
---

Review my staged changes for issues:

Staged diff: !`git diff --cached`

Check for:
- Security issues (hardcoded secrets, SQL injection, XSS)
- Logic errors or edge cases not handled
- Missing error handling at boundaries
- Breaking changes to public APIs
- Code that should have tests but doesn't

Be critical. I want problems found now, not in production.

/test-check — Test Health

---
name: test-check
description: Run tests and analyze failures
disable-model-invocation: true
allowed-tools: Read, Grep, Glob, Bash(mix *)
---

Run the test suite and analyze results:

1. Run tests: `mix test`
2. If failures exist, read the failing test files
3. Read the source files being tested
4. Identify root cause for each failure
5. Suggest fixes (don't apply them — just explain)

Focus on why the test fails, not just what failed.

/debt — Technical Debt Scan

---
name: debt
description: Scan for technical debt and code smells
context: fork
agent: Explore
allowed-tools: Read, Grep, Glob
---

Scan the codebase for technical debt:

1. TODO/FIXME/HACK comments: what's been deferred and for how long?
2. Dead code: unused functions, unreachable branches
3. Duplicated logic that should be extracted
4. Overly complex functions (too many branches, too long)
5. Missing error handling at system boundaries
6. Dependencies that are outdated or deprecated

Rank by impact: what's most likely to cause a production issue?

Architecture and Planning

/scope — Scope a Feature

---
name: scope
description: Scope a new feature or change
disable-model-invocation: true
context: fork
agent: Plan
---

Scope the following feature: $ARGUMENTS

1. What files need to change?
2. What new files need to be created?
3. What existing behavior might break?
4. What's the simplest implementation that works?
5. What are the permission/security implications?
6. Estimated effort: small (< 1 hour), medium (1-4 hours), large (4+ hours)

Don't overdesign. What's the minimum that solves the problem?

/impact — Impact Analysis

---
name: impact
description: Analyze the impact of changing a specific function or module
context: fork
agent: Explore
allowed-tools: Read, Grep, Glob
---

Analyze the impact of changing: $ARGUMENTS

1. Find all callers and dependents
2. Trace the data flow through the system
3. Identify which tests cover this code
4. List every file that would need to change
5. Flag any breaking changes to public APIs

I need to know the blast radius before I touch this.

Debugging

/diagnose — Debug a Problem

---
name: diagnose
description: Diagnose a bug or unexpected behavior
disable-model-invocation: true
allowed-tools: Read, Grep, Glob, Bash(mix *, git *)
---

Diagnose this problem: $ARGUMENTS

1. Search for related code and recent changes
2. Check git blame: when was this code last modified and by whom?
3. Look for similar patterns elsewhere in the codebase
4. Form a hypothesis about root cause
5. Suggest a diagnostic step to confirm (not a fix — just verification)

Think like a detective: evidence first, theory second.

Commands for Health and Sustainability

Development is a marathon. These commands keep you honest about the non-code parts of the job.

Mental Health

/pace — Work Pace Check

---
name: pace
description: Check work pace and burnout indicators
disable-model-invocation: true
context: fork
---

Analyze my work patterns for burnout signals:

Recent commit times: !`git log --format="%ai" --since="14 days ago" | head -50`

Check for:
- Am I committing at 2 AM regularly?
- Are there days with zero commits (rest) or is it nonstop?
- Are commit messages getting shorter/sloppier (fatigue signal)?
- Am I working weekends consistently?

Be direct about what you see. If the pattern is unsustainable, say so.

/stuck — When You’re Stuck

---
name: stuck
description: Help when feeling stuck or overwhelmed
disable-model-invocation: true
---

I'm stuck. Help me get moving:

Current state: !`git status --short`
Current branch: !`git branch --show-current`
Recent work: !`git log --oneline -5`

1. What's the smallest possible next step? Not the whole solution — just one thing I can do in 10 minutes.
2. Am I stuck because of a technical problem, or because I'm avoiding a decision?
3. Is there something I should ask someone instead of figuring out alone?
4. Should I switch tasks and come back to this later?

Don't solve the problem. Just get me moving.

/wins — Celebrate Progress

---
name: wins
description: Review recent accomplishments to maintain motivation
disable-model-invocation: true
context: fork
---

Show me what I've accomplished recently:

Last 7 days: !`git log --oneline --since="7 days ago"`
Last 30 days: !`git log --oneline --since="30 days ago" | wc -l` commits

1. Summarize the major things I shipped this week
2. What improved in the codebase because of my work?
3. What's something I did well that I probably didn't notice?

Sometimes I need to see the progress to believe it's real.

Physical Health

/break — Break Reminder

---
name: break
description: Suggest a break based on session duration
disable-model-invocation: true
---

Session check. Ask me:

1. How long have I been at the keyboard?
2. Have I had water in the last hour?
3. Have I stood up in the last 90 minutes?

If any answer is bad, tell me firmly to take a break.
No negotiation. Close the laptop, move the body, drink water.
Return in 10 minutes.

/ergonomics — Posture and Setup Check

---
name: ergonomics
description: Quick ergonomic check-in
disable-model-invocation: true
---

Quick ergonomic check. Ask me to verify:

- Screen at arm's length, top of screen at eye level?
- Feet flat on the floor?
- Shoulders relaxed, not hunched?
- Wrists neutral, not bent?
- Room lighting not causing glare on screen?
- Room temperature comfortable?

Pick one thing to fix right now. Small adjustments compound.

Commands for Learning and Growth

/explain — Deep Understanding

---
name: explain
description: Explain a concept or code pattern in depth
context: fork
agent: Explore
allowed-tools: Read, Grep, Glob
---

Explain this in depth: $ARGUMENTS

1. What is it and why does it exist?
2. How does it work in this codebase specifically?
3. What are the tradeoffs? What's the alternative?
4. When would I choose this vs the alternative?
5. Show me a concrete example from the codebase

Teach me like I'm smart but unfamiliar with this specific thing.

/til — Today I Learned

---
name: til
description: Capture something learned today
disable-model-invocation: true
---

I just learned something: $ARGUMENTS

1. Summarize what I learned in 2-3 sentences
2. Why does it matter for my work?
3. What should I do differently now that I know this?
4. Is there a related concept I should learn next?

Keep it brief. This is a note for future me.

/rabbit-hole — Controlled Deep Dive

---
name: rabbit-hole
description: Time-boxed deep dive into a topic
disable-model-invocation: true
context: fork
agent: Explore
allowed-tools: Read, Grep, Glob
---

I want to understand: $ARGUMENTS

Rules:
- You have 5 minutes of my attention. Make it count.
- Start with the 80/20: what gives me 80% understanding with 20% effort?
- Then go one level deeper on the most important subtopic
- End with: "If you want to go further, look at X"

Don't try to be comprehensive. Be useful.

A Suggested Daily Routine

Here’s how these commands chain into a daily operating rhythm:

Morning (10 minutes)

/today          → See the landscape, set priorities
/inbox          → Triage overnight activity

Work Blocks (as needed)

/scope [feature]    → Before starting something new
/diagnose [bug]     → When something breaks
/review             → Before every commit
/stuck              → When momentum stalls
/break              → Every 90 minutes

End of Day (10 minutes)

/close          → Capture what happened, set up tomorrow
/reflect        → Honest assessment of the day
/til [thing]    → Lock in what you learned

Weekly (30 minutes)

/wins           → See the progress
/pace           → Check for burnout patterns
/debt           → What's accumulating?

Building Your Own

Start with three commands:

  1. /today — Your morning startup sequence
  2. /review — Pre-commit quality check
  3. /close — End of day handoff

Use them for a week. You’ll immediately see what’s missing. Then build the next command to fill that gap. The best command library is grown organically from real needs, not designed upfront.

The commands that matter most are the ones that encode the things you forget to do — the review you skip when you’re rushing, the break you ignore when you’re deep in flow, the reflection you avoid when the day was hard.

That’s what a personal operating system is: not a productivity hack, but a set of habits encoded in files that run whether you feel like it or not.

Quick Reference: Built-in Commands

These ship with Claude Code and require no setup:

Command What it does
/help Show available commands and usage
/compact Compress conversation context to save tokens
/plan Enter planning mode (think before acting)
/model Switch between Claude models mid-session
/cost Show token usage and cost for the session
/context Show current context window usage
/config View or change Claude Code settings
/mcp Manage MCP server connections
/resume Resume a previous conversation
/rewind Undo the last action

The Key Insight

A slash command is just a markdown file. There’s no code to write, no API to learn, no framework to install. If you can describe a workflow in English, you can build a command.

The gap between “I should do X every morning” and “I do X every morning” is exactly one markdown file.

WorkingAgents — AI agent infrastructure for companies that need to get it right. workingagents.ai