Meta Command Creator

Custom Slash Command Creator

Overview

Claude Code slash commands are markdown files with optional YAML frontmatter that create reusable /command workflows. Commands and skills are unified: .claude/commands/ files and .claude/skills/ directories both create slash commands. Skills are the recommended approach since they support additional features like supporting files, but single-file commands still work.

When to use: Repeatable prompts, team workflow standardization, guardrailed operations (deploy, commit), multi-phase tasks, dynamic context injection with bash output.

When NOT to use: Complex capabilities needing multiple files and scripts (use a full skill directory instead), one-off prompts, built-in commands that already exist (/compact, /help, /init).

Quick Reference

Priority Order

When commands share the same name across levels, higher-priority locations win:

1. Enterprise (managed settings) 2. Personal (~/.claude/) 3. Project (.claude/)

Plugin commands use namespacing (plugin:name) so they never conflict. If a skill and a command share the same name, the skill takes precedence.

Common Mistakes

Delegation

• Command pattern discovery: Use Explore agent to find existing commands in .claude/commands/ or .claude/skills/
• Complex workflow skills: For multi-file capabilities, create a full skill directory with SKILL.md and supporting files

References

• Command anatomy: markdown structure, YAML frontmatter fields, file locations, and priority order
• Arguments and references: $ARGUMENTS, positional args, bash injection, and file references
• Templates: ready-to-use command templates for common patterns

Arguments and References

$ARGUMENTS Placeholder

When a user invokes /command some text here, the string some text here is available as $ARGUMENTS. If the command content does not include $ARGUMENTS, Claude Code appends ARGUMENTS: <value> to the end of the content.

Basic usage

---
description: Fix a GitHub issue
disable-model-invocation: true
---

Fix GitHub issue $ARGUMENTS following our coding standards.

## Steps

1. Read the issue description
2. Understand the requirements
3. Implement the fix
4. Write tests
5. Create a commit

Invocation: /fix-issue 123 replaces $ARGUMENTS with 123.

Handling empty arguments

Always account for the case where no arguments are provided:

---
description: Build the project
argument-hint: [target]
---

Build target: $ARGUMENTS

## Steps

1. If no arguments provided, run the default build
2. Otherwise, build the specified target
3. Report results

Positional Arguments

Access individual arguments by zero-based index using $ARGUMENTS[N] or the shorthand $N.

$ARGUMENTS[N] syntax

---
description: Migrate a component between frameworks
argument-hint: [component] [from] [to]
---

Migrate the $ARGUMENTS[0] component from $ARGUMENTS[1] to $ARGUMENTS[2].
Preserve all existing behavior and tests.

Invocation: /migrate-component SearchBar React Vue

• $ARGUMENTS[0] = SearchBar
• $ARGUMENTS[1] = React
• $ARGUMENTS[2] = Vue

$N shorthand

The same command using shorthand notation:

---
description: Migrate a component between frameworks
argument-hint: [component] [from] [to]
---

Migrate the $0 component from $1 to $2.
Preserve all existing behavior and tests.

Two-argument pattern

---
description: Create a new file from template
argument-hint: [type] [name]
---

Create a $0 named $1

## Steps

1. Determine template based on type $0
2. Create file named $1
3. Apply project conventions

Invocation: /create component UserProfile

Bash Injection (! Prefix)

The ` !command ` syntax runs shell commands before the skill content is sent to Claude. The command output replaces the placeholder. This is preprocessing, not something Claude executes.

Requirements

• The allowed-tools frontmatter MUST include Bash(...) when using ! prefix
• Commands run in the project root directory
• Output is inserted inline where the placeholder appears

Git context example

---
description: Create a conventional git commit
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git status:*), Bash(git diff:*)
argument-hint: [optional message]
---

## Context

- Current status: !`git status`
- Current diff: !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -5`

## Steps

1. Analyze the changes shown above
2. Stage appropriate files
3. Create commit with conventional format: type(scope): description

## Format

Use these types: feat, fix, docs, style, refactor, perf, test, chore

PR review example

---
description: Summarize changes in a pull request
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---

## Pull request context

- PR diff: !`gh pr diff`
- PR comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`

## Your task

Summarize this pull request. Focus on:

1. What changed and why
2. Potential risks
3. Testing recommendations

Multiple dynamic sources

---
description: Review staged changes before commit
allowed-tools: Bash(git:*), Read, Grep, Glob
---

## Context

- Staged changes: !`git diff --cached`
- Modified files: !`git diff --cached --name-only`
- Current branch: !`git branch --show-current`

