Every weekend project starts with me asking a model for "a Python script that does X" and getting back a 20-line toy: no argument parsing, prints stack traces at users, returns 0 even when it failed. Then I spend an hour hardening it by hand.
So I built one prompt that front-loads all the boring-but-critical stuff: argparse with --help, real exit codes, --dry-run, and a final self-review pass where the model has to grade its own output against a checklist before it's allowed to finish. The self-check is the part that changed everything, it catches the missing if __name__ guard and the bare except: on its own.
Curious how others word the self-check step so the model actually re-reads its code instead of just claiming it's fine.
Write a single-file Python 3.11+ CLI named `{TOOL_NAME}` that {ONE_SENTENCE_GOAL}.
Hard requirements:
- Use argparse with a program description, `--help` examples in the epilog, and typed args (use `type=`/`choices=`).
- Support `--dry-run` (print what would happen, change nothing) and `--verbose` (enable DEBUG logging).
- Use the `logging` module, never bare `print` for diagnostics; logs go to stderr, real output to stdout.
- Exit codes: 0 success, 1 handled runtime error, 2 bad usage/args. Never let a traceback reach the user; catch, log at ERROR, `sys.exit(1)`.
- Wrap the entry point in `def main(argv=None)` + `if __name__ == "__main__": raise SystemExit(main())` so it is importable and testable.
- Validate every input up front and fail fast with an actionable message.
- No bare `except:`; catch specific exceptions. No global mutable state.
Then, before finishing, output a section titled SELF-CHECK where you re-read your own code and answer YES/NO with a one-line justification for each: (1) does every non-zero exit path log a clear reason? (2) is there any code path that raises to the terminal? (3) does `--dry-run` truly avoid side effects? (4) would `main([])` with no args print help and exit 2? If any answer is NO, fix the code and re-run the checklist before responding.