|
| 1 | +--- |
| 2 | +name: commit |
| 3 | +description: >- |
| 4 | + Create git commits following Conventional Commits. Use when committing |
| 5 | + changes, staging files, or creating commit messages. |
| 6 | +allowed-tools: Bash(git:*) |
| 7 | +metadata: |
| 8 | + author: cpplain |
| 9 | + version: "1.4" |
| 10 | +--- |
| 11 | + |
| 12 | +# Commit |
| 13 | + |
| 14 | +Create commits following [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), unless the repo specifies another format. |
| 15 | + |
| 16 | +## Check for Repo-Specific Format |
| 17 | + |
| 18 | +Before composing a commit message, check for overriding conventions: |
| 19 | + |
| 20 | +1. `commitlint.config.*` or `.commitlintrc*` (commitlint rules) |
| 21 | +2. `.gitmessage` (commit template) |
| 22 | +3. `CONTRIBUTING.md` (commit guidelines section) |
| 23 | + |
| 24 | +If found, follow the repo's format instead. |
| 25 | + |
| 26 | +## Commit Message Format |
| 27 | + |
| 28 | +``` |
| 29 | +<type>[(<scope>)][!]: <description> |
| 30 | +
|
| 31 | +[optional body] |
| 32 | +
|
| 33 | +[optional footer(s)] |
| 34 | +``` |
| 35 | + |
| 36 | +### Types |
| 37 | + |
| 38 | +| Type | Purpose | |
| 39 | +| ---------- | ------------------------------------------------------- | |
| 40 | +| `feat` | New feature | |
| 41 | +| `fix` | Bug fix | |
| 42 | +| `docs` | Documentation only | |
| 43 | +| `style` | Formatting, whitespace (not CSS) | |
| 44 | +| `refactor` | Code change that neither fixes a bug nor adds a feature | |
| 45 | +| `perf` | Performance improvement | |
| 46 | +| `test` | Adding or updating tests | |
| 47 | +| `build` | Build system or external dependencies | |
| 48 | +| `ci` | CI configuration and scripts | |
| 49 | +| `chore` | Other changes that don't modify src or test files | |
| 50 | +| `revert` | Reverts a previous commit | |
| 51 | + |
| 52 | +### Description |
| 53 | + |
| 54 | +- Use imperative mood ("add feature" not "added feature") |
| 55 | +- Lowercase first letter |
| 56 | +- No period at the end |
| 57 | + |
| 58 | +### Scope |
| 59 | + |
| 60 | +Module or area affected — derive from the primary area of change using singular, lowercase names (e.g., `auth`, `api`, `parser`). Omit for cross-cutting changes. |
| 61 | + |
| 62 | +### Breaking Changes |
| 63 | + |
| 64 | +Indicate breaking changes in either (or both) of two ways: |
| 65 | + |
| 66 | +- Append `!` after type/scope: `feat(api)!: remove deprecated endpoints` |
| 67 | +- Add a `BREAKING CHANGE:` footer: `BREAKING CHANGE: response format changed from XML to JSON` |
| 68 | +- `BREAKING CHANGE` must be uppercase; `BREAKING-CHANGE` is also accepted as a footer token |
| 69 | + |
| 70 | +### Body and Footers |
| 71 | + |
| 72 | +- Separate the body from the description with a blank line |
| 73 | +- The body can contain multiple paragraphs separated by blank lines |
| 74 | +- Use the body to explain **why** the change was made when the description alone isn't sufficient |
| 75 | +- Footers use the `token: value` or `token #value` format (e.g., `Refs: #123`, `Reviewed-by: Name`) |
| 76 | +- Footer tokens must use `-` instead of spaces (e.g., `Reviewed-by` not `Reviewed by`); `BREAKING CHANGE` is the sole exception |
| 77 | + |
| 78 | +## Workflow |
| 79 | + |
| 80 | +1. Run `git status` and `git diff --staged` to understand what is being committed |
| 81 | +2. If nothing is staged, identify the relevant files and stage them with `git add <file>...` (prefer explicit paths over `git add -A`) |
| 82 | +3. Run `git log --oneline -5` to see recent commit style for scope and type consistency |
| 83 | +4. Compose the commit message following the format above |
| 84 | +5. Commit using a heredoc for multi-line messages: |
| 85 | + |
| 86 | +```bash |
| 87 | +git commit -m "$(cat <<'EOF' |
| 88 | +type(scope): description |
| 89 | +
|
| 90 | +Body text here. |
| 91 | +
|
| 92 | +Footer: value |
| 93 | +EOF |
| 94 | +)" |
| 95 | +``` |
0 commit comments