{"owner":"cockroachdb","repo":"cockroach","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## CockroachDB Development Environment\n\nCockroachDB is a distributed SQL database written in Go. We use Bazel as a build\nsystem but most operations are wrapped through the `./dev` tool, which should be\npreferred to direct `go (build|test)` or `bazel` invocations.\n\n### Essential Commands\n\n#### Building a package / package tests\n\nThis is useful as a compilation check.\n\n```bash\n# Build package ./pkg/util/log\n./dev build pkg/util/log\n# Build the tests in package ./pkg/util/log\n./dev build pkg/util/log:log_test\n```\n\n#### Testing\n\n```bash\n./dev test pkg/sql                   # run unit tests for SQL package (slow!)\n./dev test pkg/sql -f=TestParse -v   # run specific test pattern\n./dev test pkg/sql --count=5         # run test multiple times\n```\n\nNote that when filtering tests via `-f` to include the `-v` flag which\nwill warn you in the output if your filter didn't match anything. Look\nfor `testing: warning: no tests to run` in the output.\n\nSee `./dev test --help` for all options.\n\n#### Building\n\n```bash\n./dev build cockroach     # build full cockroach binary\n./dev build short         # build cockroach without UI (faster)\n```\n\nBuilding a CockroachDB binary (even in short mode) should be considered\nslow. Avoid doing this unless necessary.\n\nUse `./dev build --help` for the entire list of artifacts that can\nbe built.\n\n#### Code Generation and Linting\n\nProtocol buffers, SQL parser, SQL Optimizer rules and others rely on Go code\ngenerated by `./dev generate <args>`. This should be considered a slow command.\nRebuild only what is actually needed. `./dev (test|build)` commands\nautomatically generate their dependencies, but do not lift them into the\nworktree, i.e. if they need to be visible to you, you need to invoke the\nappropriate `./dev generate` command yourself.\n\n```bash\n./dev generate            # generate all code (protobuf, parsers, etc.) - SLOW\n./dev generate go         # generate Go code only\n./dev generate bazel      # update BUILD.bazel files when dependencies change\n./dev generate protobuf   # generate protobuf files - relatively fast\n```\n\nSee `./dev generate --help`.\n\n### Architecture Overview\n\nCockroachDB consists of many components and subsystems. The file .github/CODEOWNERS is a\ngood starting point if the overall architecture is relevant to the task.\n\n## Coding Guidelines\n\n### Code Formatting\n\nAfter editing Go files, run `crlfmt -w -tab 2 <filename>.go` to format them.\n`crlfmt` is CockroachDB's custom formatter (not `gofmt`); it enforces 100-column\ncode lines, 80-column comments, and CockroachDB-specific signature wrapping. It\nalso handles import grouping. `crlfmt` accepts one path argument at a time\n(either a file or directory).\n\nThe formatter is not used on checked-in, generated files.\n\n### Engineering Standards\n\nCockroachDB is a complex system and you should write code under the assumption\nthat it will have to be understood and modified in the future by readers who\nhave basic familiarity with CockroachDB, but are not experts on the respective\nsubsystem.\n\nKey concepts and abstractions should be explained clearly, and lifecycles and\nownership clearly stated. Whenever possible, you should use examples to make the\ncode accessible to the reader. Comments should always add depth to the code\n(rather than repeating the code).\n\nWhen reviewing, other than technical correctness, you should also focus on the\nabove aspects. Do not over-emphasize on grammar and comment typos, prefix with\n\"nit:\" in reviews.\n\nCockroachDB is a distributed system that allows for rolling upgrades. This means\nthat any shared state or inter-process communication needs to be mindful of\ncompatibility issues.  See `pkg/clusterversion` for more on this.\n\nWhen adding or reviewing a newly added file with a license header the year on\nthe header should be the current year.\n\nFavor modern Go idioms in new or updated code and use the standard library (e.g.\nthe `slices`, `maps`, and `cmp` packages) where appropriate.\n\n### Resources\n\n- **Main Documentation**: https://cockroachlabs.com/docs/stable/\n- **Architecture Guide**: https://www.cockroachlabs.com/docs/stable/architecture/overview.html\n- **Contributing**: See `/CONTRIBUTING.md` and https://wiki.crdb.io/\n- **Design Documents**: `/docs/design.md` and `/docs/tech-notes/`\n\n### When generating PRs and commit records\n\nUse the `/commit-helper` skill when creating commits and PRs.\n\n- For multi-commit PRs, describe the overall goal and the approach taken.\n  Reference individual commits only when needed for orientation (e.g.\n  \"early commits are mechanical refactors; the last two hook everything up\").\n  Don't repeat commit messages — they're visible in the commit list and\n  go stale as the PR evolves.\n- Do not include a test plan unless explicitly asked by the user.\n- Always include an `Epic:` footer in PR descriptions. Use the epic from\n  prior context or attached issues if available, otherwise `Epic: none`.\n\n### Skills\n\nThe following repo-specific skills are available:\n\n- `/commit-helper` — Create commits and PRs with properly formatted messages and release notes.\n- `/file-crdb-issue` — File GitHub issues using CockroachDB templates and labeling conventions.\n- `/review-crdb` — Review code changes or PRs for correctness and reviewability.\n\n# Interaction Style\n\n* Be direct and honest.\n* Skip unnecessary acknowledgments.\n* Correct me when I'm wrong and explain why.\n* Suggest better alternatives if my ideas can be improved.\n* Focus on accuracy and efficiency.\n* Challenge my assumptions when needed.\n* Prioritize quality information and directness.\n"},"files":{"CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## CockroachDB Development Environment\n\nCockroachDB is a distributed SQL database written in Go. We use Bazel as a build\nsystem but most operations are wrapped through the `./dev` tool, which should be\npreferred to direct `go (build|test)` or `bazel` invocations.\n\n### Essential Commands\n\n#### Building a package / package tests\n\nThis is useful as a compilation check.\n\n```bash\n# Build package ./pkg/util/log\n./dev build pkg/util/log\n# Build the tests in package ./pkg/util/log\n./dev build pkg/util/log:log_test\n```\n\n#### Testing\n\n```bash\n./dev test pkg/sql                   # run unit tests for SQL package (slow!)\n./dev test pkg/sql -f=TestParse -v   # run specific test pattern\n./dev test pkg/sql --count=5         # run test multiple times\n```\n\nNote that when filtering tests via `-f` to include the `-v` flag which\nwill warn you in the output if your filter didn't match anything. Look\nfor `testing: warning: no tests to run` in the output.\n\nSee `./dev test --help` for all options.\n\n#### Building\n\n```bash\n./dev build cockroach     # build full cockroach binary\n./dev build short         # build cockroach without UI (faster)\n```\n\nBuilding a CockroachDB binary (even in short mode) should be considered\nslow. Avoid doing this unless necessary.\n\nUse `./dev build --help` for the entire list of artifacts that can\nbe built.\n\n#### Code Generation and Linting\n\nProtocol buffers, SQL parser, SQL Optimizer rules and others rely on Go code\ngenerated by `./dev generate <args>`. This should be considered a slow command.\nRebuild only what is actually needed. `./dev (test|build)` commands\nautomatically generate their dependencies, but do not lift them into the\nworktree, i.e. if they need to be visible to you, you need to invoke the\nappropriate `./dev generate` command yourself.\n\n```bash\n./dev generate            # generate all code (protobuf, parsers, etc.) - SLOW\n./dev generate go         # generate Go code only\n./dev generate bazel      # update BUILD.bazel files when dependencies change\n./dev generate protobuf   # generate protobuf files - relatively fast\n```\n\nSee `./dev generate --help`.\n\n### Architecture Overview\n\nCockroachDB consists of many components and subsystems. The file .github/CODEOWNERS is a\ngood starting point if the overall architecture is relevant to the task.\n\n## Coding Guidelines\n\n### Code Formatting\n\nAfter editing Go files, run `crlfmt -w -tab 2 <filename>.go` to format them.\n`crlfmt` is CockroachDB's custom formatter (not `gofmt`); it enforces 100-column\ncode lines, 80-column comments, and CockroachDB-specific signature wrapping. It\nalso handles import grouping. `crlfmt` accepts one path argument at a time\n(either a file or directory).\n\nThe formatter is not used on checked-in, generated files.\n\n### Engineering Standards\n\nCockroachDB is a complex system and you should write code under the assumption\nthat it will have to be understood and modified in the future by readers who\nhave basic familiarity with CockroachDB, but are not experts on the respective\nsubsystem.\n\nKey concepts and abstractions should be explained clearly, and lifecycles and\nownership clearly stated. Whenever possible, you should use examples to make the\ncode accessible to the reader. Comments should always add depth to the code\n(rather than repeating the code).\n\nWhen reviewing, other than technical correctness, you should also focus on the\nabove aspects. Do not over-emphasize on grammar and comment typos, prefix with\n\"nit:\" in reviews.\n\nCockroachDB is a distributed system that allows for rolling upgrades. This means\nthat any shared state or inter-process communication needs to be mindful of\ncompatibility issues.  See `pkg/clusterversion` for more on this.\n\nWhen adding or reviewing a newly added file with a license header the year on\nthe header should be the current year.\n\nFavor modern Go idioms in new or updated code and use the standard library (e.g.\nthe `slices`, `maps`, and `cmp` packages) where appropriate.\n\n### Resources\n\n- **Main Documentation**: https://cockroachlabs.com/docs/stable/\n- **Architecture Guide**: https://www.cockroachlabs.com/docs/stable/architecture/overview.html\n- **Contributing**: See `/CONTRIBUTING.md` and https://wiki.crdb.io/\n- **Design Documents**: `/docs/design.md` and `/docs/tech-notes/`\n\n### When generating PRs and commit records\n\nUse the `/commit-helper` skill when creating commits and PRs.\n\n- For multi-commit PRs, describe the overall goal and the approach taken.\n  Reference individual commits only when needed for orientation (e.g.\n  \"early commits are mechanical refactors; the last two hook everything up\").\n  Don't repeat commit messages — they're visible in the commit list and\n  go stale as the PR evolves.\n- Do not include a test plan unless explicitly asked by the user.\n- Always include an `Epic:` footer in PR descriptions. Use the epic from\n  prior context or attached issues if available, otherwise `Epic: none`.\n\n### Skills\n\nThe following repo-specific skills are available:\n\n- `/commit-helper` — Create commits and PRs with properly formatted messages and release notes.\n- `/file-crdb-issue` — File GitHub issues using CockroachDB templates and labeling conventions.\n- `/review-crdb` — Review code changes or PRs for correctness and reviewability.\n\n# Interaction Style\n\n* Be direct and honest.\n* Skip unnecessary acknowledgments.\n* Correct me when I'm wrong and explain why.\n* Suggest better alternatives if my ideas can be improved.\n* Focus on accuracy and efficiency.\n* Challenge my assumptions when needed.\n* Prioritize quality information and directness.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## CockroachDB Development Environment\n\nCockroachDB is a distributed SQL database written in Go. We use Bazel as a build\nsystem but most operations are wrapped through the `./dev` tool, which should be\npreferred to direct `go (build|test)` or `bazel` invocations.\n\n### Essential Commands\n\n#### Building a package / package tests\n\nThis is useful as a compilation check.\n\n```bash\n# Build package ./pkg/util/log\n./dev build pkg/util/log\n# Build the tests in package ./pkg/util/log\n./dev build pkg/util/log:log_test\n```\n\n#### Testing\n\n```bash\n./dev test pkg/sql                   # run unit tests for SQL package (slow!)\n./dev test pkg/sql -f=TestParse -v   # run specific test pattern\n./dev test pkg/sql --count=5         # run test multiple times\n```\n\nNote that when filtering tests via `-f` to include the `-v` flag which\nwill warn you in the output if your filter didn't match anything. Look\nfor `testing: warning: no tests to run` in the output.\n\nSee `./dev test --help` for all options.\n\n#### Building\n\n```bash\n./dev build cockroach     # build full cockroach binary\n./dev build short         # build cockroach without UI (faster)\n```\n\nBuilding a CockroachDB binary (even in short mode) should be considered\nslow. Avoid doing this unless necessary.\n\nUse `./dev build --help` for the entire list of artifacts that can\nbe built.\n\n#### Code Generation and Linting\n\nProtocol buffers, SQL parser, SQL Optimizer rules and others rely on Go code\ngenerated by `./dev generate <args>`. This should be considered a slow command.\nRebuild only what is actually needed. `./dev (test|build)` commands\nautomatically generate their dependencies, but do not lift them into the\nworktree, i.e. if they need to be visible to you, you need to invoke the\nappropriate `./dev generate` command yourself.\n\n```bash\n./dev generate            # generate all code (protobuf, parsers, etc.) - SLOW\n./dev generate go         # generate Go code only\n./dev generate bazel      # update BUILD.bazel files when dependencies change\n./dev generate protobuf   # generate protobuf files - relatively fast\n```\n\nSee `./dev generate --help`.\n\n### Architecture Overview\n\nCockroachDB consists of many components and subsystems. The file .github/CODEOWNERS is a\ngood starting point if the overall architecture is relevant to the task.\n\n## Coding Guidelines\n\n### Code Formatting\n\nAfter editing Go files, run `crlfmt -w -tab 2 <filename>.go` to format them.\n`crlfmt` is CockroachDB's custom formatter (not `gofmt`); it enforces 100-column\ncode lines, 80-column comments, and CockroachDB-specific signature wrapping. It\nalso handles import grouping. `crlfmt` accepts one path argument at a time\n(either a file or directory).\n\nThe formatter is not used on checked-in, generated files.\n\n### Engineering Standards\n\nCockroachDB is a complex system and you should write code under the assumption\nthat it will have to be understood and modified in the future by readers who\nhave basic familiarity with CockroachDB, but are not experts on the respective\nsubsystem.\n\nKey concepts and abstractions should be explained clearly, and lifecycles and\nownership clearly stated. Whenever possible, you should use examples to make the\ncode accessible to the reader. Comments should always add depth to the code\n(rather than repeating the code).\n\nWhen reviewing, other than technical correctness, you should also focus on the\nabove aspects. Do not over-emphasize on grammar and comment typos, prefix with\n\"nit:\" in reviews.\n\nCockroachDB is a distributed system that allows for rolling upgrades. This means\nthat any shared state or inter-process communication needs to be mindful of\ncompatibility issues.  See `pkg/clusterversion` for more on this.\n\nWhen adding or reviewing a newly added file with a license header the year on\nthe header should be the current year.\n\nFavor modern Go idioms in new or updated code and use the standard library (e.g.\nthe `slices`, `maps`, and `cmp` packages) where appropriate.\n\n### Resources\n\n- **Main Documentation**: https://cockroachlabs.com/docs/stable/\n- **Architecture Guide**: https://www.cockroachlabs.com/docs/stable/architecture/overview.html\n- **Contributing**: See `/CONTRIBUTING.md` and https://wiki.crdb.io/\n- **Design Documents**: `/docs/design.md` and `/docs/tech-notes/`\n\n### When generating PRs and commit records\n\nUse the `/commit-helper` skill when creating commits and PRs.\n\n- For multi-commit PRs, describe the overall goal and the approach taken.\n  Reference individual commits only when needed for orientation (e.g.\n  \"early commits are mechanical refactors; the last two hook everything up\").\n  Don't repeat commit messages — they're visible in the commit list and\n  go stale as the PR evolves.\n- Do not include a test plan unless explicitly asked by the user.\n- Always include an `Epic:` footer in PR descriptions. Use the epic from\n  prior context or attached issues if available, otherwise `Epic: none`.\n\n### Skills\n\nThe following repo-specific skills are available:\n\n- `/commit-helper` — Create commits and PRs with properly formatted messages and release notes.\n- `/file-crdb-issue` — File GitHub issues using CockroachDB templates and labeling conventions.\n- `/review-crdb` — Review code changes or PRs for correctness and reviewability.\n\n# Interaction Style\n\n* Be direct and honest.\n* Skip unnecessary acknowledgments.\n* Correct me when I'm wrong and explain why.\n* Suggest better alternatives if my ideas can be improved.\n* Focus on accuracy and efficiency.\n* Challenge my assumptions when needed.\n* Prioritize quality information and directness.\n","category":"root","tokens":1417}]}