// Write conventional commit messages with type, scope, and subject when the user wants to commit changes or save work.
| name | commit |
| description | Write conventional commit messages with type, scope, and subject when the user wants to commit changes or save work. |
Creates git commits following Conventional Commits format with proper type, scope, and subject.
# 1. Stage changes
git add <files> # or: git add -A
# 2. Create commit (branch commit format)
git commit -m "type(scope): subject
Body explaining HOW and WHY.
Reference: Task X.Y, Req N"
Format: type(scope): subject
| Type | Purpose |
|---|---|
feat | New feature or functionality |
fix | Bug fix or issue resolution |
refactor | Code refactoring without behavior change |
perf | Performance improvements |
test | Test additions or modifications |
ci | CI/CD configuration changes |
docs | Documentation updates |
chore | Maintenance, dependencies, tooling |
style | Code formatting, linting (non-functional) |
security | Security vulnerability fixes or hardening |
Examples: validation, auth, cookie-service, template, config, tests, api
git status
git diff --staged # if already staged
git diff # if not staged
git add <specific-files> # preferred
# or
git add -A # all changes
NEVER commit:
.env, credentials.json, secretsnode_modules/, __pycache__/, .venv/Simple change:
git commit -m "fix(auth): use hmac.compare_digest for secure comparison"
Complex change (with body):
git commit -m "$(cat <<'EOF'
feat(validation): add URLValidator with domain whitelist
Implement URLValidator class supporting:
- Domain whitelist enforcement (youtube.com, youtu.be)
- Dangerous scheme blocking (javascript, data, file)
- URL parsing with embedded credentials handling
Addresses Requirement 31: Input validation
Part of Task 5.1: Input Validation Utilities
EOF
)"
git log -1 --format="%h %s"
git show --stat HEAD
<blank line>
Explain HOW and WHY the change was made.
- Use bullet points for multiple items
- Wrap at 72 characters
Reference: Task X.Y
Addresses: Req N
| Trailer | Purpose |
|---|---|
Fixes #N | Links and closes issue on merge |
Closes #N | Same as Fixes |
Co-authored-by: Name <email> | Credit co-contributors |
Place trailers at end of body after blank line. See references/commit_examples.md for examples.
For incompatible API/behavior changes, use ! after scope OR BREAKING CHANGE: footer:
feat(api)!: change response format to JSON:API
BREAKING CHANGE: Response envelope changed from `{ data }` to `{ data: { type, id, attributes } }`.
Triggers major version bump in semantic-release.
For PRs, use extended description with sections:
gh pr create --title "feat(security): implement input validation (Task 5)" --body "$(cat <<'EOF'
## Summary
- Input validation utilities (URLValidator, FormatValidator)
- Secure template processor with path traversal prevention
- API key authentication middleware
## Task Breakdown
Task 5.1: Input Validation - URLValidator, FormatValidator
Task 5.2: Template Processing - Path traversal prevention
Task 5.3: API Key Auth - Multi-key support, excluded paths
Task 5.4: Security Tests - 102 path traversal tests
## Requirements Covered
Req 7, Req 9, Req 31, Req 33
## Test Coverage
- All 473 tests passing
- Coverage: 93%
- Pre-commit checks: passing
EOF
)"
When fixing review comments, use this format:
git commit -m "fix(scope): address review comment #ID
Brief explanation of what was wrong and how it's fixed.
Addresses review comment #123456789."
Before creating PR, ensure all commits follow this format. The PR skill will:
Good:
feat(validation): add URLValidator with domain whitelist
fix(auth): use hmac.compare_digest for secure key comparison
refactor(template): consolidate filename sanitization logic
test(security): add 102 path traversal prevention tests
Bad:
update validation code # no type, no scope, vague
feat: add stuff # missing scope, too vague
fix(auth): fix bug # circular, not specific
chore: make changes # missing scope, vague
feat(security): improve things. # has period, vague
references/commit_examples.md - Extended examples by type