README.md

Claude Commands

A collection of commands I find usefull in Claude Code

commit.md

Claude Command: Commit

This command helps you create well-formatted commits with conventional commit messages and emoji.

Usage

To create a commit, just type:

/commit

With options:

/commit --main
/commit --wip
/commit --main --wip

With optional context:

/commit <context>

With both context and options:

/commit <context> --main
/commit <context> --wip
/commit <context> --main --wip

What This Command Does

1. ALWAYS check if on the main branch using Bash(git branch --show-current 2>/dev/null)
2. If we are on main and the --main flag is not set, ALWAYS ask the user if we should switch to a new branch.
3. Checks which files are staged with Bash(git status)
4. If 0 files are staged, automatically adds all modified files with git add .
5. Use @agent-git-diff-analyzer to summarize the current diff unless --wip flag is provided
6. If --wip flag is provided, skips commit splitting analysis and creates a single bulk work-in-progress commit
7. Otherwise analyzes the git-diff-analyzer agent's response to determine if multiple commits are needed
8. If multiple distinct changes are detected (and --wip not used), suggests breaking the commit into multiple smaller commits
9. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format based on the actual diff content
10. If a <context> argument is provided, incorporates the human-supplied context into the commit message generation to provide additional clarity and reasoning for the changes

Best Practices for Commits

• Atomic commits: Each commit should contain related changes that serve a single purpose
• Split large changes: If changes touch multiple concerns, split them into separate commits
• Conventional commit format: Use the format <type>: <description> where type is one of:
  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation changes
  • style: Code style changes (formatting, etc)
  • refactor: Code changes that neither fix bugs nor add features
  • perf: Performance improvements
  • test: Adding or fixing tests
  • chore: Changes to the build process, tools, etc.
• Present tense, imperative mood: Write commit messages as commands (e.g., "add feature" not "added feature")
• Concise first line: Keep the first line under 72 characters
• Emoji: Each commit type is paired with an appropriate emoji:
  • ✨ feat: New feature
  • 🐛 fix: Bug fix
  • 📝 docs: Documentation
  • 💄 style: Formatting/style
  • ♻️ refactor: Code refactoring
  • ⚡️ perf: Performance improvements
  • ✅ test: Tests
  • 🔧 chore: Tooling, configuration
  • 🚀 ci: CI/CD improvements
  • 🗑️ revert: Reverting changes
  • 🧪 test: Add a failing test
  • 🚨 fix: Fix compiler/linter warnings
  • 🔒️ fix: Fix security issues
  • 👥 chore: Add or update contributors
  • 🚚 refactor: Move or rename resources
  • 🏗️ refactor: Make architectural changes
  • 🔀 chore: Merge branches
  • 📦️ chore: Add or update compiled files or packages
  • ➕ chore: Add a dependency
  • ➖ chore: Remove a dependency
  • 🌱 chore: Add or update seed files
  • 👩🏻‍💻 chore: Improve developer experience
  • 🧵 feat: Add or update code related to multithreading or concurrency
  • 🔍️ feat: Improve SEO
  • 🏷️ feat: Add or update types
  • 💬 feat: Add or update text and literals
  • 🌐 feat: Internationalization and localization
  • 👔 feat: Add or update business logic
  • 📱 feat: Work on responsive design
  • 🚸 feat: Improve user experience / usability
  • 🩹 fix: Simple fix for a non-critical issue
  • 🥅 fix: Catch errors
  • 👽️ fix: Update code due to external API changes
  • 🔥 fix: Remove code or files
  • 🎨 style: Improve structure/format of the code
  • 🚑️ fix: Critical hotfix
  • 🎉 chore: Begin a project
  • 🔖 chore: Release/Version tags
  • 🚧 wip: Work in progress
  • 💚 fix: Fix CI build
  • 📌 chore: Pin dependencies to specific versions
  • 👷 ci: Add or update CI build system
  • 📈 feat: Add or update analytics or tracking code
  • ✏️ fix: Fix typos
  • ⏪️ revert: Revert changes
  • 📄 chore: Add or update license
  • 💥 feat: Introduce breaking changes
  • 🍱 assets: Add or update assets
  • ♿️ feat: Improve accessibility
  • 💡 docs: Add or update comments in source code
  • 🗃️ db: Perform database related changes
  • 🔊 feat: Add or update logs
  • 🔇 fix: Remove logs
  • 🤡 test: Mock things
  • 🥚 feat: Add or update an easter egg
  • 🙈 chore: Add or update .gitignore file
  • 📸 test: Add or update snapshots
  • ⚗️ experiment: Perform experiments
  • 🚩 feat: Add, update, or remove feature flags
  • 💫 ui: Add or update animations and transitions
  • ⚰️ refactor: Remove dead code
  • 🦺 feat: Add or update code related to validation
  • ✈️ feat: Improve offline support

