Generate Commit Message
Generate commit messages following cbea.ms guidelines.
Output Format
Plain text commit message in a code block with NO language tag.
The user should be able to copy the entire content directly. Do NOT include:
git commit -m wrapperEOF or HEREDOC syntaxbash language tag on the code block- Extra commentary outside the code block
Short Example
Add input validation to form components
Detailed Example
Implement input validation for form components
- Create validation utility with reusable validators
- Add validators for email, phone, and text inputs
- Update `Button` and `Input` to use validation
Format: Short vs Detailed
- Short: Subject line only
- Detailed: Subject + bullet list body (3–6 bullets)
Decide autonomously based on the nature of the change:
- Small, focused changes → short
- Multi-file restructuring, module extraction, or architectural changes → detailed
- Only ask the user if genuinely uncertain
Workflow
- Run
git diff --staged --stat to see staged changes
- If nothing is staged, ask the user to stage files
- Analyze
git diff --staged
- Generate the commit message based only on staged changes
- Output the plain commit message in a code block (no language tag)
Commit Message Rules
- Subject line ≤72 chars
- Capitalize subject
- No period at end
- Imperative mood: "Add feature" not "Added feature"
- Blank line between subject and body
- Body lines ≤72 chars
- Backtick code identifiers: Always wrap component names, hooks, props, and other code references in backticks (e.g.
OrderForm, useContainerQuery)
Imperative Test
Subject should complete: "If applied, this commit will [subject]"
Imperative Verbs by Change Type
| Type |
Verbs |
| Feature |
Add, Implement, Introduce, Create |
| Fix |
Fix, Resolve, Correct |
| Refactor |
Refactor, Simplify, Restructure |
| Docs |
Document, Update docs |
| Style |
Format, Polish, Clean up |
| Test |
Add tests, Update tests |
| Chore |
Update deps, Configure |
Context Detection
Infer context from file paths in the staged diff:
- Monorepo app directories (e.g.,
apps/<name>/*) → mention the app name
- Shared packages (e.g.,
packages/<name>/*) → mention the package name
- Test files (
*.test.*, *.spec.*) → "Add tests" / "Update tests"
- Documentation (
*.md) → "Document" / "Update docs"
- Config files (
.eslintrc, tsconfig.json, etc.) → "Configure" / "Update config"
Tips
- If changes are too large, suggest splitting into multiple commits
- Keep bullet points action-oriented and concise (3-6 recommended)
- Focus on WHAT and WHY, not HOW
1---2name: generate-commit-message3description: Generate professional git commit messages following cbea.ms guidelines. Outputs plain copy-pasteable commit message text by default.4---56# Generate Commit Message78Generate commit messages following [cbea.ms guidelines](https://cbea.ms/git-commit/).910## Output Format1112Plain text commit message in a code block with NO language tag.1314The user should be able to copy the entire content directly. Do NOT include:15- `git commit -m` wrapper16- `EOF` or HEREDOC syntax17- `bash` language tag on the code block18- Extra commentary outside the code block1920### Short Example2122```23Add input validation to form components24```2526### Detailed Example2728```29Implement input validation for form components3031- Create validation utility with reusable validators32- Add validators for email, phone, and text inputs33- Update `Button` and `Input` to use validation34```3536## Format: Short vs Detailed3738- **Short**: Subject line only39- **Detailed**: Subject + bullet list body (3–6 bullets)4041Decide autonomously based on the nature of the change:42- Small, focused changes → short43- Multi-file restructuring, module extraction, or architectural changes → detailed44- Only ask the user if genuinely uncertain4546## Workflow47481. Run `git diff --staged --stat` to see staged changes492. If nothing is staged, ask the user to stage files503. Analyze `git diff --staged`514. Generate the commit message based only on staged changes525. Output the plain commit message in a code block (no language tag)5354## Commit Message Rules55561. **Subject line ≤72 chars**572. **Capitalize subject**583. **No period at end**594. **Imperative mood**: "Add feature" not "Added feature"605. **Blank line** between subject and body616. **Body lines ≤72 chars**627. **Backtick code identifiers**: Always wrap component names, hooks, props, and other code references in backticks (e.g. `OrderForm`, `useContainerQuery`)6364### Imperative Test6566Subject should complete: "If applied, this commit will [subject]"6768## Imperative Verbs by Change Type6970| Type | Verbs |71|------|-------|72| Feature | Add, Implement, Introduce, Create |73| Fix | Fix, Resolve, Correct |74| Refactor | Refactor, Simplify, Restructure |75| Docs | Document, Update docs |76| Style | Format, Polish, Clean up |77| Test | Add tests, Update tests |78| Chore | Update deps, Configure |7980## Context Detection8182Infer context from file paths in the staged diff:8384- Monorepo app directories (e.g., `apps/<name>/*`) → mention the app name85- Shared packages (e.g., `packages/<name>/*`) → mention the package name86- Test files (`*.test.*`, `*.spec.*`) → "Add tests" / "Update tests"87- Documentation (`*.md`) → "Document" / "Update docs"88- Config files (`.eslintrc`, `tsconfig.json`, etc.) → "Configure" / "Update config"8990## Tips9192- If changes are too large, suggest splitting into multiple commits93- Keep bullet points action-oriented and concise (3-6 recommended)94- Focus on WHAT and WHY, not HOW
SepantaJoshani