What this prompt does
This prompt generates Ansible playbooks for [automation_goal] targeting [target_hosts] running [target_os], across [host_count] hosts organized into [inventory_groups]. It builds an inventory in [inventory_format] with group_vars for shared config and host_vars for overrides, then a role named [role_name] whose tasks/main.yml is split into tagged includes (install, configure, deploy, verify), with handlers for [handler_triggers], Jinja2 templates for [template_files], and a documented defaults/main.yml.
It integrates Ansible Vault to encrypt [secret_variables], configures a vault-password-file for CI, and uses inline encrypted strings in group_vars. The emphasis is idempotency: proper modules over shell/command, changed_when/failed_when for [custom_status_checks], and check-mode (--check) compatibility. It adds block/rescue/always error handling for [failure_scenarios] where the rescue tasks run [recovery_actions] and the always tasks log outcomes, a site.yml orchestrating roles with a [serial_strategy] rolling strategy and [pre_checks] pre-tasks, and Molecule testing with a [test_driver] driver plus Testinfra verification. The playbooks that hold up over time are the idempotent ones, which is why the prompt leans so hard on proper modules and honest status checks.
When to use it
- You're configuring Linux servers and want repeatable, idempotent runs
- You need secrets encrypted at rest with Ansible Vault, including in CI
- You want a clean role structure with tagged task phases and handlers
- You need rolling deployments that update hosts in controlled batches
- You want block/rescue error handling with automatic rollback on failure
- You want the role tested with Molecule before it touches real servers
- You're sharing roles across a team and want documented defaults and clear tags
Example output
The AI returns an inventory file, a role directory (tasks, handlers, templates, defaults), vault-encrypted variable examples, idempotent task definitions with changed_when/failed_when, block/rescue/always structures for [failure_scenarios], a site.yml with the [serial_strategy] and [pre_checks], and a Molecule scenario using [test_driver] with Testinfra checks. Expect YAML grouped per numbered section so you can adopt the role, the vault setup, or the error handling on their own.
Pro tips
- Prefer real modules over shell/command for everything in
[automation_goal], since shell commands rarely report changed state correctly - Encrypt every secret in
[secret_variables]with Vault and point CI at a vault-password-file rather than committing the password - Use
changed_whenandfailed_whenfor[custom_status_checks]so tasks report status honestly and stay idempotent - Set
[serial_strategy]conservatively (one host, then a percentage) so a bad deploy doesn't hit the whole fleet at once - Put recovery logic from
[recovery_actions]in rescue blocks so a mid-rollout failure rolls back instead of leaving hosts broken - Run the
[pre_checks]pre-tasks first so you fail fast on disk space or connectivity before touching production - Run the Molecule
[test_driver]scenario in CI so role regressions are caught before production
