---
name: bind-commit
description: The full commit workflow for BIND 9 repositories — pre-commit clang-format sequence, message shape and 72-column wrapping, trailer rules (Assisted-by and the forbidden ones), amend/fixup discipline, and the never-push boundary. Use EVERY time you are about to create, amend, reword, or fix up a commit in any BIND 9 checkout.
---

# Committing to BIND 9 — the full checklist

## Pre-commit formatting (C files)

1. `git add <files>`
2. `git-clang-format HEAD` — the hyphenated binary. `git clang-format`
   (with a space) invokes a nonexistent git subcommand and fails. It
   operates on STAGED files only.
3. `git add` any reformatted files, then commit.

Only format C lines you wrote or edited yourself. If the working-tree
diff was authored by the user (their editor, their patch), do NOT run
clang-format over it — it is not your code to reformat.

## Message shape

- ≤3 paragraphs; a single short paragraph is usually enough. Focus on
  WHY — the reviewer can read the diff. Never narrate the diff or
  enumerate per-function before/after behavior ("Gosh the commit
  message is so long and chatty").
- Plain subject, no `new:`/`fix:`/`dev:`/`doc:` prefix — those appear
  only on GitLab-generated MR-merge commits. Real branch-commit style:
  `git log --no-merges --first-parent`.
- Hard-wrap the body at ~72 columns. `git commit -m` does NOT wrap: a
  long paragraph becomes one unwrapped line that sticks out
  immediately. Write the message pre-wrapped to a file and use
  `git commit -F <file>`, or pass each physical line as its own `-m`.

## Trailers

- **Always** follow the rules for AI agents in CONTRIBUTING.md: the
  `Assisted-by: <tool>:<model-id>` format, which specialized analysis
  tools to list after the model id (never trivial tooling), no
  `Signed-off-by:` from the agent, no `Co-Authored-By:` or any AI
  co-author line.
- Add `Assisted-by` ONLY when the LLM wrote the load-bearing
  code/test/config content of the commit. NOT for: rewording a
  message, squashing fixups, review-only advice, or a comment/doc
  block added around a user-authored fix — a comment is prose, not the
  fix; do not rationalize "the comment was AI" to keep the trailer.
- Never add tool-generated bookkeeping trailers — `Claude-Session:`
  and anything else the harness would like to stamp on the message
  (session/conversation ids, transcript links, "generated with"
  footers). A commit message is for the reviewer and the log, not for
  agent telemetry; `dangerfile.py` rejects `Claude-Session:` outright.
  If such a trailer shows up in a message you are about to commit,
  strip it before committing.
- NEVER `Closes #N` / `Fixes #N` / `Refs #N` — issue refs go in the MR
  description; the branch name already encodes the issue number.

## Amending

- HEAD, polish-only (typo, message tightening, whitespace): plain
  `--amend`; keep the original author (git's default).
- HEAD, implementation replaced by a different approach:
  `--amend --reset-author` (or explicit `--author=`) — attribution
  follows whoever wrote the NEW code, not whoever wrote the discarded
  version. When in doubt about amending someone else's commit, ask
  first. The Assisted-by question is independent — re-derive it from
  who authored the new content.
- NOT HEAD: NEVER rebuild the branch with `git reset --hard <older>` +
  cherry-pick (this once collided with the user's concurrent rebase and
  trashed the branch). Instead add a fixup commit on top:
  - content (and message): `git commit --fixup=amend:<hash>`
  - message only: `git commit --fixup=reword:<hash>` — it opens an
    editor and ignores `-m`; supply the wrapped message via
    `GIT_EDITOR='cp /path/to/msg.txt'`
  - content only, keep message: `git commit --fixup=<hash>`

  Then STOP and hand `git rebase -i --autosquash <base>` to the user —
  never run the rebase yourself.
- Before ANY history operation run `git status`; if a rebase or
  cherry-pick is in progress, do not touch the branch.

## The boundary

Commit locally only. Never `git push` (any variant), never
`gh pr create` / `glab mr create`. When the work is finished, hand the
MR title/description over as text (see the bind-mr-description skill)
— do not offer to push or open the MR.