simple-modern-uv: Modern Python Project Setup

simple-modern-uv is a minimal, modern Python project template: uv for package management, ruff for linting and formatting, BasedPyright for type checking, pytest, GitHub Actions CI, and tag-driven publishing to PyPI. It is a Copier template, so fully managed projects can pull future template improvements with copier update.

Route the Request

Choose one workflow and load its reference before editing:

User goal	Workflow
Start a project from scratch	Start a new project
Add one or more practices without restructuring everything	Adopt selected features
Convert an existing package to the template’s structure and update path	Upgrade an existing project
Pull upstream changes into a project with .copier-answers.yml	Update a template-managed project

Use references/customize.md for license, publishing, apps, and common policy changes. When something fails, consult references/faq.md before improvising.

If this file was fetched from a URL rather than installed as a folder, fetch the selected reference and any shared reference it names from the same Git ref. Never mix a pinned SKILL.md with references from main.

Choose the Lowest Useful Adoption Level

These are working modes, not certifications:

Level	Result
Selective	Adopt only named feature bundles. Preserve the current build backend, layout, release model, and equivalent tools unless the user asks to change them. Do not add .copier-answers.yml.
Core toolchain	Adopt uv dependency management, lockfile policy, lint/type/test commands, CI, and agent guidance. Preserve packaging, versioning, or layout where changing them has no stated benefit. This is not Copier-managed unless the user chooses full migration.
Full template-managed	Render or migrate to the template structure, record .copier-answers.yml, and use Copier for future updates. Explicitly document any deliberate deviations.

Choose the lowest level that satisfies the request. A named feature request is selective by default. “Upgrade/migrate this project to simple-modern-uv” means full migration unless repository constraints make a lower level safer; surface that change of scope before acting.

Inspect Before Acting

For an existing repository, inspect its instructions and working tree first. Then map:

• project metadata, dependencies, Python support, package layout, and build backend
• current lockfiles, environment manager, linting, typing, tests, and CI
• versioning, release, publishing, license, private-index, and platform constraints
• existing AGENTS.md, CLAUDE.md, .copier-answers.yml, and local modifications

Preserve user work and established behavior. Work on a branch, and never overwrite an existing configuration merely because the template has a different default.

Interview Contract

New projects and full migrations use the template questions in copier.yml. Infer everything possible, then ask the user to confirm material choices once in one batched message.

Answer key	Meaning	Notes
package_name	PyPI package and GitHub repo name	Normalize to kebab-case and show the derived name
package_module	Python module name	Derive snake_case from the package name; show it, do not ask
package_description	One-line description	Infer from existing metadata when possible
package_license	MIT, Apache-2.0, BSD-3-Clause, AGPL-3.0-or-later, Proprietary, or None	Always surface, naming MIT as the new-project default
publish_to_pypi	true or false	Always surface; use false for private packages and unpublished apps

Infer author name, author email, and GitHub organization from project metadata, git, the remote, and authenticated GitHub state. Include the inferred values in the confirmation summary rather than asking separately.

For new projects, apply the template conventions: src/ layout, Python 3.11+, line length 100, and tag-derived versions beginning with v0.1.0. For published migrations, the next tag must exceed the published version. For selective and core adoption, preserve existing choices unless the requested feature requires a change; ask only about those material conflicts.

Always surface changes to supported Python versions, package layout, build backend, versioning, license, publishing, or CI provider. These are project decisions, not incidental implementation details.

Shared Execution Contract

• Use the repository’s reviewed, pinned Copier command and 14-day dependency cool-off.
• Render the template to a temporary sibling directory when a reference implementation is useful. Compare and adapt; do not blindly copy over an existing project.
• Adopt each feature’s complete dependency closure. For example, a locked CI workflow also needs compatible project metadata, uv.toml, uv.lock, and commands.
• Keep equivalent existing tooling when replacement is outside the requested scope.
• Add .copier-answers.yml only for a deliberate full migration. Selective copying does not create honest Copier lineage and must not pretend that it does.
• Keep changes reviewable and report conflicts or deliberate deviations explicitly.

Verification and Handoff

Verify every touched path. Full and core adoption normally require make install, make lint, and make test; publishable projects also require make build. Selective adoption runs the smallest commands that prove the selected features and their failure paths. Validate workflow syntax and preserve existing tests whenever CI changes.

Before reporting success, summarize five categories:

• Adopted: template practices used as designed
• Adapted: practices adjusted to preserve project constraints
• Preserved: existing choices or equivalent tools intentionally retained
• Deferred: relevant practices intentionally left for later
• Removed: superseded files or tooling, if any

Also state whether the result is selective, core, or full template-managed; list the validation commands and outcomes; and name any decision that still belongs to the user.