{"owner":"mgechev","repo":"revive","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":1997,"categories":["root-instruction"],"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  plus the end-to-end CLI tests (`e2e_test.go`, `package cli_test`) and their fixtures in `cli/testdata/`.\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.26.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\nRun the end-to-end CLI tests:\n\n```sh\ngo test -run TestRevive ./cli/\n```\n\nThese run revive as a subprocess, so they cover what unit tests cannot: exit codes, flag parsing, and output on stdout/stderr.\n\n- The test binary re-executes *itself* as revive: with `REVIVE_E2E_RUN_REVIVE=1` set it calls `RunRevive()` instead of running tests.\n- Fixtures live in `cli/testdata/` (`clean.go` has no failures, `bad.go` has two) and the subprocess runs in that directory.\n  `HOME`, `USERPROFILE` and `XDG_CONFIG_HOME` point at temp dirs, so a local `revive.toml` cannot change the result, and a\n  case can write its own config there with the `homeConfig` and `xdgConfig` fields to cover default config discovery.\n- To cover another flag, exit code, or config error, add a case to the table in `TestRevive` instead of a new test function.\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) with [`test/argument_limit_test.go`](test/argument_limit_test.go).\nThe full checklist — identifier, file and type naming, interfaces, failures, typed vs untyped, registration, tests, and documentation —\nlives in [`.github/instructions/rule.instructions.md`](.github/instructions/rule.instructions.md); it is the single source of truth\nfor rule development and is also what GitHub Copilot applies when reviewing pull requests. Follow it item by item.\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- Star the [repository](https://github.com/revive-lint/revive) before contributing — it helps the project and shows your support.\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 let `Configure` keep state from a previous call: rules are singletons and may be configured more than once,\n  so reset every configurable field to its default before reading the arguments, even on the empty-arguments early return.\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| Rule checklist (PR review)           | `.github/instructions/rule.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  plus the end-to-end CLI tests (`e2e_test.go`, `package cli_test`) and their fixtures in `cli/testdata/`.\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.26.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\nRun the end-to-end CLI tests:\n\n```sh\ngo test -run TestRevive ./cli/\n```\n\nThese run revive as a subprocess, so they cover what unit tests cannot: exit codes, flag parsing, and output on stdout/stderr.\n\n- The test binary re-executes *itself* as revive: with `REVIVE_E2E_RUN_REVIVE=1` set it calls `RunRevive()` instead of running tests.\n- Fixtures live in `cli/testdata/` (`clean.go` has no failures, `bad.go` has two) and the subprocess runs in that directory.\n  `HOME`, `USERPROFILE` and `XDG_CONFIG_HOME` point at temp dirs, so a local `revive.toml` cannot change the result, and a\n  case can write its own config there with the `homeConfig` and `xdgConfig` fields to cover default config discovery.\n- To cover another flag, exit code, or config error, add a case to the table in `TestRevive` instead of a new test function.\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) with [`test/argument_limit_test.go`](test/argument_limit_test.go).\nThe full checklist — identifier, file and type naming, interfaces, failures, typed vs untyped, registration, tests, and documentation —\nlives in [`.github/instructions/rule.instructions.md`](.github/instructions/rule.instructions.md); it is the single source of truth\nfor rule development and is also what GitHub Copilot applies when reviewing pull requests. Follow it item by item.\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- Star the [repository](https://github.com/revive-lint/revive) before contributing — it helps the project and shows your support.\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 let `Configure` keep state from a previous call: rules are singletons and may be configured more than once,\n  so reset every configurable field to its default before reading the arguments, even on the empty-arguments early return.\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| Rule checklist (PR review)           | `.github/instructions/rule.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","rawUrl":"https://raw.githubusercontent.com/mgechev/revive/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","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  plus the end-to-end CLI tests (`e2e_test.go`, `package cli_test`) and their fixtures in `cli/testdata/`.\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.26.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\nRun the end-to-end CLI tests:\n\n```sh\ngo test -run TestRevive ./cli/\n```\n\nThese run revive as a subprocess, so they cover what unit tests cannot: exit codes, flag parsing, and output on stdout/stderr.\n\n- The test binary re-executes *itself* as revive: with `REVIVE_E2E_RUN_REVIVE=1` set it calls `RunRevive()` instead of running tests.\n- Fixtures live in `cli/testdata/` (`clean.go` has no failures, `bad.go` has two) and the subprocess runs in that directory.\n  `HOME`, `USERPROFILE` and `XDG_CONFIG_HOME` point at temp dirs, so a local `revive.toml` cannot change the result, and a\n  case can write its own config there with the `homeConfig` and `xdgConfig` fields to cover default config discovery.\n- To cover another flag, exit code, or config error, add a case to the table in `TestRevive` instead of a new test function.\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) with [`test/argument_limit_test.go`](test/argument_limit_test.go).\nThe full checklist — identifier, file and type naming, interfaces, failures, typed vs untyped, registration, tests, and documentation —\nlives in [`.github/instructions/rule.instructions.md`](.github/instructions/rule.instructions.md); it is the single source of truth\nfor rule development and is also what GitHub Copilot applies when reviewing pull requests. Follow it item by item.\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- Star the [repository](https://github.com/revive-lint/revive) before contributing — it helps the project and shows your support.\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 let `Configure` keep state from a previous call: rules are singletons and may be configured more than once,\n  so reset every configurable field to its default before reading the arguments, even on the empty-arguments early return.\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| Rule checklist (PR review)           | `.github/instructions/rule.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","isInternal":false,"tokens":1997,"sizeBytes":8154}],"systemPromptSnippet":"<yakaai_skills repo=\"mgechev/revive\">\n<!-- File: AGENTS.md (Tokens: ~1997 | Category: root-instruction) -->\n# 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  plus the end-to-end CLI tests (`e2e_test.go`, `package cli_test`) and their fixtures in `cli/testdata/`.\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.26.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\nRun the end-to-end CLI tests:\n\n```sh\ngo test -run TestRevive ./cli/\n```\n\nThese run revive as a subprocess, so they cover what unit tests cannot: exit codes, flag parsing, and output on stdout/stderr.\n\n- The test binary re-executes *itself* as revive: with `REVIVE_E2E_RUN_REVIVE=1` set it calls `RunRevive()` instead of running tests.\n- Fixtures live in `cli/testdata/` (`clean.go` has no failures, `bad.go` has two) and the subprocess runs in that directory.\n  `HOME`, `USERPROFILE` and `XDG_CONFIG_HOME` point at temp dirs, so a local `revive.toml` cannot change the result, and a\n  case can write its own config there with the `homeConfig` and `xdgConfig` fields to cover default config discovery.\n- To cover another flag, exit code, or config error, add a case to the table in `TestRevive` instead of a new test function.\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) with [`test/argument_limit_test.go`](test/argument_limit_test.go).\nThe full checklist — identifier, file and type naming, interfaces, failures, typed vs untyped, registration, tests, and documentation —\nlives in [`.github/instructions/rule.instructions.md`](.github/instructions/rule.instructions.md); it is the single source of truth\nfor rule development and is also what GitHub Copilot applies when reviewing pull requests. Follow it item by item.\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- Star the [repository](https://github.com/revive-lint/revive) before contributing — it helps the project and shows your support.\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 let `Configure` keep state from a previous call: rules are singletons and may be configured more than once,\n  so reset every configurable field to its default before reading the arguments, even on the empty-arguments early return.\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| Rule checklist (PR review)           | `.github/instructions/rule.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</yakaai_skills>"}