Skip to content

CLAUDE.md

Latest commit

 

History

History
145 lines (104 loc) · 5.45 KB

CLAUDE.md

File metadata and controls

145 lines (104 loc) · 5.45 KB

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.

# 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

./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

./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.

./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 only accepts one filename at a time.

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

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.