| name | commit |
| description | Use when creating a git commit for staged or unstaged changes. Triggers on "commit this", "save my changes", or when implementation work completes and needs version control. |
Commit Changes
Create a git commit following project conventions.
Commit Message Format
Subject line: Imperative mood, 50 chars max, capitalized, no period
- "Add spectrum analyzer" NOT "Added spectrum analyzer"
- Test: "If applied, this commit will [your subject]"
Body: Optional. Most commits need only a subject line. When included:
- List the changes factually. No problem framing, no rationale, no prose.
- Skip if the subject line covers it.
Anti-patterns (never include):
- Problem framing ("The kernel was aliasing because...")
- Motivation or justification ("to improve...", "this is needed so that...")
- Praise adjectives ("clean", "robust", "proper", "correct", "improved")
- Mentions of areas that were not modified ("no preset changes", "no API changes")
- Implementation journey ("was implemented and reverted", "tried X then Y")
- Redundant expansion of subject ("This adds..." when subject says "Add...")
- Phase/step references from planning docs
- Rationale for rejected approaches
Scope: One logical change per commit. Atomic commits simplify review and revert.
Instructions
- Run
git status and git diff --staged (or git diff if nothing staged) to understand changes
- Run
git log --oneline -5 to see recent commit style
- Draft a commit message following the format above
- Stage relevant files and commit:
Simple commit (preferred):
git commit -m "Add vertical offset parameter for linear waveforms"
With body (only when subject needs clarification):
git commit -m "$(cat <<'EOF'
Add vertical offset parameter for linear waveforms
Enables vertical stacking of multiple waveforms in linear mode.
EOF
)"
Safety
- NEVER amend commits you didn't create (check
git log -1 --format='%an %ae')
- NEVER force push to main/master
- NEVER skip hooks unless explicitly requested