Guidelines for Splitting Commits

When analyzing the diff, consider splitting commits based on these criteria:

1. Different concerns: Changes to unrelated parts of the codebase
2. Different types of changes: Mixing features, fixes, refactoring, etc.
3. File patterns: Changes to different types of files (e.g., source code vs documentation)
4. Logical grouping: Changes that would be easier to understand or review separately
5. Size: Very large changes that would be clearer if broken down

Examples

Good commit messages:

• ✨ feat: add user authentication system
• 🐛 fix: resolve memory leak in rendering process
• 📝 docs: update API documentation with new endpoints
• ♻️ refactor: simplify error handling logic in parser
• 🚨 fix: resolve linter warnings in component files
• 🧑‍💻 chore: improve developer tooling setup process
• 👔 feat: implement business logic for transaction validation
• 🩹 fix: address minor styling inconsistency in header
• 🚑️ fix: patch critical security vulnerability in auth flow
• 🎨 style: reorganize component structure for better readability
• 🔥 fix: remove deprecated legacy code
• 🦺 feat: add input validation for user registration form
• 💚 fix: resolve failing CI pipeline tests
• 📈 feat: implement analytics tracking for user engagement
• 🔒️ fix: strengthen authentication password requirements
• ♿️ feat: improve form accessibility for screen readers

Example of splitting commits:

• First commit: ✨ feat: add new solc version type definitions
• Second commit: 📝 docs: update documentation for new solc versions
• Third commit: 🔧 chore: update package.json dependencies
• Fourth commit: 🏷️ feat: add type definitions for new API endpoints
• Fifth commit: 🧵 feat: improve concurrency handling in worker threads
• Sixth commit: 🚨 fix: resolve linting issues in new code
• Seventh commit: ✅ test: add unit tests for new solc version features
• Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities

Context Argument

The optional <context> argument allows you to provide additional human insight about:

• The business reasoning behind the changes
• Background context that may not be obvious from the code diff
• External factors that influenced the implementation
• Links to related issues, tickets, or discussions
• Performance or architectural considerations

This context will be incorporated into the commit message to provide future developers (including yourself) with better understanding of why changes were made.

Command Options

• --main: Commits directly to the main branch without switching to a new branch
• --wip: Creates a single bulk work-in-progress commit with all changes, skipping commit splitting analysis. The commit message will include a note indicating it's a bulk WIP commit.

Important Notes

• If specific files are already staged, the command will only commit those files
• The commit message will be constructed based on the actual diff content, not conversation context
• Always examine the full git diff --staged output to understand what is actually being committed
• When --wip is not used, the command will review the diff to identify if multiple commits would be more appropriate
• If suggesting multiple commits, it will help you stage and commit the changes separately
• Always reviews the commit diff to ensure the message accurately reflects the actual code changes

create-pr.md

Claude Command: Create PR

Create a draft GitHub pull request using the GitHub CLI. This command analyzes the current branch changes, creates an appropriate PR title and description following the established guidelines, and opens a draft PR.

Instructions

1. Check the current git status and branch information
2. Analyze all commits that will be included in the PR (from base branch divergence to HEAD)
3. Check if a GitHub PR template exists in the repository (.github/pull_request_template.md or .github/PULL_REQUEST_TEMPLATE.md)
4. Create a PR title in Title Case that summarizes the changes
5. Generate a description that:
   • Uses the GitHub PR template if available
   • Otherwise follows the CLAUDE.md formatting rules:
     • Describes changes in paragraph form (avoid bullet points unless necessary)
     • Focuses on the "why" rather than "how"
     • Assumes reader has deep codebase understanding
     • Uses backticks for code references
     • Uses sentence case for body text
     • Don't include information other than descriptions of changes
6. Create the branch using ms/<branch-name> format if not already done
7. Push the branch to remote if needed
8. Use gh pr create --draft to create ONLY a draft PR
9. Include the Claude Code signature in the PR description

Example Usage

/create-pr

This will analyze the current branch and create a draft PR with an appropriate title and description based on the changes made.