What this prompt does
This prompt casts the model as a senior Python engineer who ships internal tooling and asks it to build a production-ready CLI using Click, returning working code and a full file tree rather than pseudocode. It defines six deliverables: a src-layout project with pyproject.toml and console_scripts entry points, a Click command group with type hints on every function, Rich for colored output, tables, and progress spinners, clear per-subcommand help and sensible exit codes, a pytest suite using Click's CliRunner, and packaging notes. The structure works because it bakes types, tests, and real exit codes in from the start, which is exactly what stops a one-off script from rotting.
Four variables drive it. [cli_name] names the tool (default devops-cli) and seeds the entry point. [python_version] sets the language target, like Python 3.12. [commands] lists the subcommands — deploy, rollback, status, logs — each becoming a typed Click command. [distribution] describes how it ships, such as internal PyPI plus pipx install, which the packaging notes target. The CliRunner tests in deliverable five are the load-bearing part: wiring them early covers success and error paths and prevents silent breakage as the tool grows and teammates start depending on it.
When to use it
- You are turning a one-off Python script into a real, installable command-line tool.
- You want type hints, tests, and proper exit codes designed in rather than bolted on later.
- A teammate needs to install and trust the CLI, so packaging matters.
- You want Rich output with tables and a progress spinner for long-running calls.
- You need per-subcommand help text and exit codes that distinguish failure classes.
- You want a pytest suite with Click's CliRunner covering success and error paths.
Example output
Expect the file tree first, then each file's full contents in order, all targeting [python_version]. You get a src-layout project with pyproject.toml and console_scripts wiring [cli_name], a Click command group where each entry in [commands] is a typed subcommand, Rich-based colored output with tables and a spinner, clear --help per subcommand with exit codes (0 for success, non-zero per failure class), a pytest suite using CliRunner across success and error paths, and install notes for [distribution]. It is a buildable, installable scaffold rather than a finished product.
Pro tips
- Choose a clean, importable
[cli_name], since it seeds the entry point and the package's module names. - List the real subcommands in
[commands]; each becomes a typed Click command, so vague names produce vague stubs. - Set
[python_version]to what you actually run so type-hint syntax and features match your interpreter. - Describe
[distribution]accurately (pipx, internal PyPI) so the packaging notes are usable, not generic. - Wire the CliRunner cases early; they cover success and error paths and stop silent breakage later.
- Use exit codes per failure class so automation can branch on them rather than parsing stdout.
