uv Agent Rules

A Python package and project manager written in Rust.

Overview

uv's root file is a compact list of constraints: run targeted tests, handle fallible operations explicitly, keep dependency updates precise, protect privileged workflows, and write prose for maintainers rather than the agent conversation.

Documents

├── 
├──  · imports AGENTS.md
└──

Patterns in this file

Hard prohibitions Pointing at the source of truth Contribution etiquette

01 / Hard prohibitions

Keep dependency updates precise

The lockfile rule bans updating every dependency and names cargo update --precise as the required mechanism. It gives a concrete boundary for dependency-related diffs.

16- NEVER update all dependencies in the lockfile and ALWAYS use `cargo update --precise` to make17  lockfile changes

02 / Pointing at the source of truth

Use one privileged workflow dispatcher

Webhook-triggered privileged work must go through the existing automation dispatcher. The adjacent rule prohibits suppressing the security lint and asks for a separate dispatcher change when an event is unsupported.

20- ALWAYS use `.github/automations-dispatch.json` to trigger privileged workflows from GitHub webhook21  events instead of adding `pull_request_target` workflows22- NEVER suppress the `dangerous-triggers` security lint; extend the automation dispatcher in a23  separate pull request if it does not support the required event

Make new enum variants require handling

The guide prefers exhaustive match expressions without wildcard arms. Its stated reason is that adding an enum variant should force an explicit decision at each affected match.

11- PREFER exhaustive `match` expressions without wildcard (`_`) arms over `matches!`, so new enum12  variants require explicit handling

04 / Contribution etiquette

Keep conversation history out of project prose

Comments and pull request descriptions are addressed to maintainers who did not see the conversation. The guide also favors descriptions of present behavior and rationale over references to prior iterations.

28- DO NOT leak our conversation, prompt, or iteration history into code comments, pull request29  descriptions, or other maintainer-facing prose. Write for readers who have not seen our30  conversation.31- PREFER comments that explain the current behavior and rationale. Avoid past-facing wording like32  "preserve the existing behavior"; explain the actual backwards-compatibility constraint instead.

Ideas for your repo

Specify the narrow dependency-update operation contributors should use.
Route privileged automation through an existing reviewed entry point.
Prefer exhaustive handling where new variants need deliberate decisions.
Write project prose for readers without the agent conversation.