{"owner":"MontFerret","repo":"ferret","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":1700,"categories":["root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\n## Scope\n\nThis file is the canonical operating guide for coding agents working in this\nrepository. It applies to Ferret v2 only. Do not import assumptions from the\nseparate v1 branch unless current v2 code and tests establish the same behavior.\nShared technical policy belongs in the maintainer documentation linked below.\n\n## Sources of truth\n\nUse the most direct repository authority for facts that can change:\n\n* `go.mod` owns the module path and minimum Go version.\n* `Makefile` owns local targets, tool versions, and command composition.\n* `.github/workflows/build.yml` owns the primary CI validation path and tested Go\n  versions; other workflow files own their named automation.\n* Grammar sources under `pkg/parser/antlr` own FQL syntax. Generated parser files\n  are derived output.\n* Current code and tests own architecture and behavior. Historical notes, old\n  branches, and stale comments are not authoritative.\n* `README.md` provides product context, while `CONTRIBUTING.md` describes the\n  human contribution process.\n\nWhen these sources disagree with descriptive documentation, verify the current\nimplementation and correct the documentation rather than copying stale values.\n\n## Maintainer documentation\n\nUse the [maintainer index](docs/maintainers/README.md) to find the owning guide.\nFollow the repository engineering guidance:\n\n* [Engineering principles](docs/maintainers/engineering/principles.md)\n* [Go code style](docs/maintainers/engineering/code-style.md)\n* [Testing and performance](docs/maintainers/engineering/testing.md)\n* [Development workflow](docs/maintainers/engineering/workflow.md)\n\nBefore a substantial change, read the relevant subsystem guide; do not load\nevery guide for unrelated work. Start with\n[Architecture and package ownership](docs/maintainers/architecture/overview.md)\nto locate the owner. For stdlib work, also read the\n[shared standard-library contracts](docs/maintainers/stdlib/README.md) and the\nrelevant category guide.\n\n## Agent engineering discipline\n\nFor every non-trivial change:\n\n1. Identify the owning subsystem and read its maintainer guide.\n2. Identify the contract, invariant, and existing behavior being preserved or\n   intentionally changed.\n3. Choose the smallest implementation that fits the current architecture.\n4. Add or update correctness tests for behavior changes.\n5. Decide whether the change is significant for performance and benchmark it\n   when required.\n6. Run the narrowest relevant validation, then broaden in proportion to risk.\n7. Evaluate documentation impact and update affected repository and public\n   documentation.\n8. Review the complete resulting implementation and diff using the mandatory\n   self-review below.\n9. Fix actual findings and rerun every affected test, check, and benchmark.\n10. Report changed behavior, documentation impact, evidence, review results,\n    and limitations accurately.\n\nA task is not complete merely because the first implementation compiles or its\ntests pass. Do not perform opportunistic refactors unrelated to the requested\nchange.\n\n## Working with generated sources\n\nBefore changing grammar or generator inputs, read and follow the\n[parser generation workflow](docs/maintainers/engineering/workflow.md#parser-generation).\nIdentify the authoritative source inputs and include their derived output in\nthe complete diff review.\n\n## Validation and evidence\n\nSelect validation using the\n[testing and performance policy](docs/maintainers/engineering/testing.md) and\n[development workflow](docs/maintainers/engineering/workflow.md). Rerun checks\naffected by every review-driven fix before reporting completion.\n\nDo not claim that tests, lint, generation, benchmarks, or review passed unless\nthey actually ran successfully. Report tooling or environment limitations\nexplicitly, explain skipped validation, and distinguish blocked checks from\nproduct failures. If a required benchmark cannot run, report the limitation\nwithout claiming benchmark validation. For benchmarks that ran, report exact\ncommands and summarized deltas.\n\n## Mandatory final self-review\n\nAfter implementation and initial validation, review the complete resulting\nchange before considering any non-trivial task finished. This is a second-pass\nevaluation of the implementation, not a confirmation that tests passed.\n\n### Correctness and lifecycle\n\nVerify the task is completely satisfied. Look for missing cases, incorrect\nassumptions, boundary conditions, invalid states, cancellation and concurrency\nerrors, cleanup failures, resource leaks, ownership mistakes, and incorrect\nerror propagation. Confirm public and FQL-visible behavior matches the intended\ncontract. Check idiomatic Go error wrapping, context propagation, synchronization,\nand lifecycle management. For bug fixes, prefer a regression test that fails\nwithout the fix.\n\n### Architecture and API\n\nVerify responsibilities remain in the correct package, type, and layer. Check\ndependency direction, compile-time/runtime separation, runtime-owned semantics,\npublic API necessity, and compatibility against the\n[architecture guides](docs/maintainers/README.md#architecture) and\n[engineering principles](docs/maintainers/engineering/principles.md). Reject\nduplicated semantics, leaked implementation details, misplaced behavior, and\nabstractions at the wrong level.\n\n### Clarity and organization\n\nLook for unnecessary complexity, duplication, nesting, misleading names, dead\nbranches, debugging artifacts, and comments about abandoned approaches. Check\nthe [Go code style guide](docs/maintainers/engineering/code-style.md). Avoid both\noverloaded files and unnecessary fragmentation into excessive helpers or\nabstractions.\n\n### Tests and performance\n\nReview whether tests cover meaningful positive, negative, boundary, error,\ncleanup, and cancellation cases without merely mirroring implementation. Check\nassertion strength and unnecessary brittleness. Use the\n[testing and performance guide](docs/maintainers/engineering/testing.md) to assess\ncoverage and validation. For significant changes, inspect allocations, repeated\nwork, materialization, synchronization, and benchmark comparability.\n\n### Scope and complete diff\n\nInspect the complete final diff, not only individual files. Verify that:\n\n* every changed line belongs to the request or a necessary supporting change;\n* no temporary code, accidental API or behavior change, or unrelated refactor\n  remains;\n* generated files changed only because their source inputs changed;\n* tests describe intended behavior;\n* comments describe current contracts and invariants;\n* file, type, function, and package boundaries remain coherent;\n* resource ownership and lifecycle behavior remain correct;\n* affected repository and public documentation has been updated, or any\n  unavailable external documentation dependency is explicitly reported;\n* the final implementation is the smallest coherent solution.\n\nWhen review finds a correctness, architecture, ownership, lifecycle, API,\norganization, performance, documentation, or meaningful coverage problem, fix\nit and repeat affected validation. Minor optional style preferences do not\njustify churn.\n\nDo not use self-review to expand scope through speculative refactoring,\nunrelated cleanup, unrelated API redesign, broad package moves, or FQL semantic\nchanges outside the task.\n\n## Change and reporting discipline\n\nApply the [engineering principles](docs/maintainers/engineering/principles.md)\nwithin the requested scope. Explain why any necessary supporting cleanup is\nrequired. Call out every intentional FQL semantic change in the final report.\n\nThe final report for a non-trivial change must state:\n\n* owning subsystem and files changed;\n* behavior and invariants preserved or intentionally changed;\n* tests and benchmarks added or updated;\n* validation and benchmark commands actually run;\n* documentation updated, or documentation impact explicitly evaluated as none;\n* completion of the mandatory final self-review;\n* material findings corrected during review;\n* remaining limitations or skipped validation.\n\n## Documentation synchronization\n\nBefore completing every non-trivial task, evaluate documentation impact under\nthe [shared documentation policy](docs/maintainers/engineering/principles.md#documentation-as-part-of-changes)\nand complete the required updates in the same task. Report which documentation\nchanged, or explicitly state why no documentation update was needed.\n\nWhen the website repository or another required documentation source is\navailable, make the necessary changes as part of the task. If it is\nunavailable, identify the exact required follow-up in the final report rather\nthan silently leaving known documentation stale.\n\n## Response style\n\nKeep responses practical and easy to scan. Use short sections, focused bullets,\nand code blocks only for code, commands, or configuration. Explain why a change\nis needed before how it works, summarize each changed file's responsibility, and\navoid repeating the same context.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\n## Scope\n\nThis file is the canonical operating guide for coding agents working in this\nrepository. It applies to Ferret v2 only. Do not import assumptions from the\nseparate v1 branch unless current v2 code and tests establish the same behavior.\nShared technical policy belongs in the maintainer documentation linked below.\n\n## Sources of truth\n\nUse the most direct repository authority for facts that can change:\n\n* `go.mod` owns the module path and minimum Go version.\n* `Makefile` owns local targets, tool versions, and command composition.\n* `.github/workflows/build.yml` owns the primary CI validation path and tested Go\n  versions; other workflow files own their named automation.\n* Grammar sources under `pkg/parser/antlr` own FQL syntax. Generated parser files\n  are derived output.\n* Current code and tests own architecture and behavior. Historical notes, old\n  branches, and stale comments are not authoritative.\n* `README.md` provides product context, while `CONTRIBUTING.md` describes the\n  human contribution process.\n\nWhen these sources disagree with descriptive documentation, verify the current\nimplementation and correct the documentation rather than copying stale values.\n\n## Maintainer documentation\n\nUse the [maintainer index](docs/maintainers/README.md) to find the owning guide.\nFollow the repository engineering guidance:\n\n* [Engineering principles](docs/maintainers/engineering/principles.md)\n* [Go code style](docs/maintainers/engineering/code-style.md)\n* [Testing and performance](docs/maintainers/engineering/testing.md)\n* [Development workflow](docs/maintainers/engineering/workflow.md)\n\nBefore a substantial change, read the relevant subsystem guide; do not load\nevery guide for unrelated work. Start with\n[Architecture and package ownership](docs/maintainers/architecture/overview.md)\nto locate the owner. For stdlib work, also read the\n[shared standard-library contracts](docs/maintainers/stdlib/README.md) and the\nrelevant category guide.\n\n## Agent engineering discipline\n\nFor every non-trivial change:\n\n1. Identify the owning subsystem and read its maintainer guide.\n2. Identify the contract, invariant, and existing behavior being preserved or\n   intentionally changed.\n3. Choose the smallest implementation that fits the current architecture.\n4. Add or update correctness tests for behavior changes.\n5. Decide whether the change is significant for performance and benchmark it\n   when required.\n6. Run the narrowest relevant validation, then broaden in proportion to risk.\n7. Evaluate documentation impact and update affected repository and public\n   documentation.\n8. Review the complete resulting implementation and diff using the mandatory\n   self-review below.\n9. Fix actual findings and rerun every affected test, check, and benchmark.\n10. Report changed behavior, documentation impact, evidence, review results,\n    and limitations accurately.\n\nA task is not complete merely because the first implementation compiles or its\ntests pass. Do not perform opportunistic refactors unrelated to the requested\nchange.\n\n## Working with generated sources\n\nBefore changing grammar or generator inputs, read and follow the\n[parser generation workflow](docs/maintainers/engineering/workflow.md#parser-generation).\nIdentify the authoritative source inputs and include their derived output in\nthe complete diff review.\n\n## Validation and evidence\n\nSelect validation using the\n[testing and performance policy](docs/maintainers/engineering/testing.md) and\n[development workflow](docs/maintainers/engineering/workflow.md). Rerun checks\naffected by every review-driven fix before reporting completion.\n\nDo not claim that tests, lint, generation, benchmarks, or review passed unless\nthey actually ran successfully. Report tooling or environment limitations\nexplicitly, explain skipped validation, and distinguish blocked checks from\nproduct failures. If a required benchmark cannot run, report the limitation\nwithout claiming benchmark validation. For benchmarks that ran, report exact\ncommands and summarized deltas.\n\n## Mandatory final self-review\n\nAfter implementation and initial validation, review the complete resulting\nchange before considering any non-trivial task finished. This is a second-pass\nevaluation of the implementation, not a confirmation that tests passed.\n\n### Correctness and lifecycle\n\nVerify the task is completely satisfied. Look for missing cases, incorrect\nassumptions, boundary conditions, invalid states, cancellation and concurrency\nerrors, cleanup failures, resource leaks, ownership mistakes, and incorrect\nerror propagation. Confirm public and FQL-visible behavior matches the intended\ncontract. Check idiomatic Go error wrapping, context propagation, synchronization,\nand lifecycle management. For bug fixes, prefer a regression test that fails\nwithout the fix.\n\n### Architecture and API\n\nVerify responsibilities remain in the correct package, type, and layer. Check\ndependency direction, compile-time/runtime separation, runtime-owned semantics,\npublic API necessity, and compatibility against the\n[architecture guides](docs/maintainers/README.md#architecture) and\n[engineering principles](docs/maintainers/engineering/principles.md). Reject\nduplicated semantics, leaked implementation details, misplaced behavior, and\nabstractions at the wrong level.\n\n### Clarity and organization\n\nLook for unnecessary complexity, duplication, nesting, misleading names, dead\nbranches, debugging artifacts, and comments about abandoned approaches. Check\nthe [Go code style guide](docs/maintainers/engineering/code-style.md). Avoid both\noverloaded files and unnecessary fragmentation into excessive helpers or\nabstractions.\n\n### Tests and performance\n\nReview whether tests cover meaningful positive, negative, boundary, error,\ncleanup, and cancellation cases without merely mirroring implementation. Check\nassertion strength and unnecessary brittleness. Use the\n[testing and performance guide](docs/maintainers/engineering/testing.md) to assess\ncoverage and validation. For significant changes, inspect allocations, repeated\nwork, materialization, synchronization, and benchmark comparability.\n\n### Scope and complete diff\n\nInspect the complete final diff, not only individual files. Verify that:\n\n* every changed line belongs to the request or a necessary supporting change;\n* no temporary code, accidental API or behavior change, or unrelated refactor\n  remains;\n* generated files changed only because their source inputs changed;\n* tests describe intended behavior;\n* comments describe current contracts and invariants;\n* file, type, function, and package boundaries remain coherent;\n* resource ownership and lifecycle behavior remain correct;\n* affected repository and public documentation has been updated, or any\n  unavailable external documentation dependency is explicitly reported;\n* the final implementation is the smallest coherent solution.\n\nWhen review finds a correctness, architecture, ownership, lifecycle, API,\norganization, performance, documentation, or meaningful coverage problem, fix\nit and repeat affected validation. Minor optional style preferences do not\njustify churn.\n\nDo not use self-review to expand scope through speculative refactoring,\nunrelated cleanup, unrelated API redesign, broad package moves, or FQL semantic\nchanges outside the task.\n\n## Change and reporting discipline\n\nApply the [engineering principles](docs/maintainers/engineering/principles.md)\nwithin the requested scope. Explain why any necessary supporting cleanup is\nrequired. Call out every intentional FQL semantic change in the final report.\n\nThe final report for a non-trivial change must state:\n\n* owning subsystem and files changed;\n* behavior and invariants preserved or intentionally changed;\n* tests and benchmarks added or updated;\n* validation and benchmark commands actually run;\n* documentation updated, or documentation impact explicitly evaluated as none;\n* completion of the mandatory final self-review;\n* material findings corrected during review;\n* remaining limitations or skipped validation.\n\n## Documentation synchronization\n\nBefore completing every non-trivial task, evaluate documentation impact under\nthe [shared documentation policy](docs/maintainers/engineering/principles.md#documentation-as-part-of-changes)\nand complete the required updates in the same task. Report which documentation\nchanged, or explicitly state why no documentation update was needed.\n\nWhen the website repository or another required documentation source is\navailable, make the necessary changes as part of the task. If it is\nunavailable, identify the exact required follow-up in the final report rather\nthan silently leaving known documentation stale.\n\n## Response style\n\nKeep responses practical and easy to scan. Use short sections, focused bullets,\nand code blocks only for code, commands, or configuration. Explain why a change\nis needed before how it works, summarize each changed file's responsibility, and\navoid repeating the same context.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/MontFerret/ferret/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\n## Scope\n\nThis file is the canonical operating guide for coding agents working in this\nrepository. It applies to Ferret v2 only. Do not import assumptions from the\nseparate v1 branch unless current v2 code and tests establish the same behavior.\nShared technical policy belongs in the maintainer documentation linked below.\n\n## Sources of truth\n\nUse the most direct repository authority for facts that can change:\n\n* `go.mod` owns the module path and minimum Go version.\n* `Makefile` owns local targets, tool versions, and command composition.\n* `.github/workflows/build.yml` owns the primary CI validation path and tested Go\n  versions; other workflow files own their named automation.\n* Grammar sources under `pkg/parser/antlr` own FQL syntax. Generated parser files\n  are derived output.\n* Current code and tests own architecture and behavior. Historical notes, old\n  branches, and stale comments are not authoritative.\n* `README.md` provides product context, while `CONTRIBUTING.md` describes the\n  human contribution process.\n\nWhen these sources disagree with descriptive documentation, verify the current\nimplementation and correct the documentation rather than copying stale values.\n\n## Maintainer documentation\n\nUse the [maintainer index](docs/maintainers/README.md) to find the owning guide.\nFollow the repository engineering guidance:\n\n* [Engineering principles](docs/maintainers/engineering/principles.md)\n* [Go code style](docs/maintainers/engineering/code-style.md)\n* [Testing and performance](docs/maintainers/engineering/testing.md)\n* [Development workflow](docs/maintainers/engineering/workflow.md)\n\nBefore a substantial change, read the relevant subsystem guide; do not load\nevery guide for unrelated work. Start with\n[Architecture and package ownership](docs/maintainers/architecture/overview.md)\nto locate the owner. For stdlib work, also read the\n[shared standard-library contracts](docs/maintainers/stdlib/README.md) and the\nrelevant category guide.\n\n## Agent engineering discipline\n\nFor every non-trivial change:\n\n1. Identify the owning subsystem and read its maintainer guide.\n2. Identify the contract, invariant, and existing behavior being preserved or\n   intentionally changed.\n3. Choose the smallest implementation that fits the current architecture.\n4. Add or update correctness tests for behavior changes.\n5. Decide whether the change is significant for performance and benchmark it\n   when required.\n6. Run the narrowest relevant validation, then broaden in proportion to risk.\n7. Evaluate documentation impact and update affected repository and public\n   documentation.\n8. Review the complete resulting implementation and diff using the mandatory\n   self-review below.\n9. Fix actual findings and rerun every affected test, check, and benchmark.\n10. Report changed behavior, documentation impact, evidence, review results,\n    and limitations accurately.\n\nA task is not complete merely because the first implementation compiles or its\ntests pass. Do not perform opportunistic refactors unrelated to the requested\nchange.\n\n## Working with generated sources\n\nBefore changing grammar or generator inputs, read and follow the\n[parser generation workflow](docs/maintainers/engineering/workflow.md#parser-generation).\nIdentify the authoritative source inputs and include their derived output in\nthe complete diff review.\n\n## Validation and evidence\n\nSelect validation using the\n[testing and performance policy](docs/maintainers/engineering/testing.md) and\n[development workflow](docs/maintainers/engineering/workflow.md). Rerun checks\naffected by every review-driven fix before reporting completion.\n\nDo not claim that tests, lint, generation, benchmarks, or review passed unless\nthey actually ran successfully. Report tooling or environment limitations\nexplicitly, explain skipped validation, and distinguish blocked checks from\nproduct failures. If a required benchmark cannot run, report the limitation\nwithout claiming benchmark validation. For benchmarks that ran, report exact\ncommands and summarized deltas.\n\n## Mandatory final self-review\n\nAfter implementation and initial validation, review the complete resulting\nchange before considering any non-trivial task finished. This is a second-pass\nevaluation of the implementation, not a confirmation that tests passed.\n\n### Correctness and lifecycle\n\nVerify the task is completely satisfied. Look for missing cases, incorrect\nassumptions, boundary conditions, invalid states, cancellation and concurrency\nerrors, cleanup failures, resource leaks, ownership mistakes, and incorrect\nerror propagation. Confirm public and FQL-visible behavior matches the intended\ncontract. Check idiomatic Go error wrapping, context propagation, synchronization,\nand lifecycle management. For bug fixes, prefer a regression test that fails\nwithout the fix.\n\n### Architecture and API\n\nVerify responsibilities remain in the correct package, type, and layer. Check\ndependency direction, compile-time/runtime separation, runtime-owned semantics,\npublic API necessity, and compatibility against the\n[architecture guides](docs/maintainers/README.md#architecture) and\n[engineering principles](docs/maintainers/engineering/principles.md). Reject\nduplicated semantics, leaked implementation details, misplaced behavior, and\nabstractions at the wrong level.\n\n### Clarity and organization\n\nLook for unnecessary complexity, duplication, nesting, misleading names, dead\nbranches, debugging artifacts, and comments about abandoned approaches. Check\nthe [Go code style guide](docs/maintainers/engineering/code-style.md). Avoid both\noverloaded files and unnecessary fragmentation into excessive helpers or\nabstractions.\n\n### Tests and performance\n\nReview whether tests cover meaningful positive, negative, boundary, error,\ncleanup, and cancellation cases without merely mirroring implementation. Check\nassertion strength and unnecessary brittleness. Use the\n[testing and performance guide](docs/maintainers/engineering/testing.md) to assess\ncoverage and validation. For significant changes, inspect allocations, repeated\nwork, materialization, synchronization, and benchmark comparability.\n\n### Scope and complete diff\n\nInspect the complete final diff, not only individual files. Verify that:\n\n* every changed line belongs to the request or a necessary supporting change;\n* no temporary code, accidental API or behavior change, or unrelated refactor\n  remains;\n* generated files changed only because their source inputs changed;\n* tests describe intended behavior;\n* comments describe current contracts and invariants;\n* file, type, function, and package boundaries remain coherent;\n* resource ownership and lifecycle behavior remain correct;\n* affected repository and public documentation has been updated, or any\n  unavailable external documentation dependency is explicitly reported;\n* the final implementation is the smallest coherent solution.\n\nWhen review finds a correctness, architecture, ownership, lifecycle, API,\norganization, performance, documentation, or meaningful coverage problem, fix\nit and repeat affected validation. Minor optional style preferences do not\njustify churn.\n\nDo not use self-review to expand scope through speculative refactoring,\nunrelated cleanup, unrelated API redesign, broad package moves, or FQL semantic\nchanges outside the task.\n\n## Change and reporting discipline\n\nApply the [engineering principles](docs/maintainers/engineering/principles.md)\nwithin the requested scope. Explain why any necessary supporting cleanup is\nrequired. Call out every intentional FQL semantic change in the final report.\n\nThe final report for a non-trivial change must state:\n\n* owning subsystem and files changed;\n* behavior and invariants preserved or intentionally changed;\n* tests and benchmarks added or updated;\n* validation and benchmark commands actually run;\n* documentation updated, or documentation impact explicitly evaluated as none;\n* completion of the mandatory final self-review;\n* material findings corrected during review;\n* remaining limitations or skipped validation.\n\n## Documentation synchronization\n\nBefore completing every non-trivial task, evaluate documentation impact under\nthe [shared documentation policy](docs/maintainers/engineering/principles.md#documentation-as-part-of-changes)\nand complete the required updates in the same task. Report which documentation\nchanged, or explicitly state why no documentation update was needed.\n\nWhen the website repository or another required documentation source is\navailable, make the necessary changes as part of the task. If it is\nunavailable, identify the exact required follow-up in the final report rather\nthan silently leaving known documentation stale.\n\n## Response style\n\nKeep responses practical and easy to scan. Use short sections, focused bullets,\nand code blocks only for code, commands, or configuration. Explain why a change\nis needed before how it works, summarize each changed file's responsibility, and\navoid repeating the same context.\n","isInternal":false,"tokens":1700,"sizeBytes":8999}],"systemPromptSnippet":"<yakaai_skills repo=\"MontFerret/ferret\">\n<!-- File: AGENTS.md (Tokens: ~1700 | Category: root-instruction) -->\n# AGENTS.md\n\n## Scope\n\nThis file is the canonical operating guide for coding agents working in this\nrepository. It applies to Ferret v2 only. Do not import assumptions from the\nseparate v1 branch unless current v2 code and tests establish the same behavior.\nShared technical policy belongs in the maintainer documentation linked below.\n\n## Sources of truth\n\nUse the most direct repository authority for facts that can change:\n\n* `go.mod` owns the module path and minimum Go version.\n* `Makefile` owns local targets, tool versions, and command composition.\n* `.github/workflows/build.yml` owns the primary CI validation path and tested Go\n  versions; other workflow files own their named automation.\n* Grammar sources under `pkg/parser/antlr` own FQL syntax. Generated parser files\n  are derived output.\n* Current code and tests own architecture and behavior. Historical notes, old\n  branches, and stale comments are not authoritative.\n* `README.md` provides product context, while `CONTRIBUTING.md` describes the\n  human contribution process.\n\nWhen these sources disagree with descriptive documentation, verify the current\nimplementation and correct the documentation rather than copying stale values.\n\n## Maintainer documentation\n\nUse the [maintainer index](docs/maintainers/README.md) to find the owning guide.\nFollow the repository engineering guidance:\n\n* [Engineering principles](docs/maintainers/engineering/principles.md)\n* [Go code style](docs/maintainers/engineering/code-style.md)\n* [Testing and performance](docs/maintainers/engineering/testing.md)\n* [Development workflow](docs/maintainers/engineering/workflow.md)\n\nBefore a substantial change, read the relevant subsystem guide; do not load\nevery guide for unrelated work. Start with\n[Architecture and package ownership](docs/maintainers/architecture/overview.md)\nto locate the owner. For stdlib work, also read the\n[shared standard-library contracts](docs/maintainers/stdlib/README.md) and the\nrelevant category guide.\n\n## Agent engineering discipline\n\nFor every non-trivial change:\n\n1. Identify the owning subsystem and read its maintainer guide.\n2. Identify the contract, invariant, and existing behavior being preserved or\n   intentionally changed.\n3. Choose the smallest implementation that fits the current architecture.\n4. Add or update correctness tests for behavior changes.\n5. Decide whether the change is significant for performance and benchmark it\n   when required.\n6. Run the narrowest relevant validation, then broaden in proportion to risk.\n7. Evaluate documentation impact and update affected repository and public\n   documentation.\n8. Review the complete resulting implementation and diff using the mandatory\n   self-review below.\n9. Fix actual findings and rerun every affected test, check, and benchmark.\n10. Report changed behavior, documentation impact, evidence, review results,\n    and limitations accurately.\n\nA task is not complete merely because the first implementation compiles or its\ntests pass. Do not perform opportunistic refactors unrelated to the requested\nchange.\n\n## Working with generated sources\n\nBefore changing grammar or generator inputs, read and follow the\n[parser generation workflow](docs/maintainers/engineering/workflow.md#parser-generation).\nIdentify the authoritative source inputs and include their derived output in\nthe complete diff review.\n\n## Validation and evidence\n\nSelect validation using the\n[testing and performance policy](docs/maintainers/engineering/testing.md) and\n[development workflow](docs/maintainers/engineering/workflow.md). Rerun checks\naffected by every review-driven fix before reporting completion.\n\nDo not claim that tests, lint, generation, benchmarks, or review passed unless\nthey actually ran successfully. Report tooling or environment limitations\nexplicitly, explain skipped validation, and distinguish blocked checks from\nproduct failures. If a required benchmark cannot run, report the limitation\nwithout claiming benchmark validation. For benchmarks that ran, report exact\ncommands and summarized deltas.\n\n## Mandatory final self-review\n\nAfter implementation and initial validation, review the complete resulting\nchange before considering any non-trivial task finished. This is a second-pass\nevaluation of the implementation, not a confirmation that tests passed.\n\n### Correctness and lifecycle\n\nVerify the task is completely satisfied. Look for missing cases, incorrect\nassumptions, boundary conditions, invalid states, cancellation and concurrency\nerrors, cleanup failures, resource leaks, ownership mistakes, and incorrect\nerror propagation. Confirm public and FQL-visible behavior matches the intended\ncontract. Check idiomatic Go error wrapping, context propagation, synchronization,\nand lifecycle management. For bug fixes, prefer a regression test that fails\nwithout the fix.\n\n### Architecture and API\n\nVerify responsibilities remain in the correct package, type, and layer. Check\ndependency direction, compile-time/runtime separation, runtime-owned semantics,\npublic API necessity, and compatibility against the\n[architecture guides](docs/maintainers/README.md#architecture) and\n[engineering principles](docs/maintainers/engineering/principles.md). Reject\nduplicated semantics, leaked implementation details, misplaced behavior, and\nabstractions at the wrong level.\n\n### Clarity and organization\n\nLook for unnecessary complexity, duplication, nesting, misleading names, dead\nbranches, debugging artifacts, and comments about abandoned approaches. Check\nthe [Go code style guide](docs/maintainers/engineering/code-style.md). Avoid both\noverloaded files and unnecessary fragmentation into excessive helpers or\nabstractions.\n\n### Tests and performance\n\nReview whether tests cover meaningful positive, negative, boundary, error,\ncleanup, and cancellation cases without merely mirroring implementation. Check\nassertion strength and unnecessary brittleness. Use the\n[testing and performance guide](docs/maintainers/engineering/testing.md) to assess\ncoverage and validation. For significant changes, inspect allocations, repeated\nwork, materialization, synchronization, and benchmark comparability.\n\n### Scope and complete diff\n\nInspect the complete final diff, not only individual files. Verify that:\n\n* every changed line belongs to the request or a necessary supporting change;\n* no temporary code, accidental API or behavior change, or unrelated refactor\n  remains;\n* generated files changed only because their source inputs changed;\n* tests describe intended behavior;\n* comments describe current contracts and invariants;\n* file, type, function, and package boundaries remain coherent;\n* resource ownership and lifecycle behavior remain correct;\n* affected repository and public documentation has been updated, or any\n  unavailable external documentation dependency is explicitly reported;\n* the final implementation is the smallest coherent solution.\n\nWhen review finds a correctness, architecture, ownership, lifecycle, API,\norganization, performance, documentation, or meaningful coverage problem, fix\nit and repeat affected validation. Minor optional style preferences do not\njustify churn.\n\nDo not use self-review to expand scope through speculative refactoring,\nunrelated cleanup, unrelated API redesign, broad package moves, or FQL semantic\nchanges outside the task.\n\n## Change and reporting discipline\n\nApply the [engineering principles](docs/maintainers/engineering/principles.md)\nwithin the requested scope. Explain why any necessary supporting cleanup is\nrequired. Call out every intentional FQL semantic change in the final report.\n\nThe final report for a non-trivial change must state:\n\n* owning subsystem and files changed;\n* behavior and invariants preserved or intentionally changed;\n* tests and benchmarks added or updated;\n* validation and benchmark commands actually run;\n* documentation updated, or documentation impact explicitly evaluated as none;\n* completion of the mandatory final self-review;\n* material findings corrected during review;\n* remaining limitations or skipped validation.\n\n## Documentation synchronization\n\nBefore completing every non-trivial task, evaluate documentation impact under\nthe [shared documentation policy](docs/maintainers/engineering/principles.md#documentation-as-part-of-changes)\nand complete the required updates in the same task. Report which documentation\nchanged, or explicitly state why no documentation update was needed.\n\nWhen the website repository or another required documentation source is\navailable, make the necessary changes as part of the task. If it is\nunavailable, identify the exact required follow-up in the final report rather\nthan silently leaving known documentation stale.\n\n## Response style\n\nKeep responses practical and easy to scan. Use short sections, focused bullets,\nand code blocks only for code, commands, or configuration. Explain why a change\nis needed before how it works, summarize each changed file's responsibility, and\navoid repeating the same context.\n</yakaai_skills>"}