Help create git commits and PRs with properly formatted messages and release notes following CockroachDB conventions. Use when committing changes or creating pull requests.

CockroachDB Commit Helper Help the user create properly formatted commit messages and release notes that follow CockroachDB conventions. Workflow 1. Analyze the changes : Run git diff staged or git diff to understand what was modified 2. Determine the package prefix : Identify the primary package affected 3. Ask the user for: Issue/epic number if not already known Whether release notes are needed and what category fits best 4. Write the subject line : Imperative mood, no period, under 72 characters 5. Write the body : Explain the before/after, why the change was needed 6. Add issue references : Include Resolves/Epic as appropriate 7. Write the release note : Clear, user focused description of the change 8. Create the commit using the properly formatted message Commit Message Structure Basic Format: Key Requirements: Must include release note annotation (even if "Release note: None") Must include issue or epic reference Must separate subject from body with blank line Recommended prefix subject with affected package/area Recommended use imperative mood in subject (e.g. "fix bug" not "fixes bug") Recommended wrap body at 72 100 characters Release Note Categories When to include release notes: Changes to user interaction or experience Changes to product behavior (performance, command responses, architecture) Bug fixes affecting external users When to exclude release notes: Internal refactors, testing, infrastructure work Code that's too immature for docs (private preview features) Internal settings beginning with crdb internal. Functionality not accessible to external users Valid Categories: backward incompatible change Breaking changes to stable interfaces enterprise change Features requiring enterprise license ops change Commands/endpoints for operators (logging, metrics, CLI flags) cli change Commands for developers/contributors (SQL shells, debug tools) sql change SQL statements, functions, system catalogs ui change DB Console changes security update Security feature changes performance improvement Performance enhancements cluster virtualization Multi tenancy infrastructure bug fix Problem fixes general change Changes that don't fit elsewhere build change Source build requirements Release Note Best Practices Description guidelines: Default to more information rather than less Explain what changed, how it changed, and why it's relevant Use past tense ("Added", "Fixed") or present tense ("CockroachDB now supports") For bug fixes: describe cause, symptoms, and affected versions Note if change is part of broader roadmap feature Examples: Good bug fix: Good feature: Issue References Resolves: 123 Auto closes issue on PR merge See also: 456, 789 Cross references issues Epic: CRDB 357 Links to epic How to Avoid Common Pitfalls Always include a release note annotation (even "Release note: None") Use only valid category names from the list above Keep release notes focused on user facing information Write specific descriptions that explain the impact to users Use backward incompatible change category for any breaking changes End subject lines without punctuation Explain the "why" behind changes, not just the "what" Pull Request Guidelines Create PRs from your personal fork , not directly on cockroachdb/cockroach Single commit PRs : PR title should match commit title, PR body should match commit body Multi commit PRs : The body should summarize the end goal that the set of commits achieves and give the reader the context necessary to review the PR commit by commit (for example, the first commits might get refactors out of the way so that the last commit can hook everything up). When there isn't an overarching connection between the commits (maybe the PR groups a few mechanical changes that are not related) it is fine to say that the individual commits speak for themselves.

commit-helper