|
| 1 | +--- |
| 2 | +allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git log:*), Bash(git diff:*), Bash(git branch:*) |
| 3 | +description: Create a git commit |
| 4 | +--- |
| 5 | + |
| 6 | +# Git Commit Message Guidelines |
| 7 | + |
| 8 | +Create a git commit message following these rules: |
| 9 | + |
| 10 | +## The Seven Rules |
| 11 | + |
| 12 | +1. Separate subject from body with a blank line |
| 13 | +2. Limit the subject line to 50 characters |
| 14 | +3. Use conventional commit spec for subject line |
| 15 | +4. Do not end the subject line with a period |
| 16 | +5. Use the imperative mood in the subject line |
| 17 | +6. Wrap the body at 72 characters |
| 18 | +7. Use the body to explain what and why vs. how |
| 19 | + |
| 20 | +## Format |
| 21 | + |
| 22 | +```txt |
| 23 | +<type>: <subject - max 50 chars total, imperative mood, conventional commit spec> <Body - wrapped at 72 chars, explains what and why> <Optional bullet points for clarity> <Optional "Issue $ARGUMENTS" if provided> |
| 24 | +``` |
| 25 | + |
| 26 | +## Conventional Commits |
| 27 | + |
| 28 | +- Use conventional commits spec with types: feat, fix, refactor, docs, test, chore, style, perf, ci, build |
| 29 | +- Format: `<type>: <description>` |
| 30 | +- Examples: "feat: add user authentication", "fix: resolve memory leak in cache" |
| 31 | +- Use "feat" only on user-facing changes |
| 32 | + |
| 33 | +## Subject Line |
| 34 | + |
| 35 | +- Write as if completing: "If applied, this commit will..." |
| 36 | +- Include type prefix (conventional commits) |
| 37 | +- Total length max 50 chars including type |
| 38 | +- Examples: "refactor: simplify cache handling", "fix: prevent race condition" |
| 39 | +- NOT: "refactored cache", "fixed the race" |
| 40 | + |
| 41 | +## Body |
| 42 | + |
| 43 | +- Explain the motivation for the change |
| 44 | +- Explain the "what" and "why" vs. "how" which means: |
| 45 | + - the way things worked before the change (and what was wrong with that), |
| 46 | + - the way they work now, |
| 47 | + - and why the contributor decided to solve it the way they did, |
| 48 | + - and if you're not sure about the "why" then ask the contributor. |
| 49 | +- Focus on context, not implementation details |
| 50 | +- Find a balance for message length, i.e. analyze the diff and decide if a shorter message is enough or more explanation is needed |
| 51 | +- Don't overuse bullet points (-, \*, +), add them only in bigger commits if (and only if) they are helpful |
| 52 | +- Keep it short if there aren't many changes |
| 53 | + |
| 54 | +### Example |
| 55 | + |
| 56 | +Here is a good example from a [commit to the Bitcoin core](https://github.com/bitcoin/bitcoin/commit/eb0b56b19017ab5c16c745e6da39c53126924ed6). |
| 57 | + |
| 58 | +```txt |
| 59 | + refactor: simplify serialize.h's exception handling |
| 60 | +
|
| 61 | + Remove the 'state' and 'exceptmask' from serialize.h's stream |
| 62 | + implementations, as well as related methods. |
| 63 | +
|
| 64 | + As exceptmask always included 'failbit', and setstate was always |
| 65 | + called with bits = failbit, all it did was immediately raise an |
| 66 | + exception. Get rid of those variables, and replace the setstate |
| 67 | + with direct exception throwing (which also removes some dead |
| 68 | + code). |
| 69 | +
|
| 70 | + As a result, good() is never reached after a failure (there are |
| 71 | + only 2 calls, one of which is in tests), and can just be replaced |
| 72 | + by !eof(). |
| 73 | +
|
| 74 | + fail(), clear(n) and exceptions() are just never called. Delete |
| 75 | + them. |
| 76 | +``` |
| 77 | + |
| 78 | +## Context |
| 79 | + |
| 80 | +- Current git status: !`git status` |
| 81 | +- Current git diff (staged and unstaged changes): !`git diff HEAD` |
| 82 | +- Current branch: !`git branch --show-current` |
| 83 | + |
| 84 | +## Task |
| 85 | + |
| 86 | +1. Analyze the staged changes from git diff |
| 87 | +2. New added features and fixes are more important than other types like refactoring, etc. |
| 88 | +3. Draft a commit message following all seven rules |
| 89 | +4. Use conventional commits spec |
| 90 | +5. If $ARGUMENTS is provided, add "Issue $ARGUMENTS" at the bottom |
| 91 | +6. Show me the final message - DO NOT commit it |
0 commit comments