// Conventions for drafting git commit messages. Load when asked to write a commit message, draft a commit, or run `git commit`. Covers subject-line bracket prefixes, NFC tagging, line-length and wrapping rules, imperative mood, body content focused on the why, and trailers like rdar:// references and `Assisted-by: Claude`.
| name | commit-message |
| description | Conventions for drafting git commit messages. Load when asked to write a commit message, draft a commit, or run `git commit`. Covers subject-line bracket prefixes, NFC tagging, line-length and wrapping rules, imperative mood, body content focused on the why, and trailers like rdar:// references and `Assisted-by: Claude`. |
Draft commit messages in this format. Do not run git commit — output the message and let the user commit. Commit signing prompts a GPG pinentry that hangs Claude Code.
git status and git diff --staged (or git diff if nothing is staged) to see the actual change.git log -n 10 --oneline in the same repo to match the local prefix conventions (component tags differ between repos — [lldb], [clang], [DWARFLinker], etc.).If the staged diff spans multiple unrelated logical changes, say so and suggest splitting before drafting — one logical change per commit.
Format: [component] Imperative summary
git log in the current repo uses.[lldb, CMake]. Use separate pairs when nesting is genuinely needed: [lldb][CMake]. Prefer a single pair when one suffices. (#NNNNN) on squash-merge — that does not count against the limit.(NFC) suffix for non-functional changes (refactors, renames, comment-only, formatting). Use (NFCI) when the change is intended to be non-functional but you can't fully prove it (e.g. threading a parameter that should not change behavior). The suffix goes at the end of the subject, before any PR number.Examples (good):
[lldb] Assert that CommandObject::DoExecute sets a return status[lldb-dap] Make lldbDAP an OBJECT library (NFC)[DWARFLinker] Emit DW_IDX_parent in the accelerator table[lldb][CMake] Force OBJECT libraries to also be STATICAnti-patterns:
[lldb, dap] Fixed bug — comma-listed tags, past tense, vague.Updates the linker to handle Swift modules. — no bracket, third-person, trailing period.[lldb] Refactor — too vague; say what was refactored and how.Optional but usually present. Separate from the subject by one blank line. Wrap at 72 characters.
What goes in the body:
What stays out:
Imperative mood and present tense apply in the body too: "Pass STATIC alongside OBJECT so..." not "Passed STATIC...".
Place at the end of the body, separated by one blank line. One trailer per line.
rdar://NNNNNNNNN — Apple-internal Radar reference, only include when the change is explicitly tied to a Radar.Assisted-by: Claude — when Claude materially helped author the change (drafted code, designed the approach). Omit for purely mechanical assistance.Fixes #NNNNN / Closes #NNNNN — only when the change actually closes a public GitHub issue.Do not add Co-Authored-By: Claude or any other Claude attribution beyond Assisted-by: unless the user asks.
A bare subject is fine for changes whose subject is fully self-describing and whose motivation is obvious from the diff (mechanical fixes, test updates after a rename, reverting a clearly-named commit). When in doubt, write the body.
Return the message in a fenced block so the user can copy-paste:
[component] Imperative summary
Body paragraph explaining why, wrapped at 72 columns. Reference
prior commits by short SHA when relevant (e.g. a5a13ca29186).
rdar://NNNNNNNNN
Assisted-by: Claude
Do not prepend "Here is the commit message:" or similar — just the block.
Conventions for writing source code comments. Load when adding or editing comments in code, reviewing a diff for comment quality, or deciding whether a comment belongs at all. Covers when a comment earns its place, the WHY-not-WHAT rule, banning prompt/task references, and the tone and length to aim for.
Conventions for writing, refactoring, or reviewing C++ in LLVM, Clang, or LLDB trees. Covers the naming split between LLVM and LLDB, include ordering, ADT containers and string types (StringRef, SmallVector, DenseMap), Error/Expected handling, LLVM-style casts, formatting rules, and LLDB-specific hazards. Load when editing `.cpp`/`.h` files under an LLVM monorepo, opening a file that includes `llvm/ADT/`, or answering questions about LLVM/LLDB coding standards.
Guidance for offloading work to subagents and running independent work in parallel. Load when a task involves multiple independent investigations, heavy codebase exploration, or research that would bloat the main context. Covers when to delegate vs. do directly, how to dispatch agents concurrently in a single message, how to choose between Explore / Plan / general-purpose / specialist agents, and how to structure agent prompts for useful results.