| 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:
- 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.
- Stop and wait for the user to confirm they are happy. Do not proceed to
rebase without explicit user approval.
- 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.
