---
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.