## Steps

1. Review each changed file
2. Check against project conventions
3. Look for common issues
4. Provide structured feedback

File References (@ Prefix)

The @ prefix inlines file contents into the command prompt. Use it to give Claude direct access to specific files without requiring tool calls.

Basic usage

---
description: Review configuration files
---

Review the following configuration for issues:

- Package config: @package.json
- TypeScript config: @tsconfig.json
- ESLint config: @eslint.config.js

Comparing files

---
description: Compare two implementations
argument-hint: [file1] [file2]
---

Compare @$0 with @$1 and summarize the differences.

Focus on:

1. Behavioral changes
2. Performance implications
3. Missing edge cases

Referencing project context

---
description: Create a component following project patterns
argument-hint: [component-name]
---

Create a new component named $ARGUMENTS following the patterns in:

- Example component: @src/components/Button.tsx
- Shared types: @src/types/components.d.ts

## Steps

1. Follow the structure of the example component
2. Use shared types from the types file
3. Add appropriate props interface

Session Variables

${CLAUDE_SESSION_ID}

The current session identifier. Useful for logging, session-specific files, or correlating output.

---
description: Log activity for this session
---

Log the following to logs/${CLAUDE_SESSION_ID}.log:

$ARGUMENTS

Extended Thinking

Include the word "ultrathink" in skill content to trigger extended thinking mode for deeper reasoning:

---
description: Analyze architecture implications
disable-model-invocation: true
---

ultrathink

Analyze the architecture implications of $ARGUMENTS.

## Steps

1. Map current dependencies
2. Identify affected components
3. Evaluate trade-offs
4. Recommend approach

Combining Patterns

Commands can combine multiple features for powerful workflows:

---
description: Debug a failing test
allowed-tools: Bash(pnpm test:*), Read, Grep, Glob
argument-hint: [test file or pattern]
---

## Context

- Test output: !`pnpm test $ARGUMENTS 2>&1 | tail -50`
- Test file: @$ARGUMENTS

## Steps

1. Analyze the test failure output above
2. Read the test file and implementation
3. Identify the root cause
4. Suggest a fix

## Output

Provide the root cause and a specific code fix.

Command Anatomy

Markdown Structure

Every command is a markdown file with optional YAML frontmatter followed by instruction content. The filename (minus .md) becomes the command name.

---
description: Brief description shown in /help
allowed-tools: Read, Grep, Glob
argument-hint: [filename]
---

# Command Title

## Steps

1. First action
2. Second action
3. Final action

YAML Frontmatter Fields

All fields are optional. Only description is recommended so Claude knows when to use the command.

description

Brief text shown in /help and used by the Skill tool to decide when to invoke the command.

---
description: Create a conventional git commit with proper formatting
---

Commands without description do not appear in /help and cannot be invoked by the Skill tool.

allowed-tools

Restricts which tools Claude can use without per-use approval when the command is active. Supports glob patterns for tool arguments.

---
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git status:*), Read
---

Common patterns:

---
allowed-tools: Read, Grep, Glob
---

---
allowed-tools: Bash(gh *), Read, Grep
---

Required when using ` !bash ` injection syntax.

argument-hint

Hint displayed during autocomplete to indicate expected arguments.

---
argument-hint: [issue-number]
---

---
argument-hint: [type] [name]
---

disable-model-invocation

Claude Code only — other agents ignore this field.

Prevents Claude from automatically loading this command. Use for commands with side effects (deploy, commit, send messages) where you want explicit control over timing.

---
disable-model-invocation: true
---

When set to true, the description is not loaded into Claude context at all, reducing context cost to zero.

user-invocable

Claude Code only — other agents ignore this field.

Set to false to hide from the / menu. Use for reference/knowledge skills where /skill-name isn't a meaningful user action. Claude can still auto-load the skill when relevant.

---
user-invocable: false
---

model

Override the model used when this command is active.

---
model: claude-sonnet-4-20250514
---

context

Set to fork to run the command in an isolated subagent context. The command content becomes the prompt that drives the subagent. The subagent has no access to conversation history.

---
context: fork
---

Only use context: fork with commands that have explicit task instructions. Guidelines-only content (like "use these conventions") produces no meaningful output in a subagent.

agent

Specifies which subagent type to use when context: fork is set. Options include built-in agents (Explore, Plan, general-purpose) or custom subagents from .claude/agents/.

---
context: fork
agent: Explore
---

If omitted, defaults to general-purpose.

hooks

Hooks scoped to this command's lifecycle. See the Claude Code hooks documentation for configuration format.

