commit-conventions

Commit Conventions

Workflow

1. Inspect the worktree before committing:

   • Run git status --short.
   • Review the staged/unstaged diff enough to write an accurate message.
   • Run relevant tests when practical, and mention any warnings or skipped tests in the final response.

2. Stage exactly the intended changes:

   • Use git add -A only when the user asks to commit all changes.
   • Do not revert unrelated user changes.
   • Confirm the staged diff with git diff --cached --stat or equivalent.

3. Write a Conventional Commit subject:

   • Format: type(scope): summary
   • Use common types such as feat, fix, refactor, test, docs, chore, build, ci, perf, or style.
   • Include a concise scope when useful, such as cli, revm, config, or docs.
   • Keep the subject imperative and specific.

4. Write the commit body with the user’s required format:

   • Each distinct change description must be a bullet beginning with -.
   • Do not put blank lines between body bullet items.
   • Keep each bullet factual and tied to the staged diff.

5. Avoid forbidden attribution:

   • Do not add Co-authored-by trailers.
   • Do not mention Claude, Anthropic, or AI tooling in the commit message.
   • Do not add extra trailers unless the user explicitly asks.

6. Commit non-interactively:

   • Prefer git commit -m "type(scope): summary" -m "- item one\n- item two".
   • After committing, run git status --short and git log -1 --format=fuller to verify cleanliness and message shape.

Example

git commit -m "refactor(cli): model attach as VM run mode" -m "- replace attach subcommands with --attach mode on chroot and dockerd
- add VM.Attach for lightweight attach without building machine resources
- require session identity through WithSessionID and keep attach setup in config chain
- inline mode execution in command entrypoints"

Final Response

Report the commit hash and subject. Mention the tests run and any warnings. State if the worktree is clean.