aspiers Git Commit
Create a commit that accurately describes one logical staged change.
Respect the index boundary
Treat the staging area as user-controlled input. Do not stage, unstage, or
otherwise alter it unless the user explicitly asks for that operation. Use the
git-staging skill when selective staging is requested.
If nothing is staged, report that fact and ask whether the user wants help staging. If staged and unstaged changes coexist, keep them distinct throughout the review.
Workflow
- Inspect
git status,git diff --cached --no-ext-diff, and enough recent history to learn the repository's message style. - Confirm the staged diff is coherent and contains no apparent secrets, accidental files, or unrelated changes.
- If the staged content combines independent concerns, explain the split and ask before changing the index. Otherwise continue without inventing extra commits merely because several files changed.
- Write a message that emphasizes why the change exists and accurately summarizes the staged diff.
- Commit, then verify the resulting commit and remaining working-tree state.
Message guidance
Follow repository conventions first. Use Conventional Commits only when the history or project rules use them. Keep the subject concise and imperative when that matches local style; add a body when rationale, behavior changes, or migration details would help future readers.
Include issue references, task files, sign-offs, or AI attribution only when relevant or required by the repository or user. Do not fabricate metadata.
Before reporting success, inspect the created commit (for example with
git show --stat --oneline HEAD) and state what remains uncommitted.