{"owner":"ethereum","repo":"go-ethereum","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS\n\n## Guidelines\n\n- **Keep changes minimal and focused.** Only modify code directly related to the task at hand. Do not refactor unrelated code, rename existing variables or functions for style, or bundle unrelated fixes into the same commit or PR.\n- **Do not add, remove, or update dependencies** unless the task explicitly requires it.\n\n## Pre-Commit Checklist\n\nBefore every commit, run **all** of the following checks and ensure they pass:\n\n### 1. Formatting\n\nBefore committing, always run `gofmt` and `goimports` on all modified files:\n\n```sh\ngofmt -w <modified files>\ngoimports -w <modified files>\n```\n\n### 2. Build All Commands\n\nVerify that all tools compile successfully:\n\n```sh\nmake all\n```\n\nThis builds all executables under `cmd/`, including `keeper` which has special build requirements.\n\n### 3. Tests\n\nWhile iterating during development, use `-short` for faster feedback:\n\n```sh\ngo run ./build/ci.go test -short\n```\n\nBefore committing, run the full test suite **without** `-short` to ensure all tests pass, including the Ethereum execution-spec tests and all state/block test permutations:\n\n```sh\ngo run ./build/ci.go test\n```\n\n### 4. Linting\n\n```sh\ngo run ./build/ci.go lint\n```\n\nThis runs additional style checks. Fix any issues before committing.\n\n### 5. Generated Code\n\n```sh\ngo run ./build/ci.go check_generate\n```\n\nEnsures that all generated files (e.g., `gen_*.go`) are up to date. If this fails, first install the required code generators by running `make devtools`, then run the appropriate `go generate` commands and include the updated files in your commit.\n\n### 6. Dependency Hygiene\n\n```sh\ngo run ./build/ci.go check_baddeps\n```\n\nVerifies that no forbidden dependencies have been introduced.\n\n## What to include in commits\n\nDo not commit binaries, whether they are produced by the main build or byproducts of investigations.\n\n## Commit Message Format\n\nCommit messages must be prefixed with the package(s) they modify, followed by a short lowercase description:\n\n```\n<package(s)>: description\n```\n\nExamples:\n- `core/vm: fix stack overflow in PUSH instruction`\n- `eth, rpc: make trace configs optional`\n- `cmd/geth: add new flag for sync mode`\n\nUse comma-separated package names when multiple areas are affected. Keep the description concise.\n\n## Pull Request Title Format\n\nPR titles follow the same convention as commit messages:\n\n```\n<list of modified paths>: description\n```\n\nExamples:\n- `core/vm: fix stack overflow in PUSH instruction`\n- `core, eth: add arena allocator support`\n- `cmd/geth, internal/ethapi: refactor transaction args`\n- `trie/archiver: streaming subtree archival to fix OOM`\n\nUse the top-level package paths, comma-separated if multiple areas are affected. Only mention the directories with functional changes, interface changes that trickle all over the codebase should not generate an exhaustive list. The description should be a short, lowercase summary of the change.\n"},"files":{"AGENTS.md":"# AGENTS\n\n## Guidelines\n\n- **Keep changes minimal and focused.** Only modify code directly related to the task at hand. Do not refactor unrelated code, rename existing variables or functions for style, or bundle unrelated fixes into the same commit or PR.\n- **Do not add, remove, or update dependencies** unless the task explicitly requires it.\n\n## Pre-Commit Checklist\n\nBefore every commit, run **all** of the following checks and ensure they pass:\n\n### 1. Formatting\n\nBefore committing, always run `gofmt` and `goimports` on all modified files:\n\n```sh\ngofmt -w <modified files>\ngoimports -w <modified files>\n```\n\n### 2. Build All Commands\n\nVerify that all tools compile successfully:\n\n```sh\nmake all\n```\n\nThis builds all executables under `cmd/`, including `keeper` which has special build requirements.\n\n### 3. Tests\n\nWhile iterating during development, use `-short` for faster feedback:\n\n```sh\ngo run ./build/ci.go test -short\n```\n\nBefore committing, run the full test suite **without** `-short` to ensure all tests pass, including the Ethereum execution-spec tests and all state/block test permutations:\n\n```sh\ngo run ./build/ci.go test\n```\n\n### 4. Linting\n\n```sh\ngo run ./build/ci.go lint\n```\n\nThis runs additional style checks. Fix any issues before committing.\n\n### 5. Generated Code\n\n```sh\ngo run ./build/ci.go check_generate\n```\n\nEnsures that all generated files (e.g., `gen_*.go`) are up to date. If this fails, first install the required code generators by running `make devtools`, then run the appropriate `go generate` commands and include the updated files in your commit.\n\n### 6. Dependency Hygiene\n\n```sh\ngo run ./build/ci.go check_baddeps\n```\n\nVerifies that no forbidden dependencies have been introduced.\n\n## What to include in commits\n\nDo not commit binaries, whether they are produced by the main build or byproducts of investigations.\n\n## Commit Message Format\n\nCommit messages must be prefixed with the package(s) they modify, followed by a short lowercase description:\n\n```\n<package(s)>: description\n```\n\nExamples:\n- `core/vm: fix stack overflow in PUSH instruction`\n- `eth, rpc: make trace configs optional`\n- `cmd/geth: add new flag for sync mode`\n\nUse comma-separated package names when multiple areas are affected. Keep the description concise.\n\n## Pull Request Title Format\n\nPR titles follow the same convention as commit messages:\n\n```\n<list of modified paths>: description\n```\n\nExamples:\n- `core/vm: fix stack overflow in PUSH instruction`\n- `core, eth: add arena allocator support`\n- `cmd/geth, internal/ethapi: refactor transaction args`\n- `trie/archiver: streaming subtree archival to fix OOM`\n\nUse the top-level package paths, comma-separated if multiple areas are affected. Only mention the directories with functional changes, interface changes that trickle all over the codebase should not generate an exhaustive list. The description should be a short, lowercase summary of the change.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS\n\n## Guidelines\n\n- **Keep changes minimal and focused.** Only modify code directly related to the task at hand. Do not refactor unrelated code, rename existing variables or functions for style, or bundle unrelated fixes into the same commit or PR.\n- **Do not add, remove, or update dependencies** unless the task explicitly requires it.\n\n## Pre-Commit Checklist\n\nBefore every commit, run **all** of the following checks and ensure they pass:\n\n### 1. Formatting\n\nBefore committing, always run `gofmt` and `goimports` on all modified files:\n\n```sh\ngofmt -w <modified files>\ngoimports -w <modified files>\n```\n\n### 2. Build All Commands\n\nVerify that all tools compile successfully:\n\n```sh\nmake all\n```\n\nThis builds all executables under `cmd/`, including `keeper` which has special build requirements.\n\n### 3. Tests\n\nWhile iterating during development, use `-short` for faster feedback:\n\n```sh\ngo run ./build/ci.go test -short\n```\n\nBefore committing, run the full test suite **without** `-short` to ensure all tests pass, including the Ethereum execution-spec tests and all state/block test permutations:\n\n```sh\ngo run ./build/ci.go test\n```\n\n### 4. Linting\n\n```sh\ngo run ./build/ci.go lint\n```\n\nThis runs additional style checks. Fix any issues before committing.\n\n### 5. Generated Code\n\n```sh\ngo run ./build/ci.go check_generate\n```\n\nEnsures that all generated files (e.g., `gen_*.go`) are up to date. If this fails, first install the required code generators by running `make devtools`, then run the appropriate `go generate` commands and include the updated files in your commit.\n\n### 6. Dependency Hygiene\n\n```sh\ngo run ./build/ci.go check_baddeps\n```\n\nVerifies that no forbidden dependencies have been introduced.\n\n## What to include in commits\n\nDo not commit binaries, whether they are produced by the main build or byproducts of investigations.\n\n## Commit Message Format\n\nCommit messages must be prefixed with the package(s) they modify, followed by a short lowercase description:\n\n```\n<package(s)>: description\n```\n\nExamples:\n- `core/vm: fix stack overflow in PUSH instruction`\n- `eth, rpc: make trace configs optional`\n- `cmd/geth: add new flag for sync mode`\n\nUse comma-separated package names when multiple areas are affected. Keep the description concise.\n\n## Pull Request Title Format\n\nPR titles follow the same convention as commit messages:\n\n```\n<list of modified paths>: description\n```\n\nExamples:\n- `core/vm: fix stack overflow in PUSH instruction`\n- `core, eth: add arena allocator support`\n- `cmd/geth, internal/ethapi: refactor transaction args`\n- `trie/archiver: streaming subtree archival to fix OOM`\n\nUse the top-level package paths, comma-separated if multiple areas are affected. Only mention the directories with functional changes, interface changes that trickle all over the codebase should not generate an exhaustive list. The description should be a short, lowercase summary of the change.\n","category":"root","tokens":732}]}