---
name: commit-message
description: Create git commit messages based on current staged changes. Has support for git emoji messages.
---

# Git Commit Message

## Instructions

When this skill is invoked, follow these steps:

1. **Check if there are staged changes**: Run `git status`
2. If the output of `git status` contains `Changes not staged for commit`, then:
   - Generate an interactive yes/no prompt artifact asking "You have unstaged changes. Would you like me to stage your changes?"
   - Upon confirmation, proceed by adding the staged changes
3. If the output of `git status` contains `nothing to commit, working tree clean`, then:
   - Display response to the user: "No changes found. Please make changes to your files before trying to commit."
   - Stop and exit the skill.
4. Only proceed if all changes have been staged, and there are no unstaged changes.
5. Get details of staged changes: Run `git diff --cached` to get the details of the staged changes. Review the diff output to understand:
   - What files were modified
   - What functionality changed
   - The purpose and impact of the changes
6. **Check current branch**: Run `git branch --show-current` to determine the current branch.
   - If the current branch is `main` or `master` or `dev` or `development`:
     - Using the staged changes already retrieved in step 5, determine the appropriate branch type and a short task description
     - Generate a branch name in the format `<type>/<task-description>` (see **Branch Naming Format** section below). Be specific rather than generic in branch name, ie `feature/switch-to-branch` instead of `feature/update-commit-skill`
     - Inform the user they are committing directly to the mainline branch
     - Generate an interactive yes/no prompt artifact asking "You're on the `<branch>` branch. Would you like me to create the branch `<suggested-branch-name>` for this commit?" with the suggested branch name filled in
     - Upon confirmation, create and switch to the new branch using `git switch -c <branch-name>`
     - If the user declines, continue committing on the current branch
7. Determine emoji usage:
   - Search the user's original request for keywords like "emoji", "gitmoji", "with emoji", or "use emoji"
   - By default (if no emoji keywords found): Generate the commit message in standard format WITHOUT any emojis
   - If the user explicitly asks for emojis: Add emojis using the mapping table below, placing the emoji before the type
8. Generate commit message: Create a commit message following the semantic commit format below, ensuring:
   - Appropriate commit type (feat, fix, docs, etc.)
   - Only put a gitmoji in first line if user specified gitmoji or emoji
   - Relevant scope based on affected codebase area
   - Clear, imperative subject line under 50 characters
   - Body and footer if needed for complex changes
   - Add line breaks in the body if there are multiple sentences.
9. Present to user for commit approval:
   - Display the formatted commit message for review (without showing the git command)
   - Generate an interactive yes/no prompt artifact asking "Would you like me to create this commit?"
   - Upon confirmation, proceed to step 10
10. **Final branch check before committing**: Run `git branch --show-current` one final time before executing the commit.
    - If the current branch is still `main` or `master` or `dev` or `development`:
      - Warn the user: "You are about to commit directly to `<branch>`. Are you sure?"
      - Generate an interactive yes/no prompt artifact asking "Commit directly to `<branch>`?"
      - Upon confirmation, proceed to create the commit
      - If the user declines, stop and ask them to create a new branch before committing
    - If the current branch is not a mainline branch, proceed to create the commit
11. Present to user for push confirmation:
   - Once the commit is created, generate an interactive yes/no prompt asking "Would you like me to push this to the remote?"
   - Upon confirmation, proceed with the push operation

## Commands to get details of staged changes

**Note**: `git diff --cached` and `git diff --staged` are equivalent commands - both show staged changes.

### Show which files are staged, modified, or untracked

git status

### Show detailed line-by-line changes in staged files

git diff --staged

### Show summary of staged changes with file names and line counts

git diff --staged --stat

### Show detailed changes for a specific staged file

git diff --staged path/to/file

## Commit Message Format

The basic semantic message format is:

```text
<type>(<scope>): <subject>

<body>

<footer>
```

Where:

- `<type>`: The type of change (see list below)
- `<scope>`: Optional, the area of codebase affected
- `<subject>`: Brief description in imperative mood
- `<body>`: Optional, detailed explanation
- `<footer>`: Optional, references to issues or breaking changes

### Commit Types

The most common types are:

