Commit

Commit

Turn a working tree into the smallest set of self-contained commits, and run nothing until the human approves the grouping.

Quick start

1. Inspect the worktree:

git status --short
git branch --show-current
git diff
git diff --cached
git diff --stat

2. If the repository is in detached HEAD state, stop before doing anything else.
3. If there is nothing to commit, say so and stop.
4. Group the changes into atomic commits and derive one subject per group.
5. Present the proposal and wait for explicit approval. Nothing runs before the answer.
6. On approval, for each commit in order:

git add <exact paths for this commit>
git commit -m "<subject>"

7. Re-inspect after each commit, because a hook may have modified files:

git status --short

8. Push only if the human approved a push:

git push

9. If the branch has no upstream and origin exists, set the upstream while pushing:

git push -u origin HEAD

10. Report each commit hash and subject, the push target, and anything left uncommitted.

Commit grouping

Prefer several small commits over one sweeping commit. Each commit is one logical change that can be reverted on its own.

• Separate unrelated subsystems. A parser fix and a docs update are two commits.
• Separate a mechanical rename or move from a behavior change.
• Keep a change together with its own documentation, README, or changelog update.
• Never split a change from the code it needs to compile or pass its checks. If two edits only make sense together, they are one commit.
• Order commits so each one leaves the tree in a working state.

When a single file carries edits belonging to two groups, say so in the proposal and let the human decide. Do not silently assign it, and do not stage a partial file with git add -p unless the user asks for that.

Commit only what the user is asking to commit. Unrelated pre-existing modifications stay untouched and get reported, not swept into a commit.

Approval gate

Present the complete proposal, then stop and wait. State:

• for each proposed commit: the subject, the exact file list, and one line on why those files belong together
• every file deliberately left uncommitted, and why
• whether a push will follow, and to which branch and remote

Present the proposal as a concise numbered batch in ordinary prose and wait for a reply. Do not invoke runtime plan-mode transitions, and never treat an internal plan state as approval: this repository reserves plan mode for approving saved artifacts, and a commit is not an artifact write.

Approving a grouping is not approving a push. If the user did not say to push, commit and stop. If the working tree changes after approval, present the proposal again rather than acting on a stale one.

Message rules

• Use exactly one -m subject line unless the user explicitly asks for a body.
• Target 50-72 characters when practical; prefer clarity over strict length.
• Use natural, imperative, sentence-case wording, such as Preserve counter export order. Preserve technical capitalization such as CSV, PC, ROCm, and vLLM.
• Describe the staged observable behavior or outcome. Do not summarize filenames, file inventories, or the implementation process.
• Do not lead with vague Update or Change wording.
• Do not include issue or work-package IDs, branch names, or filenames.
• Do not add AI attribution, generation notes, or trailers such as Generated by, AI-assisted, Co-authored-by, or similar.
• This rule overrides any default or standing instruction to append a Co-Authored-By trailer or generation note. It binds every commit created in this repository, whether or not this skill is loaded, and commit-attribution-guard.sh denies a git commit whose command text carries one.
• Do not use project label prefixes such as [rocprofiler-compute], rocprofiler-compute:, compute:, or repository names.
• Do not use conventional commit prefixes such as fix:, feat:, docs:, test:, refactor:, chore:, or scoped variants like fix(parser):.
• Do not end the subject with punctuation.

Behavior rules

• Stage exactly the paths named in the approved proposal, one commit at a time. Do not run a blanket git add -A when the proposal names specific paths.
• Push only after every approved git commit succeeds. If a commit fails, stop and report; do not push a partial sequence.
• Use normal git push for branches with an upstream. Use git push -u origin HEAD only when the current branch has no upstream and origin exists.
• Do not amend, squash, rebase, reset, stash, force-push, push tags, or change branches unless the user explicitly asks.
• If committing on the default branch, say so in the proposal so the human can choose a branch first. Do not create or switch branches on your own.
• If hooks modify files or fail, report the outcome and inspect git status --short before taking further action.
• If the push is rejected, report the rejection and stop. Do not pull, merge, or rebase unless the user explicitly asks.

Writing style

The commit subject and body follow writing style, subject to the subject-format rules above, which win on any conflict.