<!-- GENERATED BY generate_skill_wrappers.py; DO NOT EDIT MANUALLY. -->

Generated Claude Code skill — do not edit manually

This complete skill and its bundled resources are generated from agent-plugins/skills/uv-project-workflow/SKILL.md. Manual changes in this directory will be overwritten the next time the generator runs. Edit the canonical skill instead.

uv Project Workflow

Use uv when the repository already chooses it or the user requests its adoption. Make the requested environment/dependency change reproducible while preserving existing work, supported runtimes and source policy.

Route precisely

• Use for explicit uv project setup, dependency/lockfile maintenance, environment diagnosis, CI configuration or an authorized migration to uv.
• Do not choose uv merely because code is Python. Preserve pip, Poetry, Conda or another established workflow unless changing it is in scope.
• Use code-review for an existing manifest/lockfile diff without edits, vet-dependency for whether to adopt a library, and deprecation-and-migration for a live application/API/schema migration. Implementing a FastAPI endpoint is not an environment-management request.
• Distinguish uv's project workflow from its pip-compatible interface, tool environments and standalone scripts; do not mix their sources of truth.

Inspect before mutation

1. Read repository instructions and working-tree state. Identify the owning project/workspace and any nested independent project. Preserve dirty manifests, lockfiles and parallel work.
2. Read pyproject.toml, uv.lock, .python-version, workspace/source/index configuration, existing requirements/constraints, CI and runtime targets. Resolve competing lockfiles or conflicting tool selection before writing.
3. Record the installed uv and Python versions, requested outcome, direct dependencies, groups/extras and platform requirements. Use installed uv --version and command help when available; do not install or upgrade uv simply to inspect a project.
4. Read references/commands-and-effects.md. Confirm relevant flags against the installed version or its matching official docs. State which commands can resolve/download, write caches, change manifests/locks or alter an environment.

Apply only the requested change

• For an existing uv project, change direct requirements intentionally through supported project commands. Preserve constraints, optional extras, dependency groups, private indexes, credentials policy and source mappings. Review both manifest and lock diff.
• For setup or migration, first map the old declared requirements, constraints, Python/runtime matrix and build/test commands. A freeze file can include transitive and environment-specific packages; do not blindly promote all of them to direct dependencies.
• Use uv lock to resolve/update a project lock without installing the project environment. Use supported add/remove/upgrade commands only when those mutations are requested; do not run a broad upgrade to fix one package.
• Choose --locked when consistency with the declared project must be checked. --frozen consumes an existing lock without checking its freshness; use it only when a separate consistency gate or the explicitly intended build policy supplies that assurance.
• Environment synchronization can install/build packages and remove extraneous packages. Inspect execution/build hooks and protect shared environments before syncing. uv run can lock/sync and execute arbitrary project code; it is not an inspection command.
• Use the existing interpreter policy. Do not download Python, change .python-version, activate a shared environment, add an index or migrate the package manager as an incidental step.
• On Windows, use native paths and project commands; uv run normally avoids activation. Do not require Bash, Homebrew or a global install in portable instructions.

Verify reproducibility and behavior

Check the selected dependency graph, lock freshness and the configured targeted application/type/lint checks relevant to the change. Keep environment consistency separate from package behavior and supported-platform coverage. A successful resolver does not prove imports, an optional extra, or the application works.

Prefer isolated environments when installs or builds are needed within the authorized task. Do not execute unreviewed hooks/configuration or access credentials and external services just to produce a green result. If uv, packages, platform access or a safe environment is missing, give the exact unrun check and its effects; do not substitute a different manager without a decision.

For CI changes, verify that the selected groups/extras, Python/uv versions, working directory and lock gate match production needs. A cached environment, skipped job or command that rewrites the lock does not prove reproducibility. Use monitor-ci only when following an actual run is requested.

Report

Return the owning project, tool/runtime versions, intended change, manifest/lock/environment effects, observed checks and untested platform/behavior cells. Explain any migration decision and rollback implications. Do not commit lockfiles or publish packages without authorization.

Adapted and substantially rewritten from wshobson's uv-package-manager, MIT, copyright 2024 Seth Hobson; see LICENSE.wshobson-agents. Changes remove unsupported example flags, universal manager preferences, installation instructions and automatic broad mutations.