---
name: commit
description: Commit procedure and message rules. Use for every commit.
---

# Commit

## Procedure

1. Confirm that the configured signing key is available. If signing is
   unavailable or fails, stop and report the problem. Never disable
   signing, bypass it with a command or configuration override, or
   create an unsigned commit.
2. Do the `check` skill. All checks must pass before you commit.
3. Stage only the files that belong to this change. Keep unrelated
   changes in separate commits.
4. Write the message to a file or a here-document and sign the commit
   with the configured key, using `git commit -S -F`. Never put `\n` in
   `git commit -m`.
5. When `.githooks/commit-msg` rejects the message, fix the message and
   commit again. Do not skip the hook with `--no-verify`.
6. Cryptographically verify each new commit's signature against the
   configured key before reporting completion. A signature header alone
   is not verification. If verification fails, stop and report it. Do
   not claim completion or publish the commit.

## Size

- Commit often. Split the work into small, coherent, working steps, and
  do not wait for a full feature.
- Push code only with the user's authorization. A remote does not give
  permission to push.
- Rebase before an authorized push only when the task permits it. Do not
  rewrite published commits without the user's explicit approval. Stop
  and ask when an operation needs that approval. Never make a merge
  commit.

## Subject

- Use 50 characters or fewer.
- Write a short summary in the present-tense imperative mood.
- Capitalize the first word. Do not end with a period.
- Do not use a subsystem or prefix.

## Body

- Separate the subject from the body with exactly one blank line.
- Always write a body. Wrap each line at 72 characters. Fill each line
  of a paragraph before you wrap it.
- Write in the present-tense declarative mood.
- Start with a direct summary of the complete change. Do not only repeat
  the subject.
- Explain what the change does and why it is necessary. Describe the
  resulting behavior and design.
- Do not describe the development process, list the changed files, or
  give obvious implementation steps.

## Trailers

- When the change belongs to an issue, end the message with one `Issue:`
  trailer. Use the shortest unique git-bug issue ID in the `Issue:`
  trailer, with a minimum of seven characters. Check uniqueness against
  all issues, not only open issues. Add it with `git commit --trailer`.
  Never use a closing keyword such as "Fixes" or "Closes".
- Link the bug report when a change fixes a reported bug.
- Do not add an AI tool as co-author. Do not add attribution trailers.

## Example

```
Print the program name

OneChat prints its name and exits. The program gives the Nix package a
binary that the install check can run, so the build pipeline is tested
before the first feature.
```