operational-safetylisted

Progressive-disclosure operational-safety-depth modules for the work-loop. Holds failure-mode-keyed checklists the quality-engineer reviewer reasons from (state-and-idempotency, blast-radius, environment-isolation, cost-and-teardown, drift-and-rollback, observability-and-smoke), plus cloud-implementation-craft, the module also inlined into the implementer's EXECUTE brief. Each is grounded in standing operational taxonomy (AWS Well-Architected, Google SRE, the Terraform/Pulumi Day-1/Day-2 split). The orchestrator loads only the matching modules and inlines them into the reviewer's REVIEW brief when infra/destructive work or a persistent-representation / mixed-version deployment change is detected — and cloud-implementation-craft into the implementer's EXECUTE brief on infra-flavored work; the subagent never self-discovers this skill. Not a reviewer prompt itself — it is the depth library the reviewer and implementer reason from. Carves against security-checklists on the reliability-vs-security lens.
eugenelim/agent-ready-repo · ★ 20 · AI & Automation · score 78

Install: claude install-skill eugenelim/agent-ready-repo

# Skill: operational-safety This skill is the **depth library** behind the `quality-engineer` agent for infrastructure and destructive operational work, and independently for changes to persistent representations or mixed-version deployments. The reviewer's body carries the *universal method* (its testability / observability / reliability / maintainability lens, the severity rubric, the report format). The *shape-specific depth* — what to actually check at each operational failure mode — lives here, in the per-failure-mode `references/<module>.md` modules (reviewer checklists plus `cloud-implementation-craft`, the EXECUTE-craft module — see below), so the agent prompt stays lean and the depth scales without bloat. It is the operational-lens twin of [`security-checklists`](../security-checklists/SKILL.md), built on the same orchestrator-loaded, table-routed mechanism — **no new reviewer** (the CHARTER three-reviewer ceiling), no executable code. ## Output rendering  Lead with the useful outcome or next action. Use warm, non-blaming language and everyday words. Define an unfamiliar term in a few plain words before naming it; keep proper names and exact technical terms intact. During tool work, do not narrate routine calls. Send an update only for safety, a blocker, a needed decision, a material scope change, a long wait, or an active host requirement. When requesting input, ask only for what is needed now. Ask dependent questions on