--- description: Analyze changes, create a git-flow style commit message, commit, and push to remote. argument-hint: "[--no-push] [--scope ] [--type ]" allowed-tools: [Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git push:*), Bash(git branch:*), Bash(git log:*), Bash(git rev-parse:*)] --- # Git Commit with Git-Flow Style You are a Claude Code slash command that creates git-flow style commit messages and pushes changes to the remote repository. Follow the protocol below exactly, using only the allowed tools. ## Inputs Parse the arguments provided to this command (`$ARGUMENTS`) and support these flags: - `--no-push`: do not push after committing. - `--scope `: optional scope for the commit message (e.g., "auth", "api", "ui"). - `--type `: force a specific commit type instead of auto-detecting (e.g., "feat", "fix", "docs"). ## Git-Flow Commit Types Use these conventional commit types: - `feat`: A new feature - `fix`: A bug fix - `docs`: Documentation only changes - `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) - `refactor`: A code change that neither fixes a bug nor adds a feature - `perf`: A code change that improves performance - `test`: Adding missing tests or correcting existing tests - `chore`: Changes to the build process or auxiliary tools and libraries such as documentation generation - `ci`: Changes to CI configuration files and scripts ## Protocol ### 1. Context Gathering Use Bash to collect repository context: - Current branch: `git branch --show-current` - Working tree status: `git status --porcelain` and `git status -sb` - Staged changes: `git diff --cached --stat` - Unstaged changes: `git diff --stat` - Recent commit messages: `git log --oneline -5` (to understand commit style) ### 2. Change Analysis Analyze the changes to determine: 1. **Commit type**: Automatically detect based on files changed and diff content: - New features → `feat` - Bug fixes → `fix` - Documentation changes (*.md, docs/, README) → `docs` - Test files (*.test.*, *.spec.*, __tests__/) → `test` - Configuration files (.github/, *.config.*, *.json) → `chore` or `ci` - Refactoring without behavior change → `refactor` - Performance improvements → `perf` - Formatting only → `style` 2. **Scope**: Suggest a scope based on: - Directory name (e.g., "packages/auth" → scope: "auth") - Module name - Feature area - If scope is broad or unclear, omit it 3. **Subject**: Create a concise description (max 72 chars, imperative mood, no period at end) 4. **Body**: Optional detailed explanation (wrap at 72 chars): - What was changed and why - Important implementation details - Breaking changes should be noted ### 3. Stage Unstaged Files If there are unstaged changes: 1. Show the list of unstaged files 2. Ask the user which files to stage (or use `git add .` for all) 3. Stage the selected files using `git add` ### 4. Secret Scanning Scan the staged diff for potential secrets: - API keys (patterns like `AKIA`, `ghp_`, `sk-`, etc.) - Private keys (BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY) - Tokens and passwords - Environment files (.env) with sensitive data If suspicious content is found: - Show a warning with masked snippets - Ask for confirmation to proceed - Default to cancel if user doesn't explicitly confirm ### 5. Compose Commit Message Create a commit message following git-flow format: ``` ():