ojhunt-commit

name	ojhunt-commit
description	Git operations, commit conventions, and ADRs. Load when preparing to commit, writing agent/worker prompts that include git steps, planning a change that may warrant an ADR, or evaluating whether a design decision needs documentation.
allowed-tools	Read, Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git branch:*), Bash(git commit:*)

Running a commit

When invoked to perform a commit (e.g. via /ojhunt-commit or when the user asks to commit), use this flow. The conventions below apply.

User instruction

$ARGUMENTS

Context

• Current git status (trimmed): ! git status --short 2>&1 | awk 'NR<=10{print} END{if(NR>10) print "... ("NR" files total, showing first 10)"}' || echo "(git status unavailable)"
• Current branch: !git branch --show-current 2>&1 || echo "(no branch)"
• Recent commits: !git log --oneline -10 2>&1 || echo "(no commits yet)"

Task

Create a single git commit using the conventions below, based on the user instruction and the changes shown above.

If the user instruction is empty, infer intent from the diff. If intent is unclear, ask before committing.

If git status reported config errors (e.g. missing user.email), surface that to the user and stop — do NOT silently set git config.

Stage and commit in a single message with parallel tool calls. Do not push.

Squash workflow (when instruction contains "squash with")

The preferred workflow is fixup-first, squash-last — never squash immediately:

1. Create fixup! commit(s): Stage the relevant files and run git commit --fixup=<sha> (requires dangerouslyDisableSandbox: true). If the commit message also needs changing, additionally run git commit --fixup=reword:<sha> (git ≥ 2.32) — no content, just a message edit. Show the user git log --oneline -5 so they can review.
2. Stop and wait for the user to confirm they are happy. Do not proceed to rebase without explicit user approval.
3. Squash: Once the user is satisfied, run GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash <target-sha>^ (requires dangerouslyDisableSandbox: true). -i is required because --autosquash only works in interactive mode; GIT_SEQUENCE_EDITOR=true suppresses the editor so no prompt appears.

---

Commit conventions

Git operations require sandbox bypass

Always use dangerouslyDisableSandbox: true for any git write operation (add, commit, reset, rebase, etc.) — the sandbox blocks writes to .git/.

Git read operations (git log, git status, git diff, git branch, git show) do NOT need sandbox bypass — run them in the sandbox like any other read command.

Do not push to remote

Commit locally; the user handles push and PR creation.

Commit hygiene

• pyproject.toml and uv.lock must be in the same commit. If they end up in separate commits during a session, squash them via interactive rebase before the session ends.
• Corrections go in new fixup commits, not amends. Use git commit --fixup=<sha> so the user can review what changed. Follow the squash workflow above — create the fixup!, wait for approval, then GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash <base-sha>.
• When UI/nav elements change, scan tests/e2e/ for selectors referencing the old element and include the test fix in the same commit.

Closing GitHub issues

When a commit fixes a GitHub issue, include Resolves #N on its own line in the commit body. GitHub will auto-close the issue when the commit lands on the default branch.

Commit messages should capture intent

The diff already shows what changed. The message should explain why — the motivation, the problem being solved, or the trade-off made. This matters especially for small tactical changes, because git log and git blame are the only place their intent is recorded.

If unsure of the user's intent, ask before committing.

When to write an ADR

Plan mode — the user arrives with a concrete plan; implement it. No ADR needed unless the plan itself involves a significant design decision.

Discussion mode — the user is exploring options. When a decision crystallises from open-ended back-and-forth, write the ADR before implementing.

A decision warrants an ADR if:

• Multiple approaches were considered and one was rejected
• The decision won't be obvious from reading the code
• Future contributors might be tempted to reverse it without understanding the context

Small tactical changes do not warrant an ADR — their intent belongs in the commit message.

How to write an ADR

Create docs/adr/NNNN-short-title.md and add a one-line pointer to the ADR list in docs/development.md. Status: Proposed, Accepted, Deprecated, or Superseded.

Write the ADR before starting implementation. If implementation reveals the decision needs to change, update the ADR first.