dawg-io

ansible-create

Builds the Ansible side of a node terraform-create provisioned, driven by a `.claude/ansible-create.yml` in that repo — no hardcoded inventory path or branch name. `/ansible-create init` checks the repo has that shape, records its real paths, conventions and lint commands, and PRs that config. A build run asks first whether this is an existing role on a new host (fast path: one inventory line and a group) or something new (full interview), then writes the minimal playbook and inventory line on a branch off the default branch and opens a draft PR. Verifies with `--syntax-check` and `ansible-lint` only; never runs a playbook against real inventory, not even `--check`. Use on /ansible-create, "ansible create", an ask for a playbook or role for a node, to apply an existing role to a new host, to wire a new VM into Ansible, or a handed-over tfvars entry plus "now the ansible side". Not for debugging a failing run, or a Talos cluster. Needs an Ansible repo (see `example/`), `git` and `gh` — Claude Code only.

ci-pipeline

Watches every CI run a gitops action kicks off — push, PR, merge, tag or dispatch — on the checked-out repo/branch. Load it automatically, without being asked, the moment a push, PR or merge happens in this session, including one you just made; finishing a push is not finishing the task. Monitors all active runs; on a failure it reads that job's real logs, prints what broke, then re-runs once for a real infra blip (OOM, timeout, rate limit), or makes the smallest safe fix with a regression test, pushes, and comments on the PR. For a larger problem it stops and lays out options with tradeoffs, recommending a stacked PR. Never guesses. Never skips, disables or loosens a check, or pushes to trunk. `/ci-pipeline init` records which checks gate a merge and how to run each locally. Also use on /ci-pipeline, /devops, /pr-pipeline-watch, "set up ci-pipeline", any question about CI, a build or a red check, or a bare "did that pass?". Not for feature work or releases (/release). Needs `gh` — Claude Code only.

Code & Development Listed

code-development

Guides a feature, bugfix, or patch through three tasks in strict sequence: (1) scope and design — read the repo, research best practices, surface every open question and design choice, and stop for explicit sign-off on a written plan; (2) implement — feature branch, smallest change, security first, written to pass SonarQube/CodeQL/lint, no commit until local tests actually run and pass; (3) document — update or create README/docs with fresh Playwright screenshots from a local run or mocks, sweeping stale images even on a bugfix. Ends by pushing and opening a fully filled PR (stacked PRs for larger work), then hands CI to ci-pipeline. `/code-development init` records validated test, lint and PR conventions in `.claude/code-development.yml`. Use on /code-development, "develop a feature", "fix a bug", or any ask to build, implement, fix, or patch code — even if coding already started. Not for CI failures (/ci-pipeline), releases (/release), or reviewing others' PRs. Needs git and gh — Claude Code only.

release

Runs a repository's full release process end to end, driven by a `.claude/release.yml` committed to that repo — no hardcoded repo, workflow, or branch names. `/release init` interviews you, writes that config, and opens a PR for it. `/release dry-run` rehearses a release read-only, changing nothing. A full run baselines from the last successful release, reviews every PR merged since, audits docs and screenshots and stops with an [ON HOLD] issue if anything is stale (it reports staleness, never fixes it), opens a labelled review issue for explicit human approval, confirms the ref, deploys the docs site first, dispatches the release workflow with the approved issue's number, tracks it, locates the resulting PR or GitHub Release, announces it, and writes a self-contained HTML record of what shipped. Use on /release, or any ask to cut, ship, publish, or promote a release. Not for feature work (/code-development) or a red pipeline (/ci-pipeline). Needs `gh` or a GitHub MCP server — Claude Code only.

terraform-create

Interviews you for a new Proxmox VM and emits a ready-to-paste `servers` entry for your Terraform tfvars plus the matching Ansible inventory host line, then checks both against the existing tfvars for a duplicate hostname, IP, MAC or VMID. Prefills — VLAN, addressing, sizing, nodes, tfvars and inventory paths — come from a `.claude/terraform-create.yml` that `/terraform-create init` derives from your real tfvars and commits; with no config, one homelab's values are used as labelled fallbacks. Output only: it prints the blocks and the commands to run, never edits your tfvars, inventory or any Terraform/Ansible file, and never runs terraform or ansible. Use on /terraform-create, "terraform create", or any ask to create/add/spin up/provision a node, VM or server on Proxmox, or for a tfvars entry for a new host — even without saying "Terraform". Not for reviewing a plan, changing an existing server, or the homelab/ Talos cluster. Needs the Terraform repo checked out; init needs git and gh, so Claude Code.