ansible-fundamentals
Core principles and golden rules for writing production-quality Ansible automation, covering FQCN requirements, module selection guidance, and execution patterns using uv run.
What this skill does
# Ansible Fundamentals
Core principles and golden rules for writing production-quality Ansible automation.
## Golden Rules
These rules apply to ALL Ansible code in this repository:
1. **Use `uv run` prefix** - Execute all Ansible commands through uv:
```bash
uv run ansible-playbook playbooks/my-playbook.yml
uv run ansible-lint
uv run ansible-galaxy collection install -r requirements.yml
```
2. **Fully Qualified Collection Names (FQCN)** - Avoid short module names:
```yaml
# CORRECT
- name: Install package
ansible.builtin.apt:
name: nginx
state: present
# WRONG - deprecated short names
- name: Install package
apt:
name: nginx
```
3. **Control command/shell modules** - Add `changed_when` and `failed_when`:
```yaml
- name: Check if service exists
ansible.builtin.command: systemctl status myservice
register: service_check
changed_when: false
failed_when: false
```
4. **Use `set -euo pipefail`** - In all shell scripts and shell module calls:
```yaml
- name: Run pipeline command
ansible.builtin.shell: |
set -euo pipefail
cat file.txt | grep pattern | wc -l
args:
executable: /bin/bash
```
5. **Tag sensitive tasks** - Use `no_log: true` for secrets:
```yaml
- name: Set database password
ansible.builtin.command: set-password {{ db_password }}
no_log: true
```
6. **Idempotency first** - Check before create, verify after.
7. **Descriptive task names** - Start with action verbs (Ensure, Configure, Install, Create).
## Module Selection Guide
### Decision Matrix
| Need | Use | Why |
|------|-----|-----|
| Install packages | `ansible.builtin.apt/yum/dnf` | Native modules handle state |
| Manage files | `ansible.builtin.copy/template/file` | Idempotent by default |
| Edit config lines | `ansible.builtin.lineinfile` | Surgical edits, not full replace |
| Run commands | `ansible.builtin.command` | When no native module exists |
| Need shell features | `ansible.builtin.shell` | Pipes, redirects, globs |
| Manage services | `ansible.builtin.systemd/service` | State management built-in |
| Manage users | `ansible.builtin.user` | Cross-platform, idempotent |
### Prefer Native Modules
Native modules provide:
- Built-in idempotency (no need for `changed_when`)
- Better error handling
- Cross-platform compatibility
- Clear documentation
```yaml
# PREFER native module
- name: Create user
ansible.builtin.user:
name: deploy
groups: docker
state: present
# AVOID command when module exists
- name: Create user
ansible.builtin.command: useradd -G docker deploy
# Requires: changed_when, failed_when, idempotency logic
```
### When Command/Shell is Acceptable
Use `command` or `shell` modules when:
1. No native module exists for the operation
2. Interacting with vendor CLI tools (pvecm, pveceph, kubectl)
3. Running one-off scripts
Add proper controls:
```yaml
- name: Create Proxmox API token
ansible.builtin.command: >
pveum user token add {{ username }}@pam {{ token_name }}
register: token_result
changed_when: "'already exists' not in token_result.stderr"
failed_when:
- token_result.rc != 0
- "'already exists' not in token_result.stderr"
no_log: true
```
## Collections in Use
This repository uses these Ansible collections:
| Collection | Purpose | Example Modules |
|------------|---------|-----------------|
| `ansible.builtin` | Core functionality | copy, template, command, user |
| `ansible.posix` | POSIX systems | authorized_key, synchronize |
| `community.general` | General utilities | interfaces_file, ini_file |
| `community.proxmox` | Proxmox VE | proxmox_vm, proxmox_kvm |
| `infisical.vault` | Secrets management | read_secrets |
| `community.docker` | Docker management | docker_container, docker_image |
### Installing Collections
```bash
# Install from requirements
cd ansible && uv run ansible-galaxy collection install -r requirements.yml
# Install specific collection
uv run ansible-galaxy collection install community.proxmox
```
## Common Execution Patterns
### Running Playbooks
```bash
# Basic execution
uv run ansible-playbook playbooks/my-playbook.yml
# With extra variables
uv run ansible-playbook playbooks/create-vm.yml \
-e "vm_name=docker-01" \
-e "vm_memory=4096"
# Limit to specific hosts
uv run ansible-playbook playbooks/update.yml --limit proxmox
# Check mode (dry run)
uv run ansible-playbook playbooks/deploy.yml --check --diff
# With tags
uv run ansible-playbook playbooks/setup.yml --tags "network,storage"
```
### Linting
```bash
# Run ansible-lint
mise run ansible-lint
# Or directly
uv run ansible-lint ansible/playbooks/
```
## Task Naming Conventions
Use descriptive names with action verbs:
| Verb | Use When |
|------|----------|
| Ensure | Verifying state exists |
| Configure | Modifying settings |
| Install | Adding packages |
| Create | Making new resources |
| Remove | Deleting resources |
| Deploy | Releasing applications |
| Update | Modifying existing resources |
Examples:
```yaml
- name: Ensure Docker is installed
- name: Configure SSH security settings
- name: Create admin user account
- name: Deploy application configuration
```
## Variable Naming
Use snake_case with descriptive names:
```yaml
# GOOD - clear, descriptive
proxmox_api_user: terraform@pam
docker_compose_version: "2.24.0"
vm_memory_mb: 4096
# BAD - vague, abbreviated
pve_usr: terraform@pam
dc_ver: "2.24.0"
mem: 4096
```
## Quick Reference Commands
```bash
# Lint all Ansible files
mise run ansible-lint
# Run playbook with secrets from Infisical
cd ansible && uv run ansible-playbook playbooks/my-playbook.yml
# Check syntax
uv run ansible-playbook --syntax-check playbooks/my-playbook.yml
# List hosts in inventory
uv run ansible-inventory --list
# Test connection
uv run ansible all -m ping
```
## Common Anti-Patterns
### Missing FQCN
```yaml
# BAD
- name: Copy file
copy:
src: file.txt
dest: /tmp/
# GOOD
- name: Copy file
ansible.builtin.copy:
src: file.txt
dest: /tmp/
```
### Uncontrolled Commands
```yaml
# BAD - always shows changed, no error handling
- name: Check status
ansible.builtin.command: systemctl status app
# GOOD
- name: Check status
ansible.builtin.command: systemctl status app
register: status_check
changed_when: false
failed_when: false
```
### Using shell When command Suffices
```yaml
# BAD - shell not needed
- name: List files
ansible.builtin.shell: ls -la /tmp
# GOOD - command is sufficient
- name: List files
ansible.builtin.command: ls -la /tmp
changed_when: false
```
### Missing no_log on Secrets
```yaml
# BAD - password in logs
- name: Set password
ansible.builtin.command: set-password {{ password }}
# GOOD
- name: Set password
ansible.builtin.command: set-password {{ password }}
no_log: true
```
## Related Skills
- **ansible-idempotency** - Detailed changed_when/failed_when patterns
- **ansible-secrets** - Infisical integration and security
- **ansible-proxmox** - Proxmox-specific module selection
- **ansible-error-handling** - Block/rescue, retry patterns
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.