path: root/claude-rules/commits.md

# Commit Rules

Applies to: `**/*`

## Author Identity

All commits are authored as the user (repo owner / maintainer), never as
Claude, Claude Code, Anthropic, or any AI tool. Git uses the configured
`user.name` and `user.email` — do not modify git config to attribute
otherwise.


## No AI Attribution — Anywhere

Absolutely no AI/LLM/Claude/Anthropic attribution in:

- Commit messages (subject or body)
- PR descriptions and titles
- Issue comments and reviews
- Code comments
- Commit trailers
- Release notes, changelogs, and any public-facing artifact
- Document author metadata — an org `#+AUTHOR:` line, YAML frontmatter `author:`, a docx or PDF author property, a byline

This means:

- **No** `Co-Authored-By: Claude …` (or Claude Code, or any AI) trailers
- **No** "Generated with Claude Code" footers or equivalents
- **No** 🤖 emojis or similar markers implying AI authorship
- **No** references to "Claude", "Anthropic", "LLM", "AI tool" as a credited contributor
- **No** attribution added via template defaults — strip them before committing

If a tool, template, or default config inserts attribution, remove it. If
settings.json needs it, set `attribution.commit: ""` and `attribution.pr: ""`
to suppress the defaults.

### Generated documents carry the human author only

Every document an agent writes or updates — a daily prep, a session log, a
spec, an explainer, a meeting summary — names the human as its sole author.
`#+AUTHOR: Craig Jennings`, never `Craig Jennings & Claude`, and never an
agent's name standing alone.

The failure mode is imitation, not intent. No template stamps this line;
agents copy the author header from whatever sits nearby — yesterday's prep,
the workflow file they're reading, the doc next to the one they're writing.
So a single stray `& Claude` propagates through everything generated
afterward, and no amount of fixing individual files stops it. Fix the files
an agent reads, and state the rule here.

The stakes are highest where the rule is least visible. A private notes repo
tolerates a co-author line; many employers do not, and their policy is that
work product carries employee names alone. An `#+AUTHOR:` line survives
conversion into docx, a published wiki page, or a PDF handed to a customer,
so a header written in a scratch document three months ago can surface inside
a deliverable. Write the header correctly at creation.

Two things this rule does not ask for. Don't rewrite historical records —
archived session logs and past dated documents stay as they are, because
they're a record of what happened rather than a live artifact. And don't
relabel a document another agent genuinely authored: if Codex wrote it, the
byline stays Codex. The rule removes false co-authorship, not true
authorship.


## Content scope for public artifacts

PR descriptions, Linear ticket bodies, and PR review comments are
visible to the team and to anyone with read access to the repo or
project. Don't mention:

- Local file paths on the user's personal machine.
- Private repos by name (e.g. a personal notes repo, a career repo).
- Personal tooling or workflow the team doesn't share.
- Anything a teammate couldn't reproduce or act on from public sources.

Rule of thumb: if a teammate couldn't find the referenced thing without
the user's help, don't reference it.

**Personal-tooling files.** The rules and skills that drive my workflow are private. Treat the following as personal tooling and don't cite them as authority in any commit message, PR description, PR comment, Linear ticket, or other shared artifact:

- Anything in `~/code/rulesets/claude-rules/` (`commits.md`, `testing.md`, `verification.md`, `subagents.md`, and any others added later).
- Any `CLAUDE.md`, `AGENTS.md`, or similar project-level rules file.
- Anything under `~/.claude/`, project `.claude/`, or project `.ai/`.
- Any skill definition (`SKILL.md`) under `~/code/rulesets/`.

Don't write "per `testing.md`, integration tests must hit a real DB" or "the rule in `commits.md` says…". State the reason directly: "integration tests hit a real DB so the migration is exercised end-to-end." The personal rule doesn't matter to a teammate. The reason does.

Edge case: when one of these files *is* the change (a commit in the rulesets repo, an edit to a project's `CLAUDE.md`), describe what changed and why without invoking the wider personal-rules layer around it. The commit can absolutely say "tighten testing rule for legacy code". It shouldn't say "per the personal-rules layer this file is loaded into…".

**Tooling-path enumeration is the same leak.** Citing a rule as authority isn't the only way the tooling layer leaks into history. A commit whose *content* must name these paths — a `.gitignore` adding `.claude/`, `CLAUDE.md`, `.ai/` — has unavoidable, correct file content, but its *message prose* must not enumerate them ("chore: ignore .claude tooling, CLAUDE.md, and session files"). On a public or shared-remote repo that enumeration exposes the tooling layer's structure in the log just as a citation would. Name the category instead: "chore: extend gitignore for local tooling and build artifacts". The same holds for any incidental mention, not only `.gitignore` commits. Two exemptions: a commit whose change *is* one of these files (the edge case above), and private single-user repos with no shared remote, where the history is the project and there's no third party to leak to.


## Write in the first person

Everything I author in or about this repo is first person: code comments,
commit messages, PR descriptions, PR review comments, and any note that lands
in the repo or its history. When I made a choice, say so as a choice — "I swept
the copies rather than repairing them, because a drifted copy outranked the
global rule" beats "the copies are swept rather than repaired."

Third-person constructions like "This change introduces X" or "This PR restores
Y" read as press-release self-narration. The commit is the change, so it does
not need announcing.

**The one carve-out: code is the actor when describing behavior.** A comment
saying *what the code does* stays third person, because the subject genuinely
is the code and not me — "the sweep only fires when the global rule exists",
"the guard rejects a malformed payload". First person is for the decision
behind it, third person for the behavior itself. Both often belong in the same
comment: what it does, then why I chose it.

This is the rule the publish flow already applied to commit bodies. It lives
here because code comments get written constantly and the publish skill is not
loaded then.

## The publish flow lives in the `publish` skill

Everything about *how* a commit, PR, or review comment gets written, reviewed,
approved, and published — the pre-flight reconcile, the code-review gate, the
draft/voice/approval gate, conventional-commit format, Voice and Focus, PR
description structure, the three review shapes, merge strategy, and the
pre-commit checklist — is in the `publish` skill. Load it before drafting a
message, not after: the flow gates what gets written.

What stays here is what must hold whether or not anything is being published,
and where a violation is permanent and reaches other people. If the skill fails
to load you will have to be told the flow, which is recoverable. The rules
below are not.

## If You Catch Yourself

Typing any of the following — stop, delete, rewrite:

- `Co-Authored-By: Claude`
- `🤖 Generated with …`
- "Created with Claude Code"
- "Assisted by AI"

Rewrite the commit as the user would write it: concise, focused on the
change, no mention of how the change was produced.