Commit
Commit staged and unstaged changes following the rules below.
Commit message format
Use semantic commit messages matching the project convention:
<type>(<scope>): <short summary in imperative mood>
Types: feat, fix, refactor, perf, chore, ci, docs, test
- Summary is lowercase, no period at the end
- Imperative mood ("add X", not "added X" or "adds X")
- Keep the first line under 72 characters
- Add a blank line + body only if the "why" isn't obvious from the summary
Splitting into logical commits
- If you have context about what work was done (e.g. you just finished implementing something), commit only that work. Don't bundle unrelated changes — leave other unstaged/untracked changes alone.
- Planning artifacts ARE part of the work — always commit them. A plan/spec/context scaffold that drove the change (e.g.
docs/plans/<date>-<slug>/ containing context.md, README.md, .planning-prompt, or similar planning docs) is not "unrelated untracked junk" — it is the record of why this commit exists. Stage and commit these alongside the code in the same commit (or a dedicated docs: commit). Never leave them behind. The only exception is regenerated runtime logs explicitly listed in .gitignore.
- You MAY split your work into multiple logical commits if it makes sense (e.g. a refactor commit + a feature commit, or separating test changes from implementation).
- If you have no prior context, read
git diff and git diff --cached to understand all changes, then group them into reasonable logical commits by topic/purpose. If some changes appear unrelated to each other and you can't determine what belongs together, ask before committing.
- Each commit should be self-contained and buildable on its own when possible.
Procedure
These commands run automatically when the skill loads — output replaces each line below:
- Working tree status: !
git status
- Unstaged diff: !
git diff
- Staged diff: !
git diff --cached
- Recent commits: !
git log --oneline -10
Then:
- Review the changes and decide how to split them into commits (if needed).
- For each commit:
- Stage the relevant files with
git add <specific files> (never git add -A or git add .)
- Create the commit
- Run
git status after all commits to verify nothing was missed.
Edge cases
- Nothing to commit: Report and stop.
- Pre-commit hook failure: The commit did NOT happen. Fix the issue, re-stage, and create a new commit. Never use
--amend after a hook failure — it would modify the previous commit.
- Secrets / dangerous files: If you spot
.env files, API keys, tokens, credentials, or private keys, stop and warn before committing.
- Merge conflict markers: Warn and refuse to commit those files.
1---2name: commit3description: Use when committing changes. Analyzes diff, writes a conventional commit message, commits immediately without confirmation. Triggers: commit, save my work, done with this change.4---56# Commit78Commit staged and unstaged changes following the rules below.910## Commit message format1112Use semantic commit messages matching the project convention:1314```15<type>(<scope>): <short summary in imperative mood>16```1718Types: `feat`, `fix`, `refactor`, `perf`, `chore`, `ci`, `docs`, `test`1920- Summary is lowercase, no period at the end21- Imperative mood ("add X", not "added X" or "adds X")22- Keep the first line under 72 characters23- Add a blank line + body only if the "why" isn't obvious from the summary2425## Splitting into logical commits2627- If you have context about what work was done (e.g. you just finished implementing something), commit **only** that work. Don't bundle unrelated changes — leave other unstaged/untracked changes alone.28- **Planning artifacts ARE part of the work — always commit them.** A plan/spec/context scaffold that drove the change (e.g. `docs/plans/<date>-<slug>/` containing `context.md`, `README.md`, `.planning-prompt`, or similar planning docs) is not "unrelated untracked junk" — it is the record of *why* this commit exists. Stage and commit these alongside the code in the same commit (or a dedicated `docs:` commit). Never leave them behind. The only exception is regenerated runtime logs explicitly listed in `.gitignore`.29- You MAY split your work into multiple logical commits if it makes sense (e.g. a refactor commit + a feature commit, or separating test changes from implementation).30- If you have no prior context, read `git diff` and `git diff --cached` to understand all changes, then group them into reasonable logical commits by topic/purpose. If some changes appear unrelated to each other and you can't determine what belongs together, ask before committing.31- Each commit should be self-contained and buildable on its own when possible.3233## Procedure3435These commands run automatically when the skill loads — output replaces each line below:3637- Working tree status: !`git status`38- Unstaged diff: !`git diff`39- Staged diff: !`git diff --cached`40- Recent commits: !`git log --oneline -10`4142Then:43441. Review the changes and decide how to split them into commits (if needed).452. For each commit:46 - Stage the relevant files with `git add <specific files>` (never `git add -A` or `git add .`)47 - Create the commit483. Run `git status` after all commits to verify nothing was missed.4950## Edge cases5152- **Nothing to commit:** Report and stop.53- **Pre-commit hook failure:** The commit did NOT happen. Fix the issue, re-stage, and create a **new** commit. Never use `--amend` after a hook failure — it would modify the previous commit.54- **Secrets / dangerous files:** If you spot `.env` files, API keys, tokens, credentials, or private keys, **stop** and warn before committing.55- **Merge conflict markers:** Warn and refuse to commit those files.
neumie