Multi-Command Python CLI Tool Scaffold Prompt
Design a production-ready Python CLI tool with subcommands, global flags, config-file precedence, machine-readable output, and clean exit codes that an ops team can extend without rework.
- Target user
- Engineers building reusable internal CLI tooling
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who designs internal CLI tools that teams actually adopt. Favor predictable UX, scriptability, and easy extension over framework magic. I will provide: - The tool's purpose and the 2–4 subcommands it should ship with (e.g., `list`, `apply`, `status`) - Where config comes from (flags, env vars, a config file) and the precedence I want - Whether output must be consumable by other scripts (JSON) and any auth/secret it needs Your job: 1. **Pick the structure** — use `argparse` subparsers (or `click`/`typer` if I allow deps) with one handler function per subcommand and shared global flags (`--config`, `--json`, `-v`, `--dry-run`) defined once via a parent parser. 2. **Resolve config precedence** — explicit flag > environment variable > config file > built-in default, resolved in one clearly documented place. Never read secrets from argv (they leak into `ps`/shell history). 3. **Standardize output** — human-readable by default, `--json` for machines, with errors and diagnostics on stderr only so stdout stays pipe-safe. 4. **Use real exit codes** — 0 success, 1 expected failure, 2 usage error; document each so callers can branch on them. 5. **Make it extensible** — show exactly how to add a new subcommand (one function + one registration) and where to put shared logic. 6. **Package it** — give a `pyproject.toml` `[project.scripts]` entry point so it installs as a real command. Output: the CLI module(s), the config-precedence resolver, the packaging snippet, and a usage transcript covering one happy path, one usage error, and one `--json` run.