What agents should know before contributing
astral-sh/uv
An extremely fast Python package and project manager, written in Rust.
Read by Bluet from 3 files written for agents and 300 merged pull requests on 2026-09-24. Not reviewed by the maintainers.
Rules its files tell agents (8)
- AGENTS.md
mustNEVER suppress the dangerous-triggers security lint; extend the automation dispatcher in a separate pull reque…
NEVER suppress the dangerous-triggers security lint; extend the automation dispatcher in a separate pull request if it does not support the required event
- AGENTS.md
mustNEVER assume clippy warnings or test failures are pre-existing, it is very rare that main has warnings
- AGENTS.md
mustNEVER update all dependencies in the lockfile and ALWAYS use cargo update --precise to make lockfile changes
- AGENTS.md
mustNEVER perform builds with the release profile, unless asked or reproducing performance issues
- CONTRIBUTING.md
shouldDo not include a leading v.
After merging the pull request, run the release workflow with the version tag. Do not include a leading v. The release will automatically be created on GitHub after everything else publishes.
- CONTRIBUTING.md
shouldPlease do not open pull requests for new features without prior discussion.
Please do not open pull requests for new features without prior discussion. While we appreciate exploration of new features, we will almost always close these pull requests immediately. Adding a new feature to uv creates a long-term maintenance burden and requires strong consensus from the uv team before it is appropriate to begin work on an implementation.
- CONTRIBUTING.md
shouldPlease do not open pull requests for issues with these labels.
Outside of issues with the labels above, issues labeled as bug are the best candidates for contribution. In contrast, issues labeled with needs-decision or needs-design are not good candidates for contribution. Please do not open pull requests for issues with these labels.
- AGENTS.md
shouldDO NOT leak our conversation, prompt, or iteration history into code comments, pull request descriptions, or o…
DO NOT leak our conversation, prompt, or iteration history into code comments, pull request descriptions, or other maintainer-facing prose. Write for readers who have not seen our conversation.