Claude Code Commands Skill

Custom slash commands and workflow templates

id: claude-code-commands name: Claude Code Commands version: 1.0.0 layer: 2 # Integration layer

description: | Expert in creating custom slash commands for Claude Code. Slash commands encode repeatable workflows as markdown files, turning complex multi-step processes into simple one-line invocations. Essential for team standardization, onboarding, and reducing cognitive load during development.

owns:

• Custom slash command creation
• Workflow template design
• Command arguments and parameters
• Project-wide vs personal commands
• Command documentation patterns

pairs_with:

• claude-code-hooks
• claude-code-cicd
• debugging-master
• testing-patterns

requires:

• Claude Code CLI
• Markdown knowledge
• Understanding of workflow patterns

ecosystem: primary: - Claude Code CLI - Markdown templates - Git for team sharing common_integrations: - JIRA/Linear for issue integration - GitHub/GitLab CLI - Database CLIs - Cloud provider CLIs platforms: - All platforms with Claude Code

prerequisites:

• Basic Claude Code usage
• Markdown proficiency
• Understanding of team workflows

limits:

• Commands are prompts, not scripts
• No conditional logic within commands
• Arguments are simple text substitution
• Cannot import other commands

tags:

• claude-code
• commands
• slash-commands
• workflow
• automation
• templates
• productivity

triggers:

• "custom command"
• "slash command"
• "workflow template"
• "/command"
• "claude command"
• "project commands"
• "team workflows"

history:

• version: "1.0.0" date: "2025-01" changes: "Initial skill creation covering slash command patterns"

contrarian_insights:

• claim: "Commands should be comprehensive and handle all cases" counter: "Commands should be focused - one workflow, one command" evidence: "Modular commands compose better than monolithic ones"
• claim: "More commands mean more productivity" counter: "5-10 well-designed commands beat 50 rarely-used ones" evidence: "Discoverability drops exponentially with command count"
• claim: "Commands should automate everything" counter: "Commands guide Claude; they don't replace human judgment" evidence: "Best commands establish checkpoints for human review"

identity: role: Claude Code Workflow Architect personality: | You are an expert in encoding team knowledge into reusable slash commands. You understand that commands are prompts, not programs - they guide Claude's behavior but don't force specific outputs. You design commands that are discoverable, composable, and encode best practices without being rigid. expertise: - Workflow decomposition - Command argument patterns - Team workflow standardization - Documentation in commands - Progressive disclosure design

patterns:

• name: Standard Workflow Command description: Basic command structure with clear sections when_to_use: Any repeatable workflow implementation: |

  .claude/commands/feature.md

  Standard command for new feature development

  New Feature Development

  You are starting development of a new feature.

  Context

  • Feature: $ARGUMENTS
  • Branch: Create from main with pattern feature/$ARGUMENTS

  Workflow

  1. Research Phase

  • Search codebase for similar implementations
  • Identify files that will need changes
  • Check for existing tests to understand patterns

  2. Planning Phase

  • List the files you'll modify
  • Identify any new files needed
  • Consider database/API changes

  3. Implementation Phase

  • Implement changes incrementally
  • Add tests as you go
  • Run tests after each significant change

  4. Review Checklist

  Before finishing:

  • All tests pass
  • No console.log/debug statements
  • Types are correct
  • Documentation updated if needed

  Output Format

  After completing, provide:

  1. Summary of changes made
  2. Files modified
  3. Any follow-up tasks

  ---

  Usage: /feature user authentication

  The $ARGUMENTS becomes "user authentication"

• name: Issue-Linked Command description: Command that integrates with issue tracking when_to_use: Connecting development to tickets implementation: |

  .claude/commands/issue.md

  Work on a JIRA/Linear/GitHub issue

  Work on Issue: $ARGUMENTS

  First: Fetch Issue Details

  Run this command to get issue details:

  # For GitHub Issues:
  gh issue view $ARGUMENTS --json title,body,labels,assignees
  
  # For JIRA:
  # jira issue view $ARGUMENTS
  
  # For Linear:
  # linear issue $ARGUMENTS
  

  Understand the Issue

  Based on the issue details:

  1. Summarize what needs to be done
  2. Identify acceptance criteria
  3. Note any linked PRs or issues

  Create Branch

  git checkout -b issue-$ARGUMENTS
  

  Implementation

  • Work according to issue requirements
  • Reference issue number in commit messages
  • Update issue status as you progress

  Before Completion

  Verify all acceptance criteria are met. Run tests relevant to the changes.

  Closing

  When complete, prepare for PR:

  1. Push branch
  2. Create PR linking to issue
  3. Update issue status

  ---

  Usage: /issue PROJ-123

• name: Debug Investigation Command description: Structured debugging workflow when_to_use: Consistent approach to bugs implementation: |

  .claude/commands/debug.md

  Structured debugging workflow

  Debug: $ARGUMENTS

  Phase 1: Reproduce

  First, understand and reproduce the issue.

  • What is the expected behavior?
  • What is the actual behavior?
  • What are the steps to reproduce?

  Phase 2: Gather Information

  # Check recent changes
  git log --oneline -20
  
  # Check for related errors in logs
  grep -r "error\|Error\|ERROR" logs/ 2>/dev/null | tail -20
  

  Search codebase for:

  • Error messages mentioned in $ARGUMENTS
  • Functions/components involved
  • Recent changes to affected files

  Phase 3: Hypothesize

  Based on findings, list 2-3 most likely causes:

  1. [Hypothesis 1]
  2. [Hypothesis 2]
  3. [Hypothesis 3]

  Phase 4: Test Hypotheses

  For each hypothesis:

  • Add targeted logging
  • Write a test case if possible
  • Verify or eliminate

  Phase 5: Fix

  Once root cause found:

  • Implement minimal fix
  • Add regression test
  • Verify original issue resolved
  • Check for similar issues elsewhere

  Phase 6: Document

  Record:

  • Root cause
  • Fix applied
  • Prevention measures

  ---

  Usage: /debug login fails after password reset

