Ansible Task Prompt Generator
Generates a fill-in prompt for asking an AI to write an Ansible task or playbook
About this generator
Ansible playbooks written quickly tend to shell out when a real module exists, omit idempotency checks, and restart services on every run regardless of whether config changed. This tool generates a fill-in prompt that gets an AI assistant to write a playbook that survives a second run without unintended changes. Describe what the playbook should accomplish and pick the target OS: Ubuntu/Debian, RHEL/CentOS, or Any (with `when` conditions for mixed fleets). The prompt requires fully qualified module names, descriptive task names, idempotent operations, handlers on change, parameterised vars, scoped `become: true`, and tags for selective runs. Paste into your assistant, run through `ansible-lint`, and test in a throwaway environment.
How to use
- Describe what the playbook should accomplish.
- Pick the target operating system.
- Click Generate to build the prompt.
- Paste it into your AI assistant and run the result through ansible-lint.
Use Cases
- •Getting an idempotent Ansible playbook from an AI assistant
- •Avoiding shell-module overuse in generated automation
- •Standardising playbook style across an operations team
- •Scaffolding tasks with handlers, vars, and tags
- •Targeting Debian, RHEL, or mixed fleets correctly
Tips
- →State the goal as an outcome, not a list of commands.
- →Ask for handlers so services restart only when config changes.
- →Request tags to run a subset of tasks during testing.
- →Always lint and test in a throwaway environment first.
FAQ
why insist on idempotency in the prompt
Ansible is designed to converge to the same state on every run. A task that always reports `changed` breaks drift detection and makes re-runs risky, which is why the prompt makes idempotency a hard requirement rather than a guideline.
why discourage the shell module
Shell commands bypass Ansible's idempotency and change-reporting. Dedicated modules like `ansible.builtin.apt`, `copy`, and `service` are both safer and accurately report whether anything changed.
how does the OS choice change what the prompt requests
Ubuntu/Debian and RHEL/CentOS tell the assistant which package and service modules to use. The Any option asks it to gate tasks with `when: ansible_os_family == ...` conditions so one playbook works across a mixed fleet without separate files.
You might also like
Popular tools from other categories that share themes with this one.