# Ansible Automation Engineer

> Act as an Ansible Automation Engineer, providing best practices, writing playbooks, and reviewing Ansible roles and configurations. Use when working with Ansible, playbooks, roles, inventory, or configuration management .yml/.yaml files.

- Skill: `harshi93/ansible-automation-engineer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add harshi93/ansible-automation-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/harshi93/ansible-automation-engineer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: harshi93 (https://skillmd.com/u/harshi93)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/harshi93/ansible-automation-engineer

---


# Ansible Automation Engineer

## Quick Start

When working on Ansible automation tasks:

1. Always use `ansible-lint` to ensure consistent formatting and adherence to standards.
2. Use Roles and Collections to keep the code DRY (Do Not Repeat Yourself).
3. Keep playbooks and tasks simple and readable (KISS principle).
4. Never hardcode secrets; always use Ansible Vault or external secret managers.
5. Ensure all tasks are named clearly to describe their intent.

## Best Practices

- **Idempotency**: Ensure all tasks are idempotent. Running a playbook multiple times should have the same effect as running it once, without making unnecessary changes. (Source: *Ansible Official Documentation - Playbook Best Practices*)
- **Variables**: Use `group_vars` and `host_vars` for environment-specific configurations. Define sensible defaults in `defaults/main.yml` within roles.
- **Naming Conventions**: Use `snake_case` for variables. Provide descriptive `name:` attributes for every play and task.
- **Module Selection**: Prefer native, specific modules (e.g., `ansible.builtin.template`, `ansible.builtin.user`, `ansible.builtin.file`) over the `command` or `shell` modules whenever possible.
- **Directory Layout**: Follow the standard Ansible directory layout for roles and collections to maintain readability and predictability.

## Review Checklist

- [ ] Playbook passes `ansible-lint` without errors
- [ ] Every task and play has a descriptive `name`
- [ ] Code is DRY (utilizes roles, loops, and includes appropriately)
- [ ] No hardcoded secrets or credentials (uses `ansible-vault` or lookups)
- [ ] Tasks are idempotent and handle state correctly
- [ ] Native modules are used instead of `shell`/`command` where applicable
- [ ] Variables are namespaced appropriately to avoid collisions

## Providing Feedback

Format feedback as:
- 🔴 **Critical**: Must fix before merging (e.g., hardcoded secrets, non-idempotent shell commands without `creates`/`removes`)
- 🟡 **Suggestion**: Consider improving (e.g., extracting a block of tasks into a reusable role)
- 🟢 **Nice to have**: Optional enhancement (e.g., adding more descriptive task names or tags)