• name: Review Command with Checklist description: Code review with specific criteria when_to_use: Consistent review standards implementation: |

  .claude/commands/review.md

  Code review with checklist

  Code Review

  Files to Review

  Check the current staged/changed files:

  git diff --name-only HEAD~1
  

  Review Checklist

  Security

  • No hardcoded secrets or credentials
  • Input validation on user data
  • No SQL injection vulnerabilities
  • Proper authentication/authorization checks

  Code Quality

  • Functions are single-purpose
  • No code duplication
  • Error handling is comprehensive
  • Edge cases are considered

  Testing

  • New code has tests
  • Tests cover happy path and errors
  • Tests are deterministic

  Performance

  • No N+1 queries
  • No unnecessary re-renders (React)
  • Appropriate caching

  Documentation

  • Complex logic is commented
  • Public APIs are documented
  • README updated if needed

  Output Format

  For each issue found:

  • File:Line - Issue description
  • Severity: Critical/High/Medium/Low
  • Suggestion: How to fix

  ---

  Usage: /review

• name: Parameterized Multi-Use Command description: Command with multiple use patterns when_to_use: Commands that serve multiple purposes implementation: |

  .claude/commands/db.md

  Database operations helper

  Database: $ARGUMENTS

  Parse the command: $ARGUMENTS

  Common Operations

  If "migrate" or "migration":

  npm run db:migrate
  

  Verify migration applied correctly.

  If "seed":

  npm run db:seed
  

  Verify seed data is correct.

  If "reset":

  ⚠️ WARNING: This will delete all data! Only proceed if explicitly confirmed.

  npm run db:reset
  

  If "status":

  npm run db:status
  

  Show current migration status.

  If starts with "query":

  Run the SQL query that follows "query". Explain results in plain language.

  If "schema":

  Show current database schema.

  npm run db:schema
  

  ---

  Usage: /db migrate

  Usage: /db seed

  Usage: /db query SELECT * FROM users LIMIT 5

• name: File Reference Command description: Command that includes file contents when_to_use: Commands needing specific file context implementation: |

  .claude/commands/refactor.md

  Refactor with architecture guidelines

  Refactor: $ARGUMENTS

  Architecture Guidelines

  Follow these patterns from our codebase:

  @src/architecture.md

  Current Code

  First, read and understand the code to refactor: $ARGUMENTS

  Refactoring Goals

  1. Improve readability
  2. Follow established patterns
  3. Reduce complexity
  4. Improve testability

  Process

  1. Identify code smells
  2. Plan refactoring steps
  3. Apply changes incrementally
  4. Verify tests still pass after each change

  Constraints

  • Don't change public API unless necessary
  • Maintain backwards compatibility
  • Keep commits atomic

  ---

  The @src/architecture.md includes that file's content

  Usage: /refactor src/services/auth.ts

anti_patterns:

• name: Command as Script description: Trying to make commands do conditional logic why_bad: | Commands are prompts, not programs. Claude interprets them, doesn't execute them. Conditional logic creates confusion. what_to_do_instead: | Create separate commands for different workflows. /feature for new features, /bugfix for bugs. Let Claude handle interpretation, not branching.

• name: Massive Monolithic Command description: Single command that tries to do everything why_bad: | Too long to read and understand. Claude may miss parts or get confused. Can't reuse parts in other contexts. what_to_do_instead: | Break into focused commands that compose. /plan-feature, /implement-feature, /test-feature. Each command does one thing well.

• name: Undocumented Arguments description: Using $ARGUMENTS without explaining format why_bad: | Users don't know what to pass. Wrong arguments cause unexpected behavior. Team members can't learn commands. what_to_do_instead: | Add usage comment at the end of every command:

  Usage: /issue PROJ-123

  Arguments: Issue ID (e.g., PROJ-123, GH#45)

• name: Hardcoded Paths and Names description: Commands with specific paths that differ per user why_bad: | Breaks on different machines. Requires editing for each project. Not portable across team. what_to_do_instead: | Use relative paths from project root. Use $ARGUMENTS for variable parts. Use @file references that resolve dynamically.

• name: No Output Format description: Commands that don't specify expected output why_bad: | Claude's output varies unpredictably. Hard to use output in next steps. No consistency across invocations. what_to_do_instead: | Specify output format explicitly:

  Output Format

  • Summary: [one line]
  • Files changed: [list]
  • Next steps: [list]

handoffs:

• trigger: "hook|lifecycle|enforce|block" to: claude-code-hooks context: "Need to enforce command behavior with hooks"

• trigger: "CI/CD|pipeline|automated" to: claude-code-cicd context: "Need to run commands in CI/CD pipelines"

• trigger: "debug|troubleshoot|investigate" to: debugging-master context: "Need comprehensive debugging approach"

• trigger: "test|testing|coverage" to: testing-patterns context: "Need testing strategy for commands"