Smart Commits
Turn the current working tree into one or more coherent commits, then push when the repository has a configured remote. This skill is for committing existing work. It must not become a feature-editing session.
Core Rules
- Never edit product code or docs just to make a commit easier. If validation exposes a real blocker, report it and keep the working tree intact unless the user explicitly asks for a fix.
- Never stash, reset, checkout away, overwrite, or revert unrelated changes. In multi-agent repos, treat every existing change as intentional work unless the user explicitly asks otherwise.
- Preserve the user's requested boundary. If they say to leave a path, topic, or change set alone, do not stage it.
- Stage exact files or hunks intentionally. Avoid
git add . unless the whole tree has been inspected and belongs in one commit group.
- Prefer conventional commit messages with a useful body explaining why the group belongs together.
- Push after committing when a remote/upstream exists. If no push destination exists, leave the commits local and say so.
Workflow
- Inspect the repository:
git status --porcelain=v1
git branch --show-current
git remote -v
git diff --stat
git diff --cached --stat
- Read enough representative diffs and files to understand intent. Include staged, unstaged, untracked, deleted, and renamed files.
- Identify commit groups by product intent, not by file type:
- foundational/configuration changes before dependent feature changes
- source and directly coupled tests together when they prove one behavior
- docs as a separate commit only when they are independently meaningful
- generated artifacts only when they are part of the requested deliverable
- Run appropriate quality gates before committing when code changed. Use the repo's own checks first. If checks are unavailable, expensive, or already known broken, record that in the final response.
- Commit one group at a time:
git add <specific files>
git commit -m "<type>(<scope>): <subject>" -m "<body>"
- After each commit, re-run
git status --porcelain=v1 and continue until all in-scope changes are committed.
- Push:
git push
If the branch lacks an upstream, use git push -u origin <branch> only when the remote and branch name are clearly correct.
Grouping Guidance
Good groups:
refactor(auth): extract token validation helperfeat(users): add email verification endpointtest(users): cover email verification flow
Bad groups:
chore: update filesdocs: update docs and app codetest: update tests when the tests prove multiple unrelated features
Final Response
Report the commits created, push result, validation run, and any remaining out-of-scope or uncommitted files. If the tree is already clean when invoked, verify the latest relevant commit and say no new commit was needed.
1---2name: smart-commits3description: Organize an existing Git tree into logical commits and push them. Use when asked to commit everything, smart commit, group changes, clean the commit stack, or push work.4---56# Smart Commits78Turn the current working tree into one or more coherent commits, then push when the repository has a configured remote. This skill is for committing existing work. It must not become a feature-editing session.910## Core Rules1112- Never edit product code or docs just to make a commit easier. If validation exposes a real blocker, report it and keep the working tree intact unless the user explicitly asks for a fix.13- Never stash, reset, checkout away, overwrite, or revert unrelated changes. In multi-agent repos, treat every existing change as intentional work unless the user explicitly asks otherwise.14- Preserve the user's requested boundary. If they say to leave a path, topic, or change set alone, do not stage it.15- Stage exact files or hunks intentionally. Avoid `git add .` unless the whole tree has been inspected and belongs in one commit group.16- Prefer conventional commit messages with a useful body explaining why the group belongs together.17- Push after committing when a remote/upstream exists. If no push destination exists, leave the commits local and say so.1819## Workflow20211. Inspect the repository:22 ```bash23 git status --porcelain=v124 git branch --show-current25 git remote -v26 git diff --stat27 git diff --cached --stat28 ```292. Read enough representative diffs and files to understand intent. Include staged, unstaged, untracked, deleted, and renamed files.303. Identify commit groups by product intent, not by file type:31 - foundational/configuration changes before dependent feature changes32 - source and directly coupled tests together when they prove one behavior33 - docs as a separate commit only when they are independently meaningful34 - generated artifacts only when they are part of the requested deliverable354. Run appropriate quality gates before committing when code changed. Use the repo's own checks first. If checks are unavailable, expensive, or already known broken, record that in the final response.365. Commit one group at a time:37 ```bash38 git add <specific files>39 git commit -m "<type>(<scope>): <subject>" -m "<body>"40 ```416. After each commit, re-run `git status --porcelain=v1` and continue until all in-scope changes are committed.427. Push:43 ```bash44 git push45 ```46 If the branch lacks an upstream, use `git push -u origin <branch>` only when the remote and branch name are clearly correct.4748## Grouping Guidance4950Good groups:51521. `refactor(auth): extract token validation helper`532. `feat(users): add email verification endpoint`543. `test(users): cover email verification flow`5556Bad groups:57581. `chore: update files`592. `docs: update docs and app code`603. `test: update tests` when the tests prove multiple unrelated features6162## Final Response6364Report the commits created, push result, validation run, and any remaining out-of-scope or uncommitted files. If the tree is already clean when invoked, verify the latest relevant commit and say no new commit was needed.
hoangnb24