---
hooks:
  pre_tool_call:
    - matcher: Bash
      hooks:
        - command: echo "About to run bash"
          type: command
---

Invocation control matrix (Claude Code)

These settings only affect Claude Code. Other agents treat all skills as default (both user and agent can invoke).

File Locations

Single-file commands

Skill directories

Skills are the recommended format. They support additional files (templates, scripts, reference docs) alongside SKILL.md.

Automatic discovery in monorepos

When editing files in subdirectories, Claude Code also discovers skills from nested .claude/skills/ directories. For example, editing a file in packages/frontend/ also loads skills from packages/frontend/.claude/skills/.

Priority Order

When commands share a name across levels:

1. Enterprise (managed settings) -- highest priority 2. Personal (~/.claude/) 3. Project (.claude/)

Plugin commands use namespacing (plugin-name:skill-name) and never conflict with other levels. If a skill directory and a command file share the same name, the skill takes precedence.

Organizing Commands with Subdirectories

Use subdirectories to categorize project commands:

.claude/commands/
├── git/
│   ├── commit.md          # /commit -> "(project:git)"
│   ├── pr.md              # /pr -> "(project:git)"
│   └── sync.md            # /sync -> "(project:git)"
├── dev/
│   ├── feature.md         # /feature -> "(project:dev)"
│   └── debug.md           # /debug -> "(project:dev)"
└── docs/
    └── update.md          # /update -> "(project:docs)"

The subdirectory name appears in parentheses in /help as (project:subdirectory).

Naming Conventions

Skill Tool Permissions

Claude invokes commands programmatically via the Skill tool. Control access through permission rules:

Character Budget

Skill descriptions consume a shared character budget (default: 15,000 characters). When exceeded, Claude sees fewer commands. Check with /context and increase via the SLASH_COMMAND_TOOL_CHAR_BUDGET environment variable.

Enabling Automatic Invocation

Reference commands in CLAUDE.md to encourage Claude to use them automatically:

When writing tests, run /write-unit-test to generate test files.
After fixing bugs, run /verify-fix to ensure the fix is complete.

This works because Claude reads CLAUDE.md at the start of every session and treats its content as project instructions.

Built-in Commands

These commands are built-in and cannot be overridden:

Run /help in Claude Code for the full list.

Commands vs Skills vs Subagents

Command Templates

Basic Command

Minimal command with description and numbered steps.

---
description: What this command does
---

# Command Name

Brief explanation of purpose.

## Steps

1. First action
2. Second action
3. Final action

## Reference

- Use `cli-command` for specific purpose

Command with Arguments

Accept dynamic input with $ARGUMENTS and argument-hint.

---
description: Review a pull request by number
argument-hint: [PR number]
allowed-tools: Bash(gh:*), Read, Grep, Glob
---

Review pull request #$ARGUMENTS

## Steps

1. Fetch PR details with `gh pr view $ARGUMENTS`
2. Review changed files
3. Check for issues against project conventions
4. Provide structured feedback

## Output Format

Provide:

- Summary of changes
- List of issues found
- Verdict: APPROVE or REQUEST CHANGES

Usage: /review-pr 123

Guardrailed Command

For commands that modify state. Includes safety constraints and explicit boundaries.

---
description: Deploy application to environment
disable-model-invocation: true
argument-hint: [environment]
allowed-tools: Bash(git:*), Bash(pnpm:*), Read
---

Deploy to $ARGUMENTS environment.

## Guardrails

- Do NOT deploy if tests fail
- Do NOT force-push or skip CI checks
- Do NOT modify environment variables without confirmation
- Only deploy from the main branch

## Steps

1. Verify current branch is main
2. Run full test suite
3. Build the application
4. Execute deployment to $ARGUMENTS
5. Verify deployment succeeded

## Rollback

If deployment fails:

1. Revert to previous deployment
2. Report the failure with error details

Usage: /deploy staging

Git Commit Command

Uses bash injection for dynamic context.

---
description: Create a conventional git commit
disable-model-invocation: true
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git status:*), Bash(git diff:*)
argument-hint: [optional message]
---

## Context

