What this prompt does
This prompt asks the AI to build a polished Python CLI tool with the Click framework rather than a loose script. It specifies eight things: a tool named [tool_name] that fulfills [purpose], subcommands [subcommands], [option_count] configurable options with sensible defaults, progress bars, Rich-formatted colored output, a [config_format] config file, --verbose/--quiet flags, shell completion for bash/zsh/fish, and pyproject.toml packaging with entry points — plus tests per subcommand.
The structure works because it turns a throwaway script into a tool people actually use. The [purpose] variable drives the core logic, [subcommands] defines the command surface, and [config_format] plus shell completion make it feel installed and native. Rich output and progress bars are small touches that signal the tool is finished, while the entry-points packaging means it installs as a real command instead of python script.py.
When to use it
- You're packaging internal tooling and want it to feel like a real CLI, not a script.
- You need multiple
[subcommands]under one tool with consistent options and help. - You want progress bars and colored output for long or multi-step operations.
- You need a config file and shell completion so the tool is pleasant to use repeatedly.
- You want the tool installable via
pyproject.tomlentry points with tests per command.
Example output
Expect a packaged CLI: a Click application defining each of [subcommands] as a command, [option_count] options with defaults, Rich-rendered output and progress bars, a loader for [config_format] config, --verbose/--quiet handling, and shell-completion setup. A pyproject.toml with entry points makes [tool_name] runnable as a command after install, and a test exists for each subcommand — a finished, distributable tool rather than a bare script.
Pro tips
- Keep
[subcommands]focused; a tight set (the default is init/generate/validate/serve) reads better than a sprawling command surface. - Set
[option_count]to what each command genuinely needs — options without sensible defaults add friction, not power. - Match
[config_format]to your ecosystem (TOML fits Python tooling well) so the config feels native. - Make
[purpose]concrete; a vague purpose yields subcommands that don't quite hang together. - Test shell completion in your actual shell — generated completion setup often needs a small tweak per shell.
- Build and pip-install the package locally early to confirm the
[tool_name]entry point resolves before adding more commands.
