cockroach

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## CockroachDB Development Environment

CockroachDB is a distributed SQL database written in Go. We use Bazel as a build
system but most operations are wrapped through the `./dev` tool, which should be
preferred to direct `go (build|test)` or `bazel` invocations.

### Essential Commands

#### Building a package / package tests

This is useful as a compilation check.

```bash
# Build package ./pkg/util/log
./dev build pkg/util/log
# Build the tests in package ./pkg/util/log
./dev build pkg/util/log:log_test
```

#### Testing

```bash
./dev test pkg/sql                   # run unit tests for SQL package (slow!)
./dev test pkg/sql -f=TestParse -v   # run specific test pattern
./dev test pkg/sql --count=5         # run test multiple times
```

Note that when filtering tests via `-f` to include the `-v` flag which
will warn you in the output if your filter didn't match anything. Look
for `testing: warning: no tests to run` in the output.

See `./dev test --help` for all options.

#### Building

```bash
./dev build cockroach     # build full cockroach binary
./dev build short         # build cockroach without UI (faster)
```

Building a CockroachDB binary (even in short mode) should be considered
slow. Avoid doing this unless necessary.

Use `./dev build --help` for the entire list of artifacts that can
be built.

#### Code Generation and Linting

Protocol buffers, SQL parser, SQL Optimizer rules and others rely on Go code
generated by `./dev generate <args>`. This should be considered a slow command.
Rebuild only what is actually needed. `./dev (test|build)` commands
automatically generate their dependencies, but do not lift them into the
worktree, i.e. if they need to be visible to you, you need to invoke the
appropriate `./dev generate` command yourself.

```bash
./dev generate            # generate all code (protobuf, parsers, etc.) - SLOW
./dev generate go         # generate Go code only
./dev generate bazel      # update BUILD.bazel files when dependencies change
./dev generate protobuf   # generate protobuf files - relatively fast
```

See `./dev generate --help`.

### Architecture Overview

CockroachDB consists of many components and subsystems. The file .github/CODEOWNERS is a
good starting point if the overall architecture is relevant to the task.

## Coding Guidelines

### Code Formatting

After editing Go files, run `crlfmt -w -tab 2 <filename>.go` to format them.
`crlfmt` is CockroachDB's custom formatter (not `gofmt`); it enforces 100-column
code lines, 80-column comments, and CockroachDB-specific signature wrapping. It
also handles import grouping. `crlfmt` accepts one path argument at a time
(either a file or directory).

The formatter is not used on checked-in, generated files.

### Engineering Standards

CockroachDB is a complex system and you should write code under the assumption
that it will have to be understood and modified in the future by readers who
have basic familiarity with CockroachDB, but are not experts on the respective
subsystem.

Key concepts and abstractions should be explained clearly, and lifecycles and
ownership clearly stated. Whenever possible, you should use examples to make the
code accessible to the reader. Comments should always add depth to the code
(rather than repeating the code).

When reviewing, other than technical correctness, you should also focus on the
above aspects. Do not over-emphasize on grammar and comment typos, prefix with
"nit:" in reviews.

CockroachDB is a distributed system that allows for rolling upgrades. This means
that any shared state or inter-process communication needs to be mindful of
compatibility issues.  See `pkg/clusterversion` for more on this.

When adding or reviewing a newly added file with a license header the year on
the header should be the current year.

Favor modern Go idioms in new or updated code and use the standard library (e.g.
the `slices`, `maps`, and `cmp` packages) where appropriate.

### Resources

- **Main Documentation**: https://cockroachlabs.com/docs/stable/
- **Architecture Guide**: https://www.cockroachlabs.com/docs/stable/architecture/overview.html
- **Contributing**: See `/CONTRIBUTING.md` and https://wiki.crdb.io/
- **Design Documents**: `/docs/design.md` and `/docs/tech-notes/`

### When generating PRs and commit records

Use the `/commit-helper` skill when creating commits and PRs.

- For multi-commit PRs, describe the overall goal and the approach taken.
  Reference individual commits only when needed for orientation (e.g.
  "early commits are mechanical refactors; the last two hook everything up").
  Don't repeat commit messages — they're visible in the commit list and
  go stale as the PR evolves.
- Do not include a test plan unless explicitly asked by the user.
- Always include an `Epic:` footer in PR descriptions. Use the epic from
  prior context or attached issues if available, otherwise `Epic: none`.

### Skills

The following repo-specific skills are available:

- `/commit-helper` — Create commits and PRs with properly formatted messages and release notes.
- `/file-crdb-issue` — File GitHub issues using CockroachDB templates and labeling conventions.
- `/review-crdb` — Review code changes or PRs for correctness and reviewability.

# Interaction Style

* Be direct and honest.
* Skip unnecessary acknowledgments.
* Correct me when I'm wrong and explain why.
* Suggest better alternatives if my ideas can be improved.
* Focus on accuracy and efficiency.
* Challenge my assumptions when needed.
* Prioritize quality information and directness.