{"owner":"mgechev","repo":"revive","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nGuidance for AI coding agents (Claude Code, Copilot, Cursor, Codex, etc.) working in this repository.\n\nHuman contributors: see [CONTRIBUTING.md](CONTRIBUTING.md) and [DEVELOPING.md](DEVELOPING.md) first — this file is a complement, not a replacement.\n\n## 1. What this project is\n\n`revive` is a fast, configurable, extensible Go linter.\nIt parses Go source via `go/ast` (+ `go/types` for typed rules), runs a configurable set of rules, and emits findings through pluggable formatters.\n\nTop-level packages:\n\n- `cli/` — command-line entry point (`main.go` defers to `cli.RunRevive`).\n- `lint/` — core linter engine, rule interfaces (`Rule`, `ConfigurableRule`), `File`, `Failure`, `Severity`, and the in-memory `Config` types.\n- `rule/` — one file per rule (100+ rules). Untyped rules also listed in `untyped.toml`.\n- `formatter/` — output formatters (default, json, sarif, stylish, friendly, …).\n- `config/` — config file loading (TOML), defaults, and the registries of available rules and formatters.\n- `revivelib/` — programmatic API for embedding revive.\n- `test/` — rule tests, one `_test.go` per rule.\n- `testdata/` — Go source fixtures consumed by rule tests.\n- `internal/` — helpers not part of the public API.\n\n## 2. Coding standards — read these first\n\nBefore writing Go, read [`.github/instructions/go.instructions.md`](.github/instructions/go.instructions.md).\nIt is the single source of truth for naming, error handling, concurrency, testing style, and modern Go (1.21+) idioms that this project expects.\n**Do not duplicate or contradict it here.**\n\nIn addition to that file:\n\n- The project targets the Go version in [`go.mod`](go.mod) (currently `go 1.25.0`).\n  Use stdlib features available at that version (`min`/`max`, `slices`, `maps`, `cmp.Or`, `errors.Join`, range-over-int, `slog`, etc.)\n  instead of hand-rolled equivalents.\n- `revive` lints itself. Code must pass `revive --config revive.toml ./...` **and** `golangci-lint run`.\n  See [`.golangci.yml`](.golangci.yml) for the strict config.\n\n## 3. Build, test, lint\n\nAll workflows go through the [`Makefile`](Makefile):\n\n```sh\nmake build # builds ./revive with version ldflags\nmake test  # go test -v -race ./...\nmake lint  # revive + golangci-lint\nmake fmt   # golangci-lint fmt\nmake tidy  # go mod tidy -diff (fails on drift)\nmake all   # test + lint + build\n```\n\nRun a single rule's tests:\n\n```sh\ngo test -run TestUnusedParam ./test/...\n```\n\nLogging during local runs: set `REVIVE_LOG_LEVEL` (`debug|info|warn|error`) — logs go to stderr. See [DEVELOPING.md](DEVELOPING.md#logging).\n\n## 4. Adding or modifying a rule\n\nThe canonical example is [`rule/argument_limit.go`](rule/argument_limit.go). For each new rule:\n\n1. **Implementation** — `rule/<rule_name>.go`. Implement `lint.Rule`:\n\n    ```golang\n    Name() string\n    Apply(*lint.File, lint.Arguments) []lint.Failure\n    ```\n\n    If the rule takes arguments, also implement `lint.ConfigurableRule.Configure(lint.Arguments) error`.\n    Validate arguments there and return errors rather than panicking.\n2. **Naming** — `Name()` returns `kebab-case` (e.g. `argument-limit`).\n   The Go type is `ArgumentsLimitRule`. Source file is `argument_limit.go`. Keep these three in lockstep.\n3. **Concurrency** — `Apply` may be called concurrently for different files.\n   Do not mutate rule state from `Apply`. Mutate only in `Configure`, which is called once.\n4. **Typed vs untyped** — if the rule uses `file.Pkg.TypeCheck()` (or anything from `go/types`), it is typed.\n   Otherwise it is untyped and **must** be added to [`untyped.toml`](untyped.toml). Keep that file sorted and in sync.\n5. **Tests** — add `test/<rule_name>_test.go` and a fixture under `testdata/<rule_name>.go` (and `_test.go`, `.gold`, or sub-dirs as needed).\n   Use the existing test harness; do not introduce assertion libraries.\n6. **Documentation** — add a `## <rule-name>` section to [`RULES_DESCRIPTIONS.md`](RULES_DESCRIPTIONS.md), in alphabetical order.\n   Include configuration shape, an `### Examples` block, and a one-line entry in the rules table in [`README.md`](README.md).\n   The TOC in both files is generated by `markdown-toc` (see DEVELOPING.md §Lint Markdown files) — regenerate it; don't hand-edit.\n7. **Defaults** — hard-code defaults as constants in the rule file and apply them in `Configure` when arguments are missing\n   (see `defaultArgumentsLimit` in `rule/argument_limit.go`). Bundle-level defaults live in `defaults.toml` / `revive.toml`.\n8. **Register** — append the rule to `allRules` in [`config/config.go`](config/config.go) so the CLI can discover it.\n\n## 5. Adding a formatter\n\nImplement `lint.Formatter`:\n\n```golang\nFormat(<-chan lint.Failure, lint.Config) (string, error)\nName() string\n```\n\nPlace the implementation in `formatter/<name>.go`, append it to `allFormatters` in [`config/config.go`](config/config.go)\n(so `config.GetFormatter` can find it), and add a row to the formatters table in [`README.md`](README.md).\n\n## 6. Markdown changes\n\n[`README.md`](README.md) and [`RULES_DESCRIPTIONS.md`](RULES_DESCRIPTIONS.md) are linted by `markdownlint-cli2`,\nhave generated tables of contents (`markdown-toc`), and have code snippets formatted by `mdsf`.\nIf you edit them, run the three tools listed in [DEVELOPING.md §Lint Markdown files](DEVELOPING.md#lint-markdown-files) —\nCI will reject hand-edited TOCs and unformatted snippets.\n\nUse ```` ```go ```` for Go code. Use ```` ```golang ```` only for snippets that are intentionally non-compilable.\n\nLine length in this and other Markdown files is capped at 150 characters (200 inside code blocks); wrap accordingly.\n\n## 7. Commits and pull requests\n\n- Match the existing commit style (see `git log`): conventional-style prefixes such as `feature:`, `fix:`, `fix(deps):`, `chore(deps):`,\n  often followed by `#<PR>`.\n- Keep PRs focused and atomic. Open an issue first for non-trivial changes — see [CONTRIBUTING.md](CONTRIBUTING.md).\n- The PR template lives at [`.github/PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md);\n  fill in motivation, test coverage, and link the originating issue.\n- Run `make all` locally before pushing. CI runs the same checks plus Markdown lint, TOC check, and `mdsf verify`.\n\n## 8. Things agents should *not* do\n\n- Don't silence lint findings with `//nolint` or `// revive:disable` to make CI green — fix the underlying code instead.\n  Suppressions need a justification comment and reviewer approval.\n- Don't relax thresholds in [`.golangci.yml`](.golangci.yml) or [`revive.toml`](revive.toml) to avoid fixing a finding.\n- Don't add a dependency without a strong reason; `revive` deliberately keeps its dependency tree small. Run `go mod tidy` afterwards.\n- Don't introduce assertion libraries (`testify`, `gomega`, …) — the project uses the standard `testing` package by design.\n- Don't reformat or restructure files unrelated to the change. Keep diffs reviewable.\n- Don't edit generated TOCs in `README.md` / `RULES_DESCRIPTIONS.md` by hand.\n- Don't add a rule to `untyped.toml` unless you've verified it really doesn't touch type info —\n  getting this wrong silently breaks the untyped fast path.\n\n## 9. Where to look when stuck\n\n| Need                                 | File / dir                                               |\n| ------------------------------------ | -------------------------------------------------------- |\n| Go style and idioms                  | `.github/instructions/go.instructions.md`                |\n| Build / test / lint commands         | `Makefile`, `DEVELOPING.md`                              |\n| How to write a rule (worked example) | `rule/argument_limit.go` + `test/argument_limit_test.go` |\n| Rule interfaces, `File`, `Failure`   | `lint/`                                                  |\n| Default config bundles               | `defaults.toml`, `revive.toml`                           |\n| User-facing rule docs                | `RULES_DESCRIPTIONS.md`                                  |\n| CLI flags & behavior                 | `cli/`                                                   |\n| Programmatic embedding               | `revivelib/`                                             |\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nGuidance for AI coding agents (Claude Code, Copilot, Cursor, Codex, etc.) working in this repository.\n\nHuman contributors: see [CONTRIBUTING.md](CONTRIBUTING.md) and [DEVELOPING.md](DEVELOPING.md) first — this file is a complement, not a replacement.\n\n## 1. What this project is\n\n`revive` is a fast, configurable, extensible Go linter.\nIt parses Go source via `go/ast` (+ `go/types` for typed rules), runs a configurable set of rules, and emits findings through pluggable formatters.\n\nTop-level packages:\n\n- `cli/` — command-line entry point (`main.go` defers to `cli.RunRevive`).\n- `lint/` — core linter engine, rule interfaces (`Rule`, `ConfigurableRule`), `File`, `Failure`, `Severity`, and the in-memory `Config` types.\n- `rule/` — one file per rule (100+ rules). Untyped rules also listed in `untyped.toml`.\n- `formatter/` — output formatters (default, json, sarif, stylish, friendly, …).\n- `config/` — config file loading (TOML), defaults, and the registries of available rules and formatters.\n- `revivelib/` — programmatic API for embedding revive.\n- `test/` — rule tests, one `_test.go` per rule.\n- `testdata/` — Go source fixtures consumed by rule tests.\n- `internal/` — helpers not part of the public API.\n\n## 2. Coding standards — read these first\n\nBefore writing Go, read [`.github/instructions/go.instructions.md`](.github/instructions/go.instructions.md).\nIt is the single source of truth for naming, error handling, concurrency, testing style, and modern Go (1.21+) idioms that this project expects.\n**Do not duplicate or contradict it here.**\n\nIn addition to that file:\n\n- The project targets the Go version in [`go.mod`](go.mod) (currently `go 1.25.0`).\n  Use stdlib features available at that version (`min`/`max`, `slices`, `maps`, `cmp.Or`, `errors.Join`, range-over-int, `slog`, etc.)\n  instead of hand-rolled equivalents.\n- `revive` lints itself. Code must pass `revive --config revive.toml ./...` **and** `golangci-lint run`.\n  See [`.golangci.yml`](.golangci.yml) for the strict config.\n\n## 3. Build, test, lint\n\nAll workflows go through the [`Makefile`](Makefile):\n\n```sh\nmake build # builds ./revive with version ldflags\nmake test  # go test -v -race ./...\nmake lint  # revive + golangci-lint\nmake fmt   # golangci-lint fmt\nmake tidy  # go mod tidy -diff (fails on drift)\nmake all   # test + lint + build\n```\n\nRun a single rule's tests:\n\n```sh\ngo test -run TestUnusedParam ./test/...\n```\n\nLogging during local runs: set `REVIVE_LOG_LEVEL` (`debug|info|warn|error`) — logs go to stderr. See [DEVELOPING.md](DEVELOPING.md#logging).\n\n## 4. Adding or modifying a rule\n\nThe canonical example is [`rule/argument_limit.go`](rule/argument_limit.go). For each new rule:\n\n1. **Implementation** — `rule/<rule_name>.go`. Implement `lint.Rule`:\n\n    ```golang\n    Name() string\n    Apply(*lint.File, lint.Arguments) []lint.Failure\n    ```\n\n    If the rule takes arguments, also implement `lint.ConfigurableRule.Configure(lint.Arguments) error`.\n    Validate arguments there and return errors rather than panicking.\n2. **Naming** — `Name()` returns `kebab-case` (e.g. `argument-limit`).\n   The Go type is `ArgumentsLimitRule`. Source file is `argument_limit.go`. Keep these three in lockstep.\n3. **Concurrency** — `Apply` may be called concurrently for different files.\n   Do not mutate rule state from `Apply`. Mutate only in `Configure`, which is called once.\n4. **Typed vs untyped** — if the rule uses `file.Pkg.TypeCheck()` (or anything from `go/types`), it is typed.\n   Otherwise it is untyped and **must** be added to [`untyped.toml`](untyped.toml). Keep that file sorted and in sync.\n5. **Tests** — add `test/<rule_name>_test.go` and a fixture under `testdata/<rule_name>.go` (and `_test.go`, `.gold`, or sub-dirs as needed).\n   Use the existing test harness; do not introduce assertion libraries.\n6. **Documentation** — add a `## <rule-name>` section to [`RULES_DESCRIPTIONS.md`](RULES_DESCRIPTIONS.md), in alphabetical order.\n   Include configuration shape, an `### Examples` block, and a one-line entry in the rules table in [`README.md`](README.md).\n   The TOC in both files is generated by `markdown-toc` (see DEVELOPING.md §Lint Markdown files) — regenerate it; don't hand-edit.\n7. **Defaults** — hard-code defaults as constants in the rule file and apply them in `Configure` when arguments are missing\n   (see `defaultArgumentsLimit` in `rule/argument_limit.go`). Bundle-level defaults live in `defaults.toml` / `revive.toml`.\n8. **Register** — append the rule to `allRules` in [`config/config.go`](config/config.go) so the CLI can discover it.\n\n## 5. Adding a formatter\n\nImplement `lint.Formatter`:\n\n```golang\nFormat(<-chan lint.Failure, lint.Config) (string, error)\nName() string\n```\n\nPlace the implementation in `formatter/<name>.go`, append it to `allFormatters` in [`config/config.go`](config/config.go)\n(so `config.GetFormatter` can find it), and add a row to the formatters table in [`README.md`](README.md).\n\n## 6. Markdown changes\n\n[`README.md`](README.md) and [`RULES_DESCRIPTIONS.md`](RULES_DESCRIPTIONS.md) are linted by `markdownlint-cli2`,\nhave generated tables of contents (`markdown-toc`), and have code snippets formatted by `mdsf`.\nIf you edit them, run the three tools listed in [DEVELOPING.md §Lint Markdown files](DEVELOPING.md#lint-markdown-files) —\nCI will reject hand-edited TOCs and unformatted snippets.\n\nUse ```` ```go ```` for Go code. Use ```` ```golang ```` only for snippets that are intentionally non-compilable.\n\nLine length in this and other Markdown files is capped at 150 characters (200 inside code blocks); wrap accordingly.\n\n## 7. Commits and pull requests\n\n- Match the existing commit style (see `git log`): conventional-style prefixes such as `feature:`, `fix:`, `fix(deps):`, `chore(deps):`,\n  often followed by `#<PR>`.\n- Keep PRs focused and atomic. Open an issue first for non-trivial changes — see [CONTRIBUTING.md](CONTRIBUTING.md).\n- The PR template lives at [`.github/PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md);\n  fill in motivation, test coverage, and link the originating issue.\n- Run `make all` locally before pushing. CI runs the same checks plus Markdown lint, TOC check, and `mdsf verify`.\n\n## 8. Things agents should *not* do\n\n- Don't silence lint findings with `//nolint` or `// revive:disable` to make CI green — fix the underlying code instead.\n  Suppressions need a justification comment and reviewer approval.\n- Don't relax thresholds in [`.golangci.yml`](.golangci.yml) or [`revive.toml`](revive.toml) to avoid fixing a finding.\n- Don't add a dependency without a strong reason; `revive` deliberately keeps its dependency tree small. Run `go mod tidy` afterwards.\n- Don't introduce assertion libraries (`testify`, `gomega`, …) — the project uses the standard `testing` package by design.\n- Don't reformat or restructure files unrelated to the change. Keep diffs reviewable.\n- Don't edit generated TOCs in `README.md` / `RULES_DESCRIPTIONS.md` by hand.\n- Don't add a rule to `untyped.toml` unless you've verified it really doesn't touch type info —\n  getting this wrong silently breaks the untyped fast path.\n\n## 9. Where to look when stuck\n\n| Need                                 | File / dir                                               |\n| ------------------------------------ | -------------------------------------------------------- |\n| Go style and idioms                  | `.github/instructions/go.instructions.md`                |\n| Build / test / lint commands         | `Makefile`, `DEVELOPING.md`                              |\n| How to write a rule (worked example) | `rule/argument_limit.go` + `test/argument_limit_test.go` |\n| Rule interfaces, `File`, `Failure`   | `lint/`                                                  |\n| Default config bundles               | `defaults.toml`, `revive.toml`                           |\n| User-facing rule docs                | `RULES_DESCRIPTIONS.md`                                  |\n| CLI flags & behavior                 | `cli/`                                                   |\n| Programmatic embedding               | `revivelib/`                                             |\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nGuidance for AI coding agents (Claude Code, Copilot, Cursor, Codex, etc.) working in this repository.\n\nHuman contributors: see [CONTRIBUTING.md](CONTRIBUTING.md) and [DEVELOPING.md](DEVELOPING.md) first — this file is a complement, not a replacement.\n\n## 1. What this project is\n\n`revive` is a fast, configurable, extensible Go linter.\nIt parses Go source via `go/ast` (+ `go/types` for typed rules), runs a configurable set of rules, and emits findings through pluggable formatters.\n\nTop-level packages:\n\n- `cli/` — command-line entry point (`main.go` defers to `cli.RunRevive`).\n- `lint/` — core linter engine, rule interfaces (`Rule`, `ConfigurableRule`), `File`, `Failure`, `Severity`, and the in-memory `Config` types.\n- `rule/` — one file per rule (100+ rules). Untyped rules also listed in `untyped.toml`.\n- `formatter/` — output formatters (default, json, sarif, stylish, friendly, …).\n- `config/` — config file loading (TOML), defaults, and the registries of available rules and formatters.\n- `revivelib/` — programmatic API for embedding revive.\n- `test/` — rule tests, one `_test.go` per rule.\n- `testdata/` — Go source fixtures consumed by rule tests.\n- `internal/` — helpers not part of the public API.\n\n## 2. Coding standards — read these first\n\nBefore writing Go, read [`.github/instructions/go.instructions.md`](.github/instructions/go.instructions.md).\nIt is the single source of truth for naming, error handling, concurrency, testing style, and modern Go (1.21+) idioms that this project expects.\n**Do not duplicate or contradict it here.**\n\nIn addition to that file:\n\n- The project targets the Go version in [`go.mod`](go.mod) (currently `go 1.25.0`).\n  Use stdlib features available at that version (`min`/`max`, `slices`, `maps`, `cmp.Or`, `errors.Join`, range-over-int, `slog`, etc.)\n  instead of hand-rolled equivalents.\n- `revive` lints itself. Code must pass `revive --config revive.toml ./...` **and** `golangci-lint run`.\n  See [`.golangci.yml`](.golangci.yml) for the strict config.\n\n## 3. Build, test, lint\n\nAll workflows go through the [`Makefile`](Makefile):\n\n```sh\nmake build # builds ./revive with version ldflags\nmake test  # go test -v -race ./...\nmake lint  # revive + golangci-lint\nmake fmt   # golangci-lint fmt\nmake tidy  # go mod tidy -diff (fails on drift)\nmake all   # test + lint + build\n```\n\nRun a single rule's tests:\n\n```sh\ngo test -run TestUnusedParam ./test/...\n```\n\nLogging during local runs: set `REVIVE_LOG_LEVEL` (`debug|info|warn|error`) — logs go to stderr. See [DEVELOPING.md](DEVELOPING.md#logging).\n\n## 4. Adding or modifying a rule\n\nThe canonical example is [`rule/argument_limit.go`](rule/argument_limit.go). For each new rule:\n\n1. **Implementation** — `rule/<rule_name>.go`. Implement `lint.Rule`:\n\n    ```golang\n    Name() string\n    Apply(*lint.File, lint.Arguments) []lint.Failure\n    ```\n\n    If the rule takes arguments, also implement `lint.ConfigurableRule.Configure(lint.Arguments) error`.\n    Validate arguments there and return errors rather than panicking.\n2. **Naming** — `Name()` returns `kebab-case` (e.g. `argument-limit`).\n   The Go type is `ArgumentsLimitRule`. Source file is `argument_limit.go`. Keep these three in lockstep.\n3. **Concurrency** — `Apply` may be called concurrently for different files.\n   Do not mutate rule state from `Apply`. Mutate only in `Configure`, which is called once.\n4. **Typed vs untyped** — if the rule uses `file.Pkg.TypeCheck()` (or anything from `go/types`), it is typed.\n   Otherwise it is untyped and **must** be added to [`untyped.toml`](untyped.toml). Keep that file sorted and in sync.\n5. **Tests** — add `test/<rule_name>_test.go` and a fixture under `testdata/<rule_name>.go` (and `_test.go`, `.gold`, or sub-dirs as needed).\n   Use the existing test harness; do not introduce assertion libraries.\n6. **Documentation** — add a `## <rule-name>` section to [`RULES_DESCRIPTIONS.md`](RULES_DESCRIPTIONS.md), in alphabetical order.\n   Include configuration shape, an `### Examples` block, and a one-line entry in the rules table in [`README.md`](README.md).\n   The TOC in both files is generated by `markdown-toc` (see DEVELOPING.md §Lint Markdown files) — regenerate it; don't hand-edit.\n7. **Defaults** — hard-code defaults as constants in the rule file and apply them in `Configure` when arguments are missing\n   (see `defaultArgumentsLimit` in `rule/argument_limit.go`). Bundle-level defaults live in `defaults.toml` / `revive.toml`.\n8. **Register** — append the rule to `allRules` in [`config/config.go`](config/config.go) so the CLI can discover it.\n\n## 5. Adding a formatter\n\nImplement `lint.Formatter`:\n\n```golang\nFormat(<-chan lint.Failure, lint.Config) (string, error)\nName() string\n```\n\nPlace the implementation in `formatter/<name>.go`, append it to `allFormatters` in [`config/config.go`](config/config.go)\n(so `config.GetFormatter` can find it), and add a row to the formatters table in [`README.md`](README.md).\n\n## 6. Markdown changes\n\n[`README.md`](README.md) and [`RULES_DESCRIPTIONS.md`](RULES_DESCRIPTIONS.md) are linted by `markdownlint-cli2`,\nhave generated tables of contents (`markdown-toc`), and have code snippets formatted by `mdsf`.\nIf you edit them, run the three tools listed in [DEVELOPING.md §Lint Markdown files](DEVELOPING.md#lint-markdown-files) —\nCI will reject hand-edited TOCs and unformatted snippets.\n\nUse ```` ```go ```` for Go code. Use ```` ```golang ```` only for snippets that are intentionally non-compilable.\n\nLine length in this and other Markdown files is capped at 150 characters (200 inside code blocks); wrap accordingly.\n\n## 7. Commits and pull requests\n\n- Match the existing commit style (see `git log`): conventional-style prefixes such as `feature:`, `fix:`, `fix(deps):`, `chore(deps):`,\n  often followed by `#<PR>`.\n- Keep PRs focused and atomic. Open an issue first for non-trivial changes — see [CONTRIBUTING.md](CONTRIBUTING.md).\n- The PR template lives at [`.github/PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md);\n  fill in motivation, test coverage, and link the originating issue.\n- Run `make all` locally before pushing. CI runs the same checks plus Markdown lint, TOC check, and `mdsf verify`.\n\n## 8. Things agents should *not* do\n\n- Don't silence lint findings with `//nolint` or `// revive:disable` to make CI green — fix the underlying code instead.\n  Suppressions need a justification comment and reviewer approval.\n- Don't relax thresholds in [`.golangci.yml`](.golangci.yml) or [`revive.toml`](revive.toml) to avoid fixing a finding.\n- Don't add a dependency without a strong reason; `revive` deliberately keeps its dependency tree small. Run `go mod tidy` afterwards.\n- Don't introduce assertion libraries (`testify`, `gomega`, …) — the project uses the standard `testing` package by design.\n- Don't reformat or restructure files unrelated to the change. Keep diffs reviewable.\n- Don't edit generated TOCs in `README.md` / `RULES_DESCRIPTIONS.md` by hand.\n- Don't add a rule to `untyped.toml` unless you've verified it really doesn't touch type info —\n  getting this wrong silently breaks the untyped fast path.\n\n## 9. Where to look when stuck\n\n| Need                                 | File / dir                                               |\n| ------------------------------------ | -------------------------------------------------------- |\n| Go style and idioms                  | `.github/instructions/go.instructions.md`                |\n| Build / test / lint commands         | `Makefile`, `DEVELOPING.md`                              |\n| How to write a rule (worked example) | `rule/argument_limit.go` + `test/argument_limit_test.go` |\n| Rule interfaces, `File`, `Failure`   | `lint/`                                                  |\n| Default config bundles               | `defaults.toml`, `revive.toml`                           |\n| User-facing rule docs                | `RULES_DESCRIPTIONS.md`                                  |\n| CLI flags & behavior                 | `cli/`                                                   |\n| Programmatic embedding               | `revivelib/`                                             |\n","category":"root","tokens":2040}]}