pkupuk
ad8e2e313e
Add configuration for BMad, Claude, OpenCode, and other AI agent tools and workflows.
87 lines
2.7 KiB
Markdown
87 lines
2.7 KiB
Markdown
---
|
|
name: git-commit
|
|
description: Use when creating git commits to ensure commit messages follow project standards. Applies the 7 rules for great commit messages with focus on conciseness and imperative mood.
|
|
---
|
|
|
|
# Git Commit Guidelines
|
|
|
|
Follow these rules when creating commits for this repository.
|
|
|
|
## The 7 Rules
|
|
|
|
1. **Separate subject from body with a blank line**
|
|
2. **Limit the subject line to 50 characters**
|
|
3. **Capitalize the subject line**
|
|
4. **Do not end the subject line with a period**
|
|
5. **Use the imperative mood** ("Add feature" not "Added feature")
|
|
6. **Wrap the body at 72 characters**
|
|
7. **Use the body to explain what and why vs. how**
|
|
|
|
## Key Principles
|
|
|
|
**Be concise, not verbose.** Every word should add value. Avoid unnecessary details about implementation mechanics - focus on what changed and why it matters.
|
|
|
|
**Subject line should stand alone** - don't require reading the body to understand the change. Body is optional and only needed for non-obvious context.
|
|
|
|
**Focus on the change, not how it was discovered** - never reference "review feedback", "PR comments", or "code review" in commit messages. Describe what the change does and why, not that someone asked for it.
|
|
|
|
**Avoid bullet points** - write prose, not lists. If you need bullets to explain a change, you're either committing too much at once or over-explaining implementation details.
|
|
|
|
## Format
|
|
|
|
Always use a HEREDOC to ensure proper formatting:
|
|
|
|
```bash
|
|
git commit -m "$(cat <<'EOF'
|
|
Subject line here
|
|
|
|
Optional body paragraph explaining what and why.
|
|
EOF
|
|
)"
|
|
```
|
|
|
|
## Good Examples
|
|
|
|
```
|
|
Add session isolation for concurrent executions
|
|
```
|
|
|
|
```
|
|
Fix encoding parameter handling in file operations
|
|
|
|
The encoding parameter wasn't properly passed through the validation
|
|
layer, causing base64 content to be treated as UTF-8.
|
|
```
|
|
|
|
## Bad Examples
|
|
|
|
```
|
|
Update files
|
|
|
|
Changes some things related to sessions and also fixes a bug.
|
|
```
|
|
|
|
Problem: Vague subject, doesn't explain what changed
|
|
|
|
```
|
|
Add file operations support
|
|
|
|
Implements FileClient with read/write methods and adds FileService
|
|
in the container with a validation layer. Includes comprehensive test
|
|
coverage for edge cases and supports both UTF-8 text and base64 binary
|
|
encodings. Uses proper error handling with custom error types from the
|
|
shared package for consistency across the SDK.
|
|
```
|
|
|
|
Problem: Over-explains implementation details, uses too many words
|
|
|
|
## Checklist Before Committing
|
|
|
|
- [ ] Subject is ≤50 characters
|
|
- [ ] Subject uses imperative mood
|
|
- [ ] Subject is capitalized, no period at end
|
|
- [ ] Body (if present) explains why, not how
|
|
- [ ] No references to review feedback or PR comments
|
|
- [ ] No bullet points in body
|
|
- [ ] Not committing sensitive files (.env, credentials)
|