- Current status: !`git status`
- Current diff: !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -5`

## Steps

1. Analyze the changes shown above
2. Stage appropriate files (not unrelated changes)
3. Create commit with conventional format: type(scope): description
4. If $ARGUMENTS provided, use it as the commit message basis

## Format

Use conventional commit types: feat, fix, docs, style, refactor, perf, test, chore

Multi-Phase Command

Complex workflows with distinct phases. Consider using context: fork for isolation.

---
description: Complete feature development workflow
disable-model-invocation: true
argument-hint: [feature name]
---

# Feature Development: $ARGUMENTS

## Phase 1: Planning

1. Understand the requirement for $ARGUMENTS
2. Identify affected files and components
3. Create implementation plan

## Phase 2: Implementation

1. Create or modify necessary files
2. Follow project conventions
3. Add appropriate tests

## Phase 3: Verification

1. Run type checking
2. Run linting
3. Run tests
4. Verify no regressions

## Phase 4: Documentation

1. Update relevant documentation
2. Add inline comments only where non-obvious

## Output

Provide a summary of all changes made across phases.

Code Review Command

Combines bash injection with structured output.

---
description: Review staged changes before commit
allowed-tools: Bash(git:*), Read, Grep, Glob
---

## Context

- Staged changes: !`git diff --cached`
- Modified files: !`git diff --cached --name-only`

## Steps

1. Review each changed file for correctness
2. Check against project conventions
3. Look for common issues: missing error handling, type safety, edge cases
4. Provide structured feedback

## Output

For each file, report:

- Status: OK or NEEDS CHANGES
- Issues found (if any)
- Overall verdict: READY TO COMMIT or NEEDS CHANGES

Debug Helper Command

Accepts error context and provides structured analysis.

---
description: Help debug an error message or failing code
argument-hint: [error message or file:line]
---

Debug: $ARGUMENTS

## Steps

1. Parse the error location from the arguments
2. Read the relevant file and surrounding context
3. Search for related code patterns
4. Identify potential root causes
5. Suggest specific fixes

## Output

Provide:

- Parsed error details
- Root cause analysis
- Specific code fix with explanation

Read-Only Explorer

Restricts tools to prevent modifications.

---
description: Explore and explain code without making changes
allowed-tools: Read, Grep, Glob
argument-hint: [file or pattern]
---

Explore $ARGUMENTS without making any changes.

## Steps

1. Find relevant files matching $ARGUMENTS
2. Read and analyze the code
3. Trace data flow and dependencies
4. Explain the architecture

## Output

Provide:

- File structure overview
- Key components and their responsibilities
- Data flow diagram (ASCII)
- Notable patterns or concerns

Forked Research Command

Runs in an isolated subagent for focused exploration.

---
description: Research a topic in the codebase
context: fork
agent: Explore
argument-hint: [topic]
---

Research $ARGUMENTS thoroughly in this codebase.

## Steps

1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Trace usage patterns and dependencies
4. Map the architecture

## Output

Summarize findings with specific file references:

- Where the feature lives
- How it works
- Key dependencies
- Potential improvements

Component Generator

Uses file references for pattern consistency.

---
description: Generate a new component following project patterns
disable-model-invocation: true
argument-hint: [component-name]
---

Create a new component named $ARGUMENTS.

## Reference Pattern

Use the existing component structure from the project.

## Steps

1. Determine the appropriate directory for the new component
2. Create the component file with proper TypeScript types
3. Create a test file following existing test patterns
4. Export from the nearest index file
5. Verify types and lint pass

## Conventions

- PascalCase for component names and files
- Props interface named `${ComponentName}Props`
- Colocate tests as `component-name.test.tsx`

Best Practices

Clear Steps

Use bold labels for phases in numbered steps:

## Steps

1. **Analyze** - Examine the current state
2. **Plan** - Determine necessary changes
3. **Execute** - Make the changes
4. **Verify** - Confirm success

Include Reference Commands

Tell Claude which CLI tools to use:

## Reference

- Use `gh pr view` to inspect PR details
- Use `git diff` to see changes
- Use `pnpm test` to verify no regressions

Provide Output Format

Specify the expected structure of results:

## Output Format

\`\`\`markdown

## Result

**Status**: [Success/Failure]
**Changes Made**:

- [Change 1]
- [Change 2]

**Next Steps**:

- [Recommendation]
  \`\`\`

Use File References

Reference project files with @ for context:

Review the implementation considering:

- Main file: @src/utils/helpers.ts
- Tests: @src/utils/helpers.test.ts
- Types: @src/types/helpers.d.ts

Checklist for New Commands

When creating a command, verify:

1. File location matches intended scope (project vs personal) 2. description frontmatter is present 3. Steps are numbered and actionable 4. $ARGUMENTS handled for empty case (if used) 5. allowed-tools included when using ` !bash injection 6. All code blocks have language specifiers 7. Guardrails section included for state-changing commands 8. disable-model-invocation: true` set for side-effect commands 9. Output format specified when structured output is expected