SKILL.md
$27
Basic Format:
package: imperative title without period
Detailed explanation of what changed, why it changed, and
how it impacts users. Explain the problem that existed
before and how this commit solves it.
Include context about alternate approaches considered and
any side effects or consequences.
Resolves: #123
Epic: CRDB-357
Release note (category): Description of user-facing change
in past or present tense explaining what changed, how users
can see the change, and why it's important.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:
Release note (bug fix): Fixed a bug introduced in v19.2.3 that
caused duplicate rows in CREATE TABLE ... AS results when multiple
nodes attempt to populate the results.Good feature:
Release note (enterprise change): Shortened the default interval
for the kv.closed_timestamp.target_duration cluster setting from
30s to 3s. This allows follower reads at 4.8 seconds in the past,
a much shorter window than the previous 48 seconds.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 changecategory 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.