Commit
Reads the working tree and prints commit messages to chat. Never runs git add or
git commit - staging and committing stay a human decision.
1. Read the diff
git status --short
git diff HEAD
Include untracked files - git status --short marks them ??; read their contents too,
they are not in git diff HEAD by default.
If the tree is clean, say so and stop. Do not invent a message for nothing.
2. Group by logical change, not by file
A diff touching three unrelated things gets three messages, not one. Group by concern:
a rename here, a new skill there, a doc fix elsewhere - even if they landed in the same
session. Do not force unrelated work into a single commit to keep the list short.
3. Write each message
Per .claude/CLAUDE.md > Naming - use what the project actually uses, not a generic
convention:
- Types in use:
fix, feat, test, perf, docs, refactor, ci, chore, style, plus release:
for version bumps.
- Lowercase, imperative mood, no trailing period.
- Optional scope:
type(scope): summary.
- Bugfix branches use
bug/, but their commits use fix: - never bug:.
fix: reject 1D<->2D connections with matching flattened size
test(golden): add sigmoid regime coverage
chore: pin vcpkg and imgui-platform-kit revisions
Output
A markdown bullet list, one message per logical change, each in a code span. When there is
more than one, name the files it covers so they can be staged separately:
- `refactor: rename (project)notes to notes` - .gitignore, .claude/CLAUDE.md, wiki/Helping Claude Help You.md
- `feat: add /commit and /pr skills` - .claude/skills/commit/SKILL.md, .claude/skills/pr/SKILL.md
Nothing else - no staging, no committing, no pushing.