What this prompt does
This prompt casts the AI as a senior Python automation engineer and demands a production-ready script for whatever [task_description] you give it — working code, not pseudocode. It lists six deliverables: validated config from [config_method], structured logging to file and console, graceful error handling that alerts via [notification_method], a cron-compatible entry point with a --dry-run flag, an end-of-run summary report, and a requirements.txt plus README.
The structure works because it turns a vague "automate this" into a checklist of the things that separate a real automation from a script that fails silently at 3am. The [task_description] variable drives the logic, while [config_method], [notification_method], and [python_version] make the script configurable, observable, and alertable. The mandated --dry-run flag is the safety valve — it lets you exercise the whole script against real data before it changes anything.
When to use it
- You have a repetitive operational task (file shuffling, sync jobs, report generation) worth automating properly.
- You want logging and failure alerts built in so the job never dies quietly.
- You need a cron-compatible script with a safe
--dry-runmode before it touches real data. - You want a summary report of what was processed, skipped, and failed each run.
- You need the script to ship with
requirements.txtand scheduling instructions, not just a loose file.
Example output
Expect three fenced, copy-ready blocks: the Python script itself (config loading and validation, a logging setup, the task logic wrapped in error handling, a --dry-run branch, and a summary printout), a requirements.txt, and a README with setup and cron scheduling steps. The script uses [python_version]+ features and type hints throughout, and is structured around a cron entry point so it slots straight into a scheduler.
Pro tips
- Write
[task_description]as a precise sentence — the more concrete the task, the less the AI guesses at your intent. - Always run the generated
--dry-runagainst real data first; that's the whole reason the flag is a required deliverable. - Match
[config_method]to how you actually deploy (YAML file, env vars, CLI args) so the config layer fits your environment. - Set
[notification_method]to a channel you monitor — a Slack webhook only helps if someone watches that channel. - Bump
[python_version]to match your runtime so the AI uses (and doesn't exceed) available language features. - Read the summary report logic and tune what counts as "skipped" vs "failed" for your task before trusting the counts.