What this prompt does
This prompt makes the AI design a full Python virtual-environment and dependency-management setup for a real team, scaled by [team_size] and [project_count] and constrained by the [python_versions] and [operating_systems] you actually run. It first compares the tools in [tools_to_evaluate] against criteria like resolution speed and lock-file reliability, produces a decision matrix, and justifies [recommended_tool]. That comparison step is what stops the output from being a generic README and ties it to your environment.
The structure works because reproducibility comes from specifics. [config_file] and [pinning_strategy] define how versions are constrained; [optional_groups] separates docs, notebooks, and profiling dependencies; [ci_platform] and [cache_key] wire it into CI installing from the lock file rather than the manifest; and [security_tool], [allowed_licenses], and [private_repo] cover auditing and private packages. The [env_count] and [common_issues] variables push the AI toward multi-version testing and real troubleshooting instead of a happy path. Because you declare [team_size] and the [operating_systems] in play, the onboarding guide accounts for platform-specific wheels and missing system libraries rather than assuming everyone is on the same machine. The [ci_platform] and [cache_key] pairing makes builds both fast and reproducible, and the [private_repo] variable ensures the guide includes the auth configuration your team actually needs to pull internal packages.
When to use it
- You are starting a Python project and want reproducible builds from day one
- Your team spans macOS, Linux, and Windows and hits works-on-my-machine drift
- You need to standardize tooling across several projects at once
- You want CI that installs from a lock file for guaranteed reproducibility
- You need a dependency audit covering vulnerabilities and license compliance
- You manage private packages and need editable installs for local development
Example output
The AI returns a decision matrix recommending a tool, a complete [config_file] with pinned production and grouped optional dependencies, a step-by-step onboarding guide per OS, a [ci_platform] workflow that installs from the lock file and caches on [cache_key], a dependency-audit workflow, and a Makefile or task runner exposing setup, install, update, lock, test, lint, format, audit, clean, and publish commands with help text.
Pro tips
- List the tools you would genuinely consider in
[tools_to_evaluate]; dropping ones you have ruled out keeps the matrix focused - Be precise in
[pinning_strategy]— minimum versions in the manifest with exact pins in the lock file is what makes CI deterministic - Set
[cache_key]to include the lock-file hash so cache busts correctly when dependencies change - Name your real
[private_repo]so the onboarding guide includes the correct auth configuration - Use
[env_count]to match the Python versions you test against, not an aspirational number - The Makefile is the piece a mixed-OS team relies on daily — keep its command names stable once adopted
