{"owner":"astral-sh","repo":"uv","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"- Read CONTRIBUTING.md for guidelines on how to run tools\n- ALWAYS ensure that new tests use the same style as existing tests for all parts of the test\n- ALWAYS check whether the behavior of a new test is already covered by an existing test\n- PREFER integration tests, e.g., at `it/...` over unit tests\n- PREFER running specific tests over running the entire test suite\n- PREFER `insta` snapshots following patterns in nearby tests over substring assertions\n- When making changes for Windows from Unix, use `cargo xwin clippy` to check compilation\n- NEVER perform builds with the release profile, unless asked or reproducing performance issues\n- AVOID using `panic!`, `unreachable!`, `.unwrap()`, unsafe code, and clippy rule ignores\n- PREFER patterns like `if let` to handle fallibility\n- ALWAYS write `SAFETY` comments following our usual style when writing `unsafe` code\n- PREFER `#[expect()]` over `[allow()]` if clippy must be disabled\n- PREFER let chains (`if let` combined with `&&`) over nested `if let` statements\n- NEVER update all dependencies in the lockfile and ALWAYS use `cargo update --precise` to make\n  lockfile changes\n- NEVER assume clippy warnings or test failures are pre-existing, it is very rare that `main` has\n  warnings\n- ALWAYS use `.github/automations-dispatch.json` to trigger privileged workflows from GitHub webhook\n  events instead of adding `pull_request_target` workflows\n- NEVER suppress the `dangerous-triggers` security lint; extend the automation dispatcher in a\n  separate pull request if it does not support the required event\n- PREFER top-level imports over local imports or fully qualified names\n- AVOID shortening variable names, e.g., use `version` instead of `ver`, and `requires_python`\n  instead of `rp`\n- PREFER [`TypeName`] references when writing Rust doc comments\n"},"files":{"AGENTS.md":"- Read CONTRIBUTING.md for guidelines on how to run tools\n- ALWAYS ensure that new tests use the same style as existing tests for all parts of the test\n- ALWAYS check whether the behavior of a new test is already covered by an existing test\n- PREFER integration tests, e.g., at `it/...` over unit tests\n- PREFER running specific tests over running the entire test suite\n- PREFER `insta` snapshots following patterns in nearby tests over substring assertions\n- When making changes for Windows from Unix, use `cargo xwin clippy` to check compilation\n- NEVER perform builds with the release profile, unless asked or reproducing performance issues\n- AVOID using `panic!`, `unreachable!`, `.unwrap()`, unsafe code, and clippy rule ignores\n- PREFER patterns like `if let` to handle fallibility\n- ALWAYS write `SAFETY` comments following our usual style when writing `unsafe` code\n- PREFER `#[expect()]` over `[allow()]` if clippy must be disabled\n- PREFER let chains (`if let` combined with `&&`) over nested `if let` statements\n- NEVER update all dependencies in the lockfile and ALWAYS use `cargo update --precise` to make\n  lockfile changes\n- NEVER assume clippy warnings or test failures are pre-existing, it is very rare that `main` has\n  warnings\n- ALWAYS use `.github/automations-dispatch.json` to trigger privileged workflows from GitHub webhook\n  events instead of adding `pull_request_target` workflows\n- NEVER suppress the `dangerous-triggers` security lint; extend the automation dispatcher in a\n  separate pull request if it does not support the required event\n- PREFER top-level imports over local imports or fully qualified names\n- AVOID shortening variable names, e.g., use `version` instead of `ver`, and `requires_python`\n  instead of `rp`\n- PREFER [`TypeName`] references when writing Rust doc comments\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"- Read CONTRIBUTING.md for guidelines on how to run tools\n- ALWAYS ensure that new tests use the same style as existing tests for all parts of the test\n- ALWAYS check whether the behavior of a new test is already covered by an existing test\n- PREFER integration tests, e.g., at `it/...` over unit tests\n- PREFER running specific tests over running the entire test suite\n- PREFER `insta` snapshots following patterns in nearby tests over substring assertions\n- When making changes for Windows from Unix, use `cargo xwin clippy` to check compilation\n- NEVER perform builds with the release profile, unless asked or reproducing performance issues\n- AVOID using `panic!`, `unreachable!`, `.unwrap()`, unsafe code, and clippy rule ignores\n- PREFER patterns like `if let` to handle fallibility\n- ALWAYS write `SAFETY` comments following our usual style when writing `unsafe` code\n- PREFER `#[expect()]` over `[allow()]` if clippy must be disabled\n- PREFER let chains (`if let` combined with `&&`) over nested `if let` statements\n- NEVER update all dependencies in the lockfile and ALWAYS use `cargo update --precise` to make\n  lockfile changes\n- NEVER assume clippy warnings or test failures are pre-existing, it is very rare that `main` has\n  warnings\n- ALWAYS use `.github/automations-dispatch.json` to trigger privileged workflows from GitHub webhook\n  events instead of adding `pull_request_target` workflows\n- NEVER suppress the `dangerous-triggers` security lint; extend the automation dispatcher in a\n  separate pull request if it does not support the required event\n- PREFER top-level imports over local imports or fully qualified names\n- AVOID shortening variable names, e.g., use `version` instead of `ver`, and `requires_python`\n  instead of `rp`\n- PREFER [`TypeName`] references when writing Rust doc comments\n","category":"root","tokens":454}]}