uv-developlisted

# uv: the operations models get wrong Routine `uv add <pkg>`, `uv remove <pkg>`, `uv run <cmd>` are correct as-is — do them directly. This skill covers only the cases where the obvious command is the wrong one. ## In a uv project, EVERYTHING runs through uv If the repo has a `uv.lock`, it's a uv project — never reach for bare `python`, `pip`, `pytest`, or a hand-activated venv, even for "just running a quick script". Bare invocations hit the wrong interpreter or an environment missing the project's deps; `uv run` first ensures the venv exists and matches the lock, then runs the command inside it: ```bash uv run python script.py # not: python script.py uv run -m pytest # not: pytest uv run <console-script> # project entry points too uv run --with rich python scratch.py # ad-hoc extra dep, without touching the project ``` ## Upgrade ONE package — not the whole world To bump a single dependency, upgrade **that package only** and re-sync: ```bash uv lock --upgrade-package <pkg> # re-resolve just <pkg> (and only what it forces) uv sync # apply to the venv ``` Do **not** reach for blanket `uv lock --upgrade` / `-U` to "bump requests" — it re-resolves *every* dependency and produces a huge, unreviewable lock diff. Use the blanket form only when the explicit intent is "update everything." Either way, review the `uv.lock` diff and run the tests before committing. `-P` / `--upgrade-package` accepts a constraint too: `u