{"owner":"facebookresearch","repo":"hydra","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nRepo-specific directives for coding agents working in this project.\n\n## Behavioral defaults\n\nThese guidelines are intended to reduce common LLM coding mistakes. Apply them\nalongside the repo-specific rules below. They bias toward caution over speed,\nand for truly trivial tasks you may use judgment.\n\n### Think before coding\n\n- Do not assume.\n- Do not hide confusion.\n- Surface tradeoffs.\n- State assumptions explicitly when they matter to the implementation.\n- If multiple reasonable interpretations exist, present them instead of silently picking one.\n- If a simpler approach exists, say so.\n- Push back when warranted.\n- If something material is unclear or risky, stop, name what is confusing, and ask instead of guessing.\n\n### Simplicity first\n\n- Solve the requested problem with the minimum code necessary.\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No flexibility or configurability that was not requested.\n- No error handling for scenarios that are effectively impossible in context.\n- If a solution feels overbuilt for the task, simplify it before considering it done.\n- If you write 200 lines and the same result could be achieved in 50, rewrite it.\n- Ask: would a senior engineer say this is overcomplicated? If yes, simplify.\n\n### Surgical changes\n\n- Touch only what is needed for the request.\n- Do not \"clean up\" adjacent code, comments, formatting, or structure unless the change requires it.\n- Match the existing style and patterns of the codebase unless the user asks for a broader refactor.\n- If you notice unrelated dead code or issues nearby, mention them instead of fixing them opportunistically.\n- Remove imports, variables, functions, or other artifacts that your change makes unused.\n- Do not delete unrelated pre-existing dead code unless asked.\n- Every changed line should trace directly to the user's request.\n\n### Prefer focused tools over ad hoc shell\n\nUse repository-aware file inspection and edit tools for file operations. Reserve\nshell commands for things that genuinely require shell execution: `sl`\n(Sapling) commands, `gh`, dependency installation, or `nox` / `pytest` /\n`python` for tests, linting, and other repo tooling.\n\n- Use `rg` for text search and `rg --files` for file discovery.\n- Avoid inline Python snippets (`python -c ...`) when a dedicated tool or standard CLI utility is sufficient.\n- Use structured tools such as `jq` to parse JSON shell output instead of piping to Python.\n\n### Goal-driven execution\n\n- Translate requests into concrete success criteria that can be verified.\n- For bug fixes, prefer reproducing the issue with a test or other reliable check before fixing it.\n- For refactors, prefer checks that demonstrate behavior is preserved before and after.\n- For multi-step tasks, keep a brief plan in mind and verify each step before calling the work complete.\n- Favor specific goals over vague ones:\n  - \"Add validation\" -> write tests for invalid inputs, then make them pass.\n  - \"Fix the bug\" -> reproduce it with a test or reliable check, then make it pass.\n  - \"Refactor X\" -> verify behavior before and after the refactor.\n\n## Documentation map\n\n- Website and docs source: [`website/`](./website/)\n- Current docs: [`website/docs/`](./website/docs/)\n- Development docs: [`website/docs/development/`](./website/docs/development/)\n- Plugin docs: [`website/docs/plugins/`](./website/docs/plugins/)\n- Versioned docs: [`website/versioned_docs/`](./website/versioned_docs/)\n\n## Reproduction files\n\nWhen asked to create a reproduction for an issue, place files under `temp/`:\n\n- Single-file repro: `temp/<issue_number>.py`\n- Multi-file repro: `temp/<issue_number>/`\n\n## Stop and ask\n\n- If a tracked repo file appears unexpectedly renamed, moved, regenerated, deleted, or otherwise changed, stop and ask before reverting, recreating, reclassifying, or staging over that change.\n- Do not change supported Python versions, CI matrices, packaging metadata, release automation, or workflow triggers unless the request explicitly includes that scope.\n\n## Verification\n\n- For any new or changed functionality, test it in two layers when practical:\n  - run relevant focused tests with `pytest path/to/test_file.py`\n  - run the relevant `nox` session to ensure no regressions\n- Hydra core tests run with `pytest` from the repository root.\n- Plugin tests run from the plugin directory after installing the plugin, or via `nox -s test_plugins`.\n- Use `PLUGINS=<plugin_dir_name>` with `nox` when validating one plugin.\n- If the broader suite disagrees with focused tests, trust the broader result and do not call the change verified.\n- If live verification is blocked by the current environment, request escalation if that would unblock it. If not, stop and ask for guidance.\n\n## Linting and formatting\n\nRun linting through `nox -s lint lint_plugins` when validating broad changes.\nThe repo's lint sessions include formatting, import sorting, type checks, style,\nYAML linting, and security checks.\n\nFor focused local checks, use the same tools the noxfile runs:\n\n- `ruff format .` / `ruff format --check .`\n- `ruff check .` / `ruff check --fix .`\n- `pyrefly check --config pyproject.toml`\n- `yamllint --strict .`\n- `bandit --exclude ./.nox/** -ll -r .`\n\n## Environment and hooks\n\n- Run commands from the repo-local `.venv` by default. Prefer\n  `.venv/bin/python`, `.venv/bin/pip`, `.venv/bin/pytest`, and\n  `.venv/bin/nox` when those entry points exist.\n- If `.venv` is missing and dependency installation is in scope, create it\n  with `python -m venv .venv`, then install `requirements/dev.txt` and the\n  editable checkout into that environment.\n- Use a separate environment only when testing a specific supported Python\n  version or reproducing an environment-specific issue.\n- When validating contributor setup, shell initialization, or hook behavior, verify it from the same environment a developer would actually use, such as a normal shell session or `sl commit`, not only from a temporary sandbox-only environment.\n- Prefer hooks that do not depend on nontrivial user-environment tooling.\n- If an environment override is required for one command, explain why it must be part of that same process invocation.\n- If a small system tool would materially simplify the workflow, it is fine to suggest it or ask the user to install it.\n\n## Source control and PRs\n\nUse the VCS tooling that matches the current checkout. Some Hydra worktrees are\nSapling (`sl`) checkouts, while others may be plain Git clones.\n\n- Prefer the checkout's native tool for local operations such as status, log, diff, commit, amend, and stack inspection.\n- In a Sapling checkout, use `sl` for normal local VCS operations.\n- Keep escalated VCS commands minimal and single-purpose.\n- Do not bundle staging, environment bootstrapping, dependency installation, and commit creation into one escalated shell command unless there is no practical alternative.\n- If a VCS operation requires escalation, ask only for the specific action that needs it.\n- Do not force-push, submit, or otherwise update a remote branch unless the user explicitly asks for that outward action.\n- Before using low-level fallback commands, such as `git --git-dir .sl/store/git` in a Sapling checkout, stop and explain why the normal workflow is not sufficient.\n\n## Release and news fragments\n\n- Do not commit, push, merge, publish, or otherwise send changes outside the local working tree unless the user explicitly asks for that outward action.\n- If a change alters release automation, workflow triggers, deployment behavior, or other externally visible project mechanics, require an explicit user review checkpoint before any commit, push, merge, publish, or deployment action.\n- All non-trivial product-user-visible changes should have a news fragment.\n- Core Hydra fragments go under `news/`; plugin-specific fragments go under the relevant plugin's `news/` directory.\n- Fragment filenames follow the pattern `<issue_or_pr_number>.<category>`.\n- Supported categories are `api_change`, `feature`, `bugfix`, `docs`, `config`, and `maintenance`.\n- Fragment text must be concise, user-facing, sentence case, and preferably under 80 characters.\n- Developer-only tooling, repo maintenance, and CI-only changes do not need a fragment unless they change the shipped product experience.\n- The user handles releases. Do not edit version numbers, create release files, assemble release notes, or otherwise perform release-cut steps unless explicitly asked.\n- The documented release process lives in [`website/docs/development/release.md`](./website/docs/development/release.md). Do not improvise a manual release flow.\n\n## Reviews\n\n- When asked to review a commit, pull request, or diff, cover correctness, completeness, documentation, and internal consistency.\n- Verify that each product-user-visible change includes an appropriate news fragment and that the fragment matches the implementation and docs.\n",".github/copilot-instructions.md":"# Copilot instructions\n\nWhen generating code or reviewing pull requests for this repository, use\n`CONTRIBUTING.md` as the source of truth for contributor requirements.\n\nFor pull request reviews, check the changed files against the contributor\nguidelines and call out only actionable gaps, especially:\n\n- missing or insufficient tests for code changes;\n- missing documentation updates for API or behavior changes;\n- missing news fragments for non-trivial user-visible changes;\n- news fragments in the wrong `news/` directory or with the wrong category;\n- non-trivial features, API changes, or behavior changes that do not link to\n  prior maintainer agreement in an issue or design discussion;\n- validation claims that are not supported by the tests or checks shown in the\n  pull request.\n\nDo not request a news fragment for developer-only tooling, repository\nmaintenance, or CI-only changes unless the change affects the shipped product\nexperience.\n\nKeep review comments specific and actionable. Prefer pointing to the relevant\nguideline in `CONTRIBUTING.md` over restating the whole policy.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nRepo-specific directives for coding agents working in this project.\n\n## Behavioral defaults\n\nThese guidelines are intended to reduce common LLM coding mistakes. Apply them\nalongside the repo-specific rules below. They bias toward caution over speed,\nand for truly trivial tasks you may use judgment.\n\n### Think before coding\n\n- Do not assume.\n- Do not hide confusion.\n- Surface tradeoffs.\n- State assumptions explicitly when they matter to the implementation.\n- If multiple reasonable interpretations exist, present them instead of silently picking one.\n- If a simpler approach exists, say so.\n- Push back when warranted.\n- If something material is unclear or risky, stop, name what is confusing, and ask instead of guessing.\n\n### Simplicity first\n\n- Solve the requested problem with the minimum code necessary.\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No flexibility or configurability that was not requested.\n- No error handling for scenarios that are effectively impossible in context.\n- If a solution feels overbuilt for the task, simplify it before considering it done.\n- If you write 200 lines and the same result could be achieved in 50, rewrite it.\n- Ask: would a senior engineer say this is overcomplicated? If yes, simplify.\n\n### Surgical changes\n\n- Touch only what is needed for the request.\n- Do not \"clean up\" adjacent code, comments, formatting, or structure unless the change requires it.\n- Match the existing style and patterns of the codebase unless the user asks for a broader refactor.\n- If you notice unrelated dead code or issues nearby, mention them instead of fixing them opportunistically.\n- Remove imports, variables, functions, or other artifacts that your change makes unused.\n- Do not delete unrelated pre-existing dead code unless asked.\n- Every changed line should trace directly to the user's request.\n\n### Prefer focused tools over ad hoc shell\n\nUse repository-aware file inspection and edit tools for file operations. Reserve\nshell commands for things that genuinely require shell execution: `sl`\n(Sapling) commands, `gh`, dependency installation, or `nox` / `pytest` /\n`python` for tests, linting, and other repo tooling.\n\n- Use `rg` for text search and `rg --files` for file discovery.\n- Avoid inline Python snippets (`python -c ...`) when a dedicated tool or standard CLI utility is sufficient.\n- Use structured tools such as `jq` to parse JSON shell output instead of piping to Python.\n\n### Goal-driven execution\n\n- Translate requests into concrete success criteria that can be verified.\n- For bug fixes, prefer reproducing the issue with a test or other reliable check before fixing it.\n- For refactors, prefer checks that demonstrate behavior is preserved before and after.\n- For multi-step tasks, keep a brief plan in mind and verify each step before calling the work complete.\n- Favor specific goals over vague ones:\n  - \"Add validation\" -> write tests for invalid inputs, then make them pass.\n  - \"Fix the bug\" -> reproduce it with a test or reliable check, then make it pass.\n  - \"Refactor X\" -> verify behavior before and after the refactor.\n\n## Documentation map\n\n- Website and docs source: [`website/`](./website/)\n- Current docs: [`website/docs/`](./website/docs/)\n- Development docs: [`website/docs/development/`](./website/docs/development/)\n- Plugin docs: [`website/docs/plugins/`](./website/docs/plugins/)\n- Versioned docs: [`website/versioned_docs/`](./website/versioned_docs/)\n\n## Reproduction files\n\nWhen asked to create a reproduction for an issue, place files under `temp/`:\n\n- Single-file repro: `temp/<issue_number>.py`\n- Multi-file repro: `temp/<issue_number>/`\n\n## Stop and ask\n\n- If a tracked repo file appears unexpectedly renamed, moved, regenerated, deleted, or otherwise changed, stop and ask before reverting, recreating, reclassifying, or staging over that change.\n- Do not change supported Python versions, CI matrices, packaging metadata, release automation, or workflow triggers unless the request explicitly includes that scope.\n\n## Verification\n\n- For any new or changed functionality, test it in two layers when practical:\n  - run relevant focused tests with `pytest path/to/test_file.py`\n  - run the relevant `nox` session to ensure no regressions\n- Hydra core tests run with `pytest` from the repository root.\n- Plugin tests run from the plugin directory after installing the plugin, or via `nox -s test_plugins`.\n- Use `PLUGINS=<plugin_dir_name>` with `nox` when validating one plugin.\n- If the broader suite disagrees with focused tests, trust the broader result and do not call the change verified.\n- If live verification is blocked by the current environment, request escalation if that would unblock it. If not, stop and ask for guidance.\n\n## Linting and formatting\n\nRun linting through `nox -s lint lint_plugins` when validating broad changes.\nThe repo's lint sessions include formatting, import sorting, type checks, style,\nYAML linting, and security checks.\n\nFor focused local checks, use the same tools the noxfile runs:\n\n- `ruff format .` / `ruff format --check .`\n- `ruff check .` / `ruff check --fix .`\n- `pyrefly check --config pyproject.toml`\n- `yamllint --strict .`\n- `bandit --exclude ./.nox/** -ll -r .`\n\n## Environment and hooks\n\n- Run commands from the repo-local `.venv` by default. Prefer\n  `.venv/bin/python`, `.venv/bin/pip`, `.venv/bin/pytest`, and\n  `.venv/bin/nox` when those entry points exist.\n- If `.venv` is missing and dependency installation is in scope, create it\n  with `python -m venv .venv`, then install `requirements/dev.txt` and the\n  editable checkout into that environment.\n- Use a separate environment only when testing a specific supported Python\n  version or reproducing an environment-specific issue.\n- When validating contributor setup, shell initialization, or hook behavior, verify it from the same environment a developer would actually use, such as a normal shell session or `sl commit`, not only from a temporary sandbox-only environment.\n- Prefer hooks that do not depend on nontrivial user-environment tooling.\n- If an environment override is required for one command, explain why it must be part of that same process invocation.\n- If a small system tool would materially simplify the workflow, it is fine to suggest it or ask the user to install it.\n\n## Source control and PRs\n\nUse the VCS tooling that matches the current checkout. Some Hydra worktrees are\nSapling (`sl`) checkouts, while others may be plain Git clones.\n\n- Prefer the checkout's native tool for local operations such as status, log, diff, commit, amend, and stack inspection.\n- In a Sapling checkout, use `sl` for normal local VCS operations.\n- Keep escalated VCS commands minimal and single-purpose.\n- Do not bundle staging, environment bootstrapping, dependency installation, and commit creation into one escalated shell command unless there is no practical alternative.\n- If a VCS operation requires escalation, ask only for the specific action that needs it.\n- Do not force-push, submit, or otherwise update a remote branch unless the user explicitly asks for that outward action.\n- Before using low-level fallback commands, such as `git --git-dir .sl/store/git` in a Sapling checkout, stop and explain why the normal workflow is not sufficient.\n\n## Release and news fragments\n\n- Do not commit, push, merge, publish, or otherwise send changes outside the local working tree unless the user explicitly asks for that outward action.\n- If a change alters release automation, workflow triggers, deployment behavior, or other externally visible project mechanics, require an explicit user review checkpoint before any commit, push, merge, publish, or deployment action.\n- All non-trivial product-user-visible changes should have a news fragment.\n- Core Hydra fragments go under `news/`; plugin-specific fragments go under the relevant plugin's `news/` directory.\n- Fragment filenames follow the pattern `<issue_or_pr_number>.<category>`.\n- Supported categories are `api_change`, `feature`, `bugfix`, `docs`, `config`, and `maintenance`.\n- Fragment text must be concise, user-facing, sentence case, and preferably under 80 characters.\n- Developer-only tooling, repo maintenance, and CI-only changes do not need a fragment unless they change the shipped product experience.\n- The user handles releases. Do not edit version numbers, create release files, assemble release notes, or otherwise perform release-cut steps unless explicitly asked.\n- The documented release process lives in [`website/docs/development/release.md`](./website/docs/development/release.md). Do not improvise a manual release flow.\n\n## Reviews\n\n- When asked to review a commit, pull request, or diff, cover correctness, completeness, documentation, and internal consistency.\n- Verify that each product-user-visible change includes an appropriate news fragment and that the fragment matches the implementation and docs.\n",".github/copilot-instructions.md":"# Copilot instructions\n\nWhen generating code or reviewing pull requests for this repository, use\n`CONTRIBUTING.md` as the source of truth for contributor requirements.\n\nFor pull request reviews, check the changed files against the contributor\nguidelines and call out only actionable gaps, especially:\n\n- missing or insufficient tests for code changes;\n- missing documentation updates for API or behavior changes;\n- missing news fragments for non-trivial user-visible changes;\n- news fragments in the wrong `news/` directory or with the wrong category;\n- non-trivial features, API changes, or behavior changes that do not link to\n  prior maintainer agreement in an issue or design discussion;\n- validation claims that are not supported by the tests or checks shown in the\n  pull request.\n\nDo not request a news fragment for developer-only tooling, repository\nmaintenance, or CI-only changes unless the change affects the shipped product\nexperience.\n\nKeep review comments specific and actionable. Prefer pointing to the relevant\nguideline in `CONTRIBUTING.md` over restating the whole policy.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nRepo-specific directives for coding agents working in this project.\n\n## Behavioral defaults\n\nThese guidelines are intended to reduce common LLM coding mistakes. Apply them\nalongside the repo-specific rules below. They bias toward caution over speed,\nand for truly trivial tasks you may use judgment.\n\n### Think before coding\n\n- Do not assume.\n- Do not hide confusion.\n- Surface tradeoffs.\n- State assumptions explicitly when they matter to the implementation.\n- If multiple reasonable interpretations exist, present them instead of silently picking one.\n- If a simpler approach exists, say so.\n- Push back when warranted.\n- If something material is unclear or risky, stop, name what is confusing, and ask instead of guessing.\n\n### Simplicity first\n\n- Solve the requested problem with the minimum code necessary.\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No flexibility or configurability that was not requested.\n- No error handling for scenarios that are effectively impossible in context.\n- If a solution feels overbuilt for the task, simplify it before considering it done.\n- If you write 200 lines and the same result could be achieved in 50, rewrite it.\n- Ask: would a senior engineer say this is overcomplicated? If yes, simplify.\n\n### Surgical changes\n\n- Touch only what is needed for the request.\n- Do not \"clean up\" adjacent code, comments, formatting, or structure unless the change requires it.\n- Match the existing style and patterns of the codebase unless the user asks for a broader refactor.\n- If you notice unrelated dead code or issues nearby, mention them instead of fixing them opportunistically.\n- Remove imports, variables, functions, or other artifacts that your change makes unused.\n- Do not delete unrelated pre-existing dead code unless asked.\n- Every changed line should trace directly to the user's request.\n\n### Prefer focused tools over ad hoc shell\n\nUse repository-aware file inspection and edit tools for file operations. Reserve\nshell commands for things that genuinely require shell execution: `sl`\n(Sapling) commands, `gh`, dependency installation, or `nox` / `pytest` /\n`python` for tests, linting, and other repo tooling.\n\n- Use `rg` for text search and `rg --files` for file discovery.\n- Avoid inline Python snippets (`python -c ...`) when a dedicated tool or standard CLI utility is sufficient.\n- Use structured tools such as `jq` to parse JSON shell output instead of piping to Python.\n\n### Goal-driven execution\n\n- Translate requests into concrete success criteria that can be verified.\n- For bug fixes, prefer reproducing the issue with a test or other reliable check before fixing it.\n- For refactors, prefer checks that demonstrate behavior is preserved before and after.\n- For multi-step tasks, keep a brief plan in mind and verify each step before calling the work complete.\n- Favor specific goals over vague ones:\n  - \"Add validation\" -> write tests for invalid inputs, then make them pass.\n  - \"Fix the bug\" -> reproduce it with a test or reliable check, then make it pass.\n  - \"Refactor X\" -> verify behavior before and after the refactor.\n\n## Documentation map\n\n- Website and docs source: [`website/`](./website/)\n- Current docs: [`website/docs/`](./website/docs/)\n- Development docs: [`website/docs/development/`](./website/docs/development/)\n- Plugin docs: [`website/docs/plugins/`](./website/docs/plugins/)\n- Versioned docs: [`website/versioned_docs/`](./website/versioned_docs/)\n\n## Reproduction files\n\nWhen asked to create a reproduction for an issue, place files under `temp/`:\n\n- Single-file repro: `temp/<issue_number>.py`\n- Multi-file repro: `temp/<issue_number>/`\n\n## Stop and ask\n\n- If a tracked repo file appears unexpectedly renamed, moved, regenerated, deleted, or otherwise changed, stop and ask before reverting, recreating, reclassifying, or staging over that change.\n- Do not change supported Python versions, CI matrices, packaging metadata, release automation, or workflow triggers unless the request explicitly includes that scope.\n\n## Verification\n\n- For any new or changed functionality, test it in two layers when practical:\n  - run relevant focused tests with `pytest path/to/test_file.py`\n  - run the relevant `nox` session to ensure no regressions\n- Hydra core tests run with `pytest` from the repository root.\n- Plugin tests run from the plugin directory after installing the plugin, or via `nox -s test_plugins`.\n- Use `PLUGINS=<plugin_dir_name>` with `nox` when validating one plugin.\n- If the broader suite disagrees with focused tests, trust the broader result and do not call the change verified.\n- If live verification is blocked by the current environment, request escalation if that would unblock it. If not, stop and ask for guidance.\n\n## Linting and formatting\n\nRun linting through `nox -s lint lint_plugins` when validating broad changes.\nThe repo's lint sessions include formatting, import sorting, type checks, style,\nYAML linting, and security checks.\n\nFor focused local checks, use the same tools the noxfile runs:\n\n- `ruff format .` / `ruff format --check .`\n- `ruff check .` / `ruff check --fix .`\n- `pyrefly check --config pyproject.toml`\n- `yamllint --strict .`\n- `bandit --exclude ./.nox/** -ll -r .`\n\n## Environment and hooks\n\n- Run commands from the repo-local `.venv` by default. Prefer\n  `.venv/bin/python`, `.venv/bin/pip`, `.venv/bin/pytest`, and\n  `.venv/bin/nox` when those entry points exist.\n- If `.venv` is missing and dependency installation is in scope, create it\n  with `python -m venv .venv`, then install `requirements/dev.txt` and the\n  editable checkout into that environment.\n- Use a separate environment only when testing a specific supported Python\n  version or reproducing an environment-specific issue.\n- When validating contributor setup, shell initialization, or hook behavior, verify it from the same environment a developer would actually use, such as a normal shell session or `sl commit`, not only from a temporary sandbox-only environment.\n- Prefer hooks that do not depend on nontrivial user-environment tooling.\n- If an environment override is required for one command, explain why it must be part of that same process invocation.\n- If a small system tool would materially simplify the workflow, it is fine to suggest it or ask the user to install it.\n\n## Source control and PRs\n\nUse the VCS tooling that matches the current checkout. Some Hydra worktrees are\nSapling (`sl`) checkouts, while others may be plain Git clones.\n\n- Prefer the checkout's native tool for local operations such as status, log, diff, commit, amend, and stack inspection.\n- In a Sapling checkout, use `sl` for normal local VCS operations.\n- Keep escalated VCS commands minimal and single-purpose.\n- Do not bundle staging, environment bootstrapping, dependency installation, and commit creation into one escalated shell command unless there is no practical alternative.\n- If a VCS operation requires escalation, ask only for the specific action that needs it.\n- Do not force-push, submit, or otherwise update a remote branch unless the user explicitly asks for that outward action.\n- Before using low-level fallback commands, such as `git --git-dir .sl/store/git` in a Sapling checkout, stop and explain why the normal workflow is not sufficient.\n\n## Release and news fragments\n\n- Do not commit, push, merge, publish, or otherwise send changes outside the local working tree unless the user explicitly asks for that outward action.\n- If a change alters release automation, workflow triggers, deployment behavior, or other externally visible project mechanics, require an explicit user review checkpoint before any commit, push, merge, publish, or deployment action.\n- All non-trivial product-user-visible changes should have a news fragment.\n- Core Hydra fragments go under `news/`; plugin-specific fragments go under the relevant plugin's `news/` directory.\n- Fragment filenames follow the pattern `<issue_or_pr_number>.<category>`.\n- Supported categories are `api_change`, `feature`, `bugfix`, `docs`, `config`, and `maintenance`.\n- Fragment text must be concise, user-facing, sentence case, and preferably under 80 characters.\n- Developer-only tooling, repo maintenance, and CI-only changes do not need a fragment unless they change the shipped product experience.\n- The user handles releases. Do not edit version numbers, create release files, assemble release notes, or otherwise perform release-cut steps unless explicitly asked.\n- The documented release process lives in [`website/docs/development/release.md`](./website/docs/development/release.md). Do not improvise a manual release flow.\n\n## Reviews\n\n- When asked to review a commit, pull request, or diff, cover correctness, completeness, documentation, and internal consistency.\n- Verify that each product-user-visible change includes an appropriate news fragment and that the fragment matches the implementation and docs.\n","category":"root","tokens":2234},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# Copilot instructions\n\nWhen generating code or reviewing pull requests for this repository, use\n`CONTRIBUTING.md` as the source of truth for contributor requirements.\n\nFor pull request reviews, check the changed files against the contributor\nguidelines and call out only actionable gaps, especially:\n\n- missing or insufficient tests for code changes;\n- missing documentation updates for API or behavior changes;\n- missing news fragments for non-trivial user-visible changes;\n- news fragments in the wrong `news/` directory or with the wrong category;\n- non-trivial features, API changes, or behavior changes that do not link to\n  prior maintainer agreement in an issue or design discussion;\n- validation claims that are not supported by the tests or checks shown in the\n  pull request.\n\nDo not request a news fragment for developer-only tooling, repository\nmaintenance, or CI-only changes unless the change affects the shipped product\nexperience.\n\nKeep review comments specific and actionable. Prefer pointing to the relevant\nguideline in `CONTRIBUTING.md` over restating the whole policy.\n","category":".github","tokens":273}]}