## Procedure
-1. Do the `check` skill. All checks must pass before you commit.
-2. Stage only the files that belong to this change. Keep unrelated
+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.
-3. Write the message to a file or a here-document and commit with
- `git commit -F`. Never put `\n` in `git commit -m`.
-4. When `.githooks/commit-msg` rejects the message, fix the message and
- commit again. Do not skip the hook with `--no-verify`.
+4. Write the complete message to a file, including all trailers. Add
+ trailers with `git interpret-trailers --trailer` before the check,
+ not after it. Never put `\n` in `git commit -m`.
+5. Run `sh .githooks/commit-msg MESSAGE_FILE` on that final file before
+ `git commit`. Fix every failure and run the check again. Sign with
+ the configured key, using `git commit -S -F MESSAGE_FILE` on the same
+ file. Do not add or change trailers after the check. The normal
+ commit hook still runs. Never skip it 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.
-- Before a push, rebase on the latest `master` and fix conflicts during
- the rebase. Never make a merge commit.
+- 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
- 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.
+ of a paragraph before you wrap it. `bin/reflow` formats source
+ comments at 80 columns, not commit prose. Do not use it to format a
+ commit message.
- Write in the present-tense declarative mood.
- Start with a direct summary of the complete change. Do not only repeat
the subject.
## Trailers
-- When the change belongs to an issue, end the message with one `Link:`
- trailer to that issue. Add it with `git commit --trailer`. Never use a
- closing keyword such as "Fixes" or "Closes".
+- 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. Assemble it with
+ `git interpret-trailers --trailer` before the message check. 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.