- feat: A new feature
- fix: A bug fix
- docs: Documentation changes
- style: Changes that don't affect code meaning (formatting, semicolons, etc.)
- refactor: Code changes that neither fix bugs nor add features
- perf: Changes that improve performance
- test: Adding or updating tests
- chore: Changes to build process, dependencies, or tooling

Scope is optional and specifies which part of the codebase is affected, like feat(auth): add login validation or fix(api): handle null responses.

Subject is a short, imperative description—start with a verb and keep it under 50 characters. Use present tense: "add feature" not "added feature."

Body is optional but useful for longer commits. It explains the why and what in more detail, usually wrapped at 72 characters. Separate it from the subject with a blank line.

Footer is optional and often used for referencing issues: Closes #123 or Fixes #456.

A practical example:
feat(checkout): add paypal payment option

- Added integration with PayPal's API
- Implemented error handling

Closes #234

## Branch Naming Format

When creating a branch, use the following format:

```text
<type>/<task-description>
```

Where:

- `<type>`: One of the branch types listed below
- `<task-description>`: A short hyphenated description of the task (3-4 words max, use hyphens instead of spaces)

### Branch Types

| Type     | Usage                                                            |
| -------- | ---------------------------------------------------------------- |
| feature  | New feature for the user                                         |
| fix      | Bug fix for the user                                             |
| docs     | Documentation changes                                            |
| style    | Formatting, missing semicolons, etc.                             |
| refactor | Refactoring production code                                      |
| test     | Adding missing tests, refactoring tests                          |
| chore    | Updating grunt tasks, nothing that an external user would see    |

### Example Branch Names

- `feature/add-user-auth`
- `fix/null-response-handling`
- `docs/update-install-guide`
- `style/reformat-buttons`
- `refactor/simplify-data-logic`
- `test/add-edge-cases`
- `chore/upgrade-dependencies`

## Git Emoji Messages

**Only use emojis when explicitly requested by the user.**

When emojis are requested, place the emoji at the start of the commit message, before the type. Format:

```text
<emoji> <type>(<scope>): <subject>
```

### Emoji Mappings to Types

| Type     | Emoji |
| -------- | ----- |
| feat     | ✨    |
| fix      | 🐛    |
| docs     | 📚    |
| style    | 💄    |
| refactor | ♻️    |
| perf     | ⚡    |
| test     | ✅    |
| chore    | 🔨    |
| ci       | 👷    |
| build    | 📦    |
| revert   | ⏮️    |
| security | 🔒    |
| deps     | 📦    |

**Example commit messages with emojis:**

✨ feat(auth): add two-factor authentication
🐛 fix(api): handle null responses correctly
📚 docs: update installation guide
💄 style(ui): reformat button component
♻️ refactor(core): simplify data processing logic
⚡ perf(database): optimize query performance
✅ test(utils): add edge case tests
🔨 chore: upgrade dependencies
👷 ci: add GitHub Actions workflow
📦 build: update webpack config
🔒 security: patch XSS vulnerability

## Guidelines for Commit Messages

When generating commit messages, follow these rules:

- ensure the subject line is lowercase only
- **Keep the first line under 50 characters** for better readability in git logs
- **Be descriptive rather than technical**: Explain what changed from a functional perspective, not implementation details
- **List changes in bullet form**, 1 item per line rather than writing long sentences. Keep bullets to 6 points or less.
- **Use imperative mood**: "add feature" not "added feature" or "adds feature"
- **Include scope when relevant**: Helps identify which part of the codebase is affected
- **Add body for additional context**: Explain the why and what in more detail when the subject alone isn't sufficient
- **Reference issues in footer**: Use "Closes #123" or "Fixes #456" when applicable

## Output Format

When presenting the generated commit message to the user, use this format:

```markdown
Here's the suggested commit message based on your staged changes:

​`
<generated commit message>
​`
```

## Important Notes

- Do not run `git commit` or `git push` without user approval
- Do not add Co-Authored-By trailers: Commits should only show the user as the author. Never add "Co-Authored-By: Claude Sonnet <noreply@anthropic.com>" or any similar co-author trailers to commit messages
- Analyze all staged files: If there are many staged files, review each one to ensure the commit message accurately reflects all changes