Commit Message
Use this schema for commit subjects:
Add <thing>: new feature, file, API, UI, behavior, or test coverage.Fix <thing>: broken behavior, regression, failing test, or incorrect output.Update <thing>: change existing behavior, config, copy, dependency, styling, or implementation.Remove <thing>: delete unused behavior, files, flags, dependencies, or config.Refactor <thing>: internal change with no intended behavior change.Test <thing>: test-only change.Docs <thing>: documentation-only change.Chore <thing>: tooling, build, formatting, generated files, repo maintenance, or CI.Revert <thing>: roll back a previous change.
Rules: no Conventional Commits syntax, no trailing period, prefer user-visible outcome, and keep the subject under 72 characters when practical.
Behavior: if the user asks to draft, suggest, review, or improve a message, do not commit. If this skill is invoked with an implementation task, treat it as atomic commit mode: after verification, stage intended changes and create commits. If the user explicitly says not to commit, do not commit.
Before committing:
- Inspect
git status --short, git diff --name-only, and staged diff if any.
- Decide commit groups before staging.
- State the planned commit list before the first commit.
- If the user provides a "what changed" list, treat each independent bullet or bullet cluster as a candidate commit.
- If 5+ files, multiple domains, or 3+ independent bullets changed, a single commit is forbidden unless the user explicitly asks for one commit.
Default split policy:
- Runtime behavior changes: separate commit per independently reviewable behavior.
- Shared helpers/refactors: separate commit.
- Tests: separate commit unless they are direct coverage for a small fix.
- Docs: separate commit.
- Config, tooling, generated files, and repo metadata: separate commit.
- Do not combine docs, tests, config, and runtime code in one commit unless explicitly asked.
- Do not combine API behavior, parser/data handling, bug fixes, and test/tooling cleanup in one commit unless explicitly asked.
- If multiple logical changes exist, split them. If unsure, prefer more small commits.
- If a proposed commit subject would be vague, broad, or plural, split it further.
Never stage unrelated changes.
1---2name: 0-commit-message3description: Use for git commit messages.4---56# Commit Message78Use this schema for commit subjects:910- `Add <thing>`: new feature, file, API, UI, behavior, or test coverage.11- `Fix <thing>`: broken behavior, regression, failing test, or incorrect output.12- `Update <thing>`: change existing behavior, config, copy, dependency, styling, or implementation.13- `Remove <thing>`: delete unused behavior, files, flags, dependencies, or config.14- `Refactor <thing>`: internal change with no intended behavior change.15- `Test <thing>`: test-only change.16- `Docs <thing>`: documentation-only change.17- `Chore <thing>`: tooling, build, formatting, generated files, repo maintenance, or CI.18- `Revert <thing>`: roll back a previous change.1920Rules: no Conventional Commits syntax, no trailing period, prefer user-visible outcome, and keep the subject under 72 characters when practical.2122Behavior: if the user asks to draft, suggest, review, or improve a message, do not commit. If this skill is invoked with an implementation task, treat it as atomic commit mode: after verification, stage intended changes and create commits. If the user explicitly says not to commit, do not commit.2324Before committing:2526- Inspect `git status --short`, `git diff --name-only`, and staged diff if any.27- Decide commit groups before staging.28- State the planned commit list before the first commit.29- If the user provides a "what changed" list, treat each independent bullet or bullet cluster as a candidate commit.30- If 5+ files, multiple domains, or 3+ independent bullets changed, a single commit is forbidden unless the user explicitly asks for one commit.3132Default split policy:3334- Runtime behavior changes: separate commit per independently reviewable behavior.35- Shared helpers/refactors: separate commit.36- Tests: separate commit unless they are direct coverage for a small fix.37- Docs: separate commit.38- Config, tooling, generated files, and repo metadata: separate commit.39- Do not combine docs, tests, config, and runtime code in one commit unless explicitly asked.40- Do not combine API behavior, parser/data handling, bug fixes, and test/tooling cleanup in one commit unless explicitly asked.41- If multiple logical changes exist, split them. If unsure, prefer more small commits.42- If a proposed commit subject would be vague, broad, or plural, split it further.4344Never stage unrelated changes.
curvefit