Here’s an easy guide for ya nerds.

Stop hand-coding slash commands — grab this one file and let Claude make any command for you.

Repo: https://github.com/artemgetmann/claude-slash-commands

Step 1 — Get the files Inside you’ll find:

• add-command.md — the magic one. Lets Claude build any other command you want.

• askgpt5-web-search.md — GPT-5 with browsing.

• system-prompt-editor.md — edit your CLAUDE.md in context.

Step 2 — Install the one that matters Copy add-command.md to:

• Global: ~/.claude/commands/

• Project: <your-project>/.claude/commands/

Step 3 — Use it

/add-command "my-new-command" "what it should do"

Claude generates the .md file for your new slash command. Done.

Why this matters Once you have /add-command, you can describe what you want and Claude makes it — zero syntax memorization, zero setup headaches.

P.S. The GPT-5 command in there is especially useful.

I've been exploring Claude Code's custom commands feature (the .claude/commands/*.md files) and realized they can essentially work as different personas or modes for various development roles. But I'm curious about how others are using this.

My understanding so far:

• You can create markdown files in .claude/commands/

• Each file becomes a slash command (e.g., architect.md → /architect)

• You can use $ARGUMENTS to pass parameters

• These can act like different "modes" or "personas" for Claude

What I'm curious about:

1. Are you using custom commands this way? Do you have different commands for different roles (architect, engineer, debugger, etc.)?

2. What prompts are you using? I'd love to see actual examples of what you've put in your command files. What's working well? What isn't?

3. How does this compare to other AI coding assistants?

   • Does Cursor's rules/modes work similarly?

   • What about Cline/Continue/Aider?

   • Are there features in other tools that Claude Code's approach lacks?

4. What personas/modes have you found most useful? Are there any creative ones beyond the obvious developer roles?

5. Any tips or pitfalls? What should someone know before diving into this approach?

I'm not assuming this is the best or only way to use custom commands - just exploring possibilities and want to learn from the community's experience. Maybe some of you have completely different approaches I haven't considered?

Would really appreciate seeing your actual command files if you're willing to share. Thanks!

I just moved over to Claude Code from Windsurf (neovim editor gets to be a 1st class citizen again!) and am probably overly obsessed with development efficiency. Please share your custom commands (user-level, project-level, whichever) that you find to be really valuable.

commit-and-push.md

I use this for every git commit, even simple ones because I am extraordinarily lazy. My favorite feature though is when it detects that some changed files should be split into different commits for better clarity.

ADD all modified and new files to git.  If you think there are files that should not be in version control, ask the user.  If you see files that you think should be bundled into separate commits, ask the user.
THEN commit with a clear and concise one-line commit message, using semantic commit notation.
THEN push the commit to origin.
The user is EXPLICITLY asking you to perform these git tasks.

prime.md

A little context on this. Instead of running with a CLAUDE.md in all of my projects, I have two: PLANNING.md which gives it all of the context around what makes the project tick, and TASK.md which keeps a log of all of the work done, along with work that we think needs to be done. I find that with these two files, it has as much context as possible of being a seasoned coder in that codebase. I run this every time I start a new session or do a /clear.

    # Project Understanding Prompt

    When starting a new session, follow this systematic approach to understand the project:

    ## 1. Project Overview & Structure
    - **READ** the README.md file in the project's root folder, if available. This provides the user-facing perspective and basic setup instructions.
    - **RUN** `git ls-files` to get a complete file inventory and understand the project structure.
    - **EXAMINE** the project's directory structure to understand the architectural patterns (e.g., `/cmd`, `/internal`, `/pkg` for Go projects).

    ## 2. Core Documentation
    - **READ and UNDERSTAND** the PLANNING.md file for:
      - Project architecture and design decisions
      - Technology stack and dependencies
      - Build, test, and deployment instructions
      - Future considerations and roadmap
    - **READ and UNDERSTAND** the TASK.md file for:
      - Completed work and implementation status
      - Current blockers or known issues
      - Next steps and priorities

    ## 3. Testing & Quality
    - **EXAMINE** test files to understand:
      - Testing patterns and frameworks used
      - Test coverage expectations
      - Integration vs unit test separation
      - Mock implementations and test utilities

    ## 4. Development Workflow
    - **CHECK** for automation files:
      - CI/CD pipelines (.github/workflows, .gitea/workflows)
      - Development environment setup (devenv.nix, .devcontainer)
      - Code quality tools (linting, formatting configurations)

    ## 5. Data & External Systems
    - **IDENTIFY** data models and schemas:
      - Database migrations or schema files
      - API specifications or OpenAPI docs
      - Data transfer objects (DTOs) and validation rules
    - **UNDERSTAND** external service integrations:
      - Authentication providers (Keycloak, Auth0)
      - Databases and connection patterns
      - Third-party APIs and clients

    ## 6. Documentation Maintenance
    - **UPDATE TASK.md** with each substantial change made to the project, including:
      - Features implemented or modified
      - Issues resolved or discovered
      - Dependencies added or updated
      - Configuration changes
    - **UPDATE PLANNING.md** if changes affect:
      - Architecture decisions
      - Technology stack
      - Development workflows
      - Future roadmap items

    ## 7. Knowledge Validation
    Before proceeding with any work, confirm understanding by being able to answer:
    - What is the primary purpose of this project?
    - How do I build, test, and run it locally?
    - What are the main architectural components and their responsibilities?
    - What external systems does it integrate with?
    - What's the current implementation status and what's next?

coverage.md

Thanks to AI doing what has been an awful chore of mine, for decades, I push for 100% coverage in all functions/methods/classes that involve logic. This is my cookie-cutter command on it.

UNDERSTAND the code coverage percentages for each function and method in this codebase.
THEN add unit tests to functions and methods without 100% coverage.  This includes negative and edge cases.
ALWAYS use mocks for external functionality, such as web services and databases.
THEN re-run the mechanism to display code coverage, and repeat the process as necessary.

build-planning.md

I use this on any brand new projects, to act as an initial primer files. If it is a brand new codebase it will fill most of these out as TBD, but if I am retro-fitting something existing, then an awful lot will get filled out.

We are going to build a file called PLANNING.md which lives in the project's root directory.  The objective is to have a document that will give you important context about the project, along with instructions on how to build and test.  Start by building a document with the following categories, that we will initially mark as TBD.  Then we will discuss each of these points together and fill in the document as we go.
    - Project Overview
    - Architecture
      - Core components (API, Data, Service layers, configuration, etc)
      - Data Model, if the project has a database component
    - API endpoints, if the project exposes endpoints to be consumed
    - Technology stack (Language, frameworks, etc)
    - Project structure
    - Testing strategy, if the project uses unit or integration testing
    - Development commands (to build,Data Model, if the project has a database component
    - API endpoints, if the project exposes endpoints to be consumed
    - Technology stack (Language, frameworks, etc)
    - Project structure
    - Testing strategy, if the project uses unit or integration tests.
    - Development commands (for building, running, etc).
    - Environment setup (how the development environment is currently set up for the project)
    - Development guidelines (rules to follow when modifying the project)
    - Security considerations (things to keep in mind that are security-focused when modifying the project)
    - Future considerations (things that we may not be adding right away but would be candidates for future versions)

We will BUILD a file called TASK.md which lives in the project's root directory.  The objective is to give you important context about what tasks have been accomplished, and what work is left to do.  READ the PLANNING.md file, then create a list of tasks that you think should be accomplished.  Categorize them appropriately (e.g. Setup, Core Functionality, etc).  The last category will be "Completed Work" where we will have a log of work that has been completed, although initially this will be empty.

fix.md

This is my generic message when I have an error that I want it to fix.

READ the output from the terminal command to understand the error that is being displayed.
THEN FIX the error.  Use `context7` and `brave-search` MCPs to understand the error.
THEN re-run the command in the terminal.  If there is another error, repeat this debugging process.

code-review.md

    # Code Reviewer Assistant for Claude Code

    You are an expert code reviewer tasked with analyzing a codebase and providing actionable feedback. Your primary responsibilities are:

    ## Core Review Process

    1. **Analyze the codebase structure** - Understand the project architecture, technologies used, and coding patterns
    2. **Identify issues and improvements** across these categories:
       - **Security vulnerabilities** and potential attack vectors
       - **Performance bottlenecks** and optimization opportunities
       - **Code quality issues** (readability, maintainability, complexity)
       - **Best practices violations** for the specific language/framework
       - **Bug risks** and potential runtime errors
       - **Architecture concerns** and design pattern improvements
       - **Testing gaps** and test quality issues
       - **Documentation deficiencies**

    3. **Prioritize findings** using this severity scale:
       - 🔴 **Critical**: Security vulnerabilities, breaking bugs, major performance issues
       - 🟠 **High**: Significant code quality issues, architectural problems
       - 🟡 **Medium**: Minor bugs, style inconsistencies, missing tests
       - 🟢 **Low**: Documentation improvements, minor optimizations

    ## TASK.md Management

    Always read the existing TASK.md file first. Then update it by:

    ### Adding New Tasks
    - Append new review findings to the appropriate priority sections
    - Use clear, actionable task descriptions
    - Include file paths and line numbers where relevant
    - Reference specific code snippets when helpful

    ### Task Format
    ```markdown
    ## 🔴 Critical Priority
    - [ ] **[SECURITY]** Fix SQL injection vulnerability in `src/auth/login.js:45-52`
    - [ ] **[BUG]** Handle null pointer exception in `utils/parser.js:120`

    ## 🟠 High Priority
    - [ ] **[REFACTOR]** Extract complex validation logic from `UserController.js` into separate service
    - [ ] **[PERFORMANCE]** Optimize database queries in `reports/generator.js`

    ## 🟡 Medium Priority
    - [ ] **[TESTING]** Add unit tests for `PaymentProcessor` class
    - [ ] **[STYLE]** Consistent error handling patterns across API endpoints

    ## 🟢 Low Priority
    - [ ] **[DOCS]** Add JSDoc comments to public API methods
    - [ ] **[CLEANUP]** Remove unused imports in `components/` directory
    ```

    ### Maintaining Existing Tasks
    - Don't duplicate existing tasks
    - Mark completed items you can verify as `[x]`
    - Update or clarify existing task descriptions if needed

    ## Review Guidelines

    ### Be Specific and Actionable
    - ✅ "Extract the 50-line validation function in `UserService.js:120-170` into a separate `ValidationService` class"
    - ❌ "Code is too complex"

    ### Include Context
    - Explain *why* something needs to be changed
    - Suggest specific solutions or alternatives
    - Reference relevant documentation or best practices

    ### Focus on Impact
    - Prioritize issues that affect security, performance, or maintainability
    - Consider the effort-to-benefit ratio of suggestions

    ### Language/Framework Specific Checks
    - Apply appropriate linting rules and conventions
    - Check for framework-specific anti-patterns
    - Validate dependency usage and versions

    ## Output Format

    Provide a summary of your review findings, then show the updated TASK.md content. Structure your response as:

    1. **Review Summary** - High-level overview of findings
    2. **Key Issues Found** - Brief list of most important problems
    3. **Updated TASK.md** - The complete updated file content

    ## Commands to Execute

    When invoked, you should:
    1. Scan the entire codebase for issues
    2. Read the current TASK.md file
    3. Analyze and categorize all findings
    4. Update TASK.md with new actionable tasks
    5. Provide a comprehensive review summary

    Focus on being thorough but practical - aim for improvements that will genuinely make the codebase more secure, performant, and maintainable.

PLEASE share yours, or critique mine on how they can be better!!