← ClaudeAtlas

ops-automationlisted

Production scripting and ops automation — shell scripts, config-management playbooks and roles, scheduled jobs, monitoring checks. Use when writing or reviewing automation that runs unattended, repeatedly, or against a fleet, when a change touches high-impact system surfaces, and when planning patching or provisioning runs.
voklab/layline · ★ 0 · AI & Automation · score 72
Install: claude install-skill voklab/layline
# Ops automation Automation acts on live systems with no reviewer between the run and the damage. Every rule here exists because the second run, the wrong host, or the failed activation is where operational code actually breaks. Layline doctrine owns the baseline; this skill owns what running against production adds. - **Converge, don't act.** Every step declares a target state and is safe to run twice — interrupted runs get re-run from the top; change reporting is honest (changed only when something changed). Verified by running twice, not by inspection; where no target is reachable to run against, report the check `not_run` and name the exact two-run command the operator must execute. Read `references/idempotent-runs.md` when any step will run more than once — which is all of them. - **Gate the destructive step.** Service-affecting or irreversible operations run only behind an approval flag that defaults closed, against a scoped target, never the whole inventory. Read `references/destructive-gates.md` before any such step, and for the high-impact surfaces that demand the full treatment. - **Canary before fleet.** Dry-run with a diff → one representative host → bounded batches; each stage licenses only the next stage, never "done". Read `references/staged-rollout.md` when planning any fleet-touching run. - **Validate before activate, name the rollback first.** A config is checked by its native validator before a service loads it; the restore path is