leogallego

Answer Ansible questions and review Ansible code using official documentation from the Ansible ecosystem. Covers ansible-core, ansible-lint, ansible-navigator, ansible-builder, ansible-creator, and molecule. Use when the user asks about Ansible concepts, syntax, best practices, deprecations, or wants Ansible code reviewed against official docs. Use when user says "check my playbook against docs", "what does Ansible say about X", "how do I use module Y", or "review my role". Do NOT use for CoP good practices review (use ansible-good-practices instead). Do NOT use for general Python or YAML questions unrelated to Ansible.

Review Ansible code against Red Hat CoP automation good practices. Use when the user wants to audit, lint, review, check, or validate Ansible roles, playbooks, collections, or inventory for compliance with CoP rules. Optionally validates module parameters via ansible-know MCP. Use when user says "lint my role", "check my playbook", "review best practices", or "audit my Ansible code". Do NOT use for general Python or YAML linting unrelated to Ansible. Do NOT use for answering Ansible module usage questions or checking syntax against official Ansible documentation (use ansible-docs instead).

Create a new Ansible content collection following all Red Hat CoP good practices. Optionally uses ansible-know MCP tools to discover existing collections on Galaxy and inspect reference collections before scaffolding. Use when the user wants to create, generate, or bootstrap a new Ansible collection. Use when user says "create a collection", "new collection", "scaffold collection", or "init collection". Leverages ansible-creator when available. Do NOT use for reviewing existing collections (use ansible-good-practices instead).

Create a new Ansible execution environment project following good practices. Optionally uses ansible-know MCP tools to validate collection dependencies on Galaxy and pin latest versions. Use when the user wants to create, generate, or bootstrap a new EE. Use when user says "create an EE", "new execution environment", "scaffold EE", or "build EE project". Leverages ansible-creator when available. Do NOT use for building existing EEs or managing containers. Do NOT use for reviewing existing EEs (use ansible-good-practices instead).

Scaffold molecule testing for an Ansible role or collection following the current molecule testing philosophy (Ansible-native everything). Use when the user wants to add molecule tests, create test scenarios, or set up molecule for an existing role or collection. Use when user says "add molecule", "create molecule tests", "scaffold testing", "add test scenarios", or "set up molecule". Generates modern ansible-native molecule.yml (no driver/provisioner/verifier/platforms blocks), working create.yml/destroy.yml playbooks, smart verify.yml from role introspection, and optional GitHub Actions CI. Optionally uses ansible-know MCP server for module return value lookup. Do NOT use for migrating existing molecule setups (migration skill planned for a future release).

Create a new Ansible role following all Red Hat CoP good practices. Use when the user wants to create, generate, or bootstrap a new Ansible role. Use when user says "create a role", "new role", "scaffold role", or "generate role skeleton". Optionally uses ansible-know MCP tools for module-aware task generation with verified parameters. Falls back to template-based generation when MCP is unavailable. Leverages ansible-creator when available. Do NOT use for reviewing existing roles (use ansible-good-practices instead). Do NOT use for creating collections (use ansible-new-collection) or adding molecule tests to existing roles (use ansible-new-molecule).

Display the Zen of Ansible principles and review Ansible code against them. Use when the user wants to see the Zen of Ansible, get philosophical guidance on their automation approach, or review code for simplicity, readability, and clarity. Use when user says "zen of ansible", "simplify my playbook", "is this too complex", or "clean code review". Do NOT use for strict rule compliance (use ansible-good-practices instead). Do NOT use for Ansible module reference or documentation lookups (use ansible-docs instead).