core-setup-checklist-design

name

core-setup-checklist-design

description

Use when turning a settled goal, plan, procedure, runbook, migration, launch, investigation, or recurring operation into an atomic, dependency-ordered, evidence-backed checklist. Apply failure-aware checklist design when success depends on identifying how each required outcome can fail, selecting a proportionate response, and defining pass, failure, retry, recovery, escalation, or accepted-risk routes.

Reliability-Centered Checklists

A checklist is a control loop, not a list of hopes. For each required outcome, name what must remain true in its real operating context; examine how it could fail; choose the smallest response that makes its consequence tolerable; and prove the response's result. This adapts the reasoning of reliability-centered maintenance (RCM) to knowledge work and software delivery.

Use this when a normal task list would hide meaningful failure paths. For ordinary, low-risk work, use a short task list instead. Do not call a task preventive merely because it happens before a problem: it must address a named failure mode and have evidence that it did.

Build the checklist

1. Define the function and operating context

Write the goal as one or more observable functions: what must be true, for whom, under which conditions, and by when. State constraints and the boundary of the checklist.

Complete when every function has a measurable success condition and no critical term is ambiguous.

2. Find failure modes before prescribing work

For each function, ask in order:

1. How could this function fail, partially fail, be late, or produce an unsafe result?
2. What credible causes or triggering events could lead to that failure?
3. What would a user, operator, test, monitor, or reviewer observe?
4. What is the consequence if it remains unresolved?

Rank consequences by their real impact: safety or security, irreversible data or financial harm, service or delivery failure, quality or cost, then negligible impact. Record uncertainty instead of inventing precision. Focus effort on credible, consequential failures; a low-impact failure may be accepted deliberately.

Complete when each non-trivial function has explicit failure modes, observations, and a consequence level, and every accepted risk says why it is tolerable.

3. Select a response that fits the failure

Choose one response for every failure mode. Prefer the least costly response that reduces the consequence enough:

Response	Use it when	Checklist branch
Prevent	A known action can remove or materially reduce the cause.	Do the action; verify the changed condition.
Detect	Prevention is weak or impractical, but early discovery changes the outcome.	Check a signal at a defined point; set the threshold and owner.
Recover	The failure can occur and recovery limits harm.	Prepare and test rollback, repair, or containment steps.
Change the system	The risk is intolerable and no routine action is adequate.	Stop and redesign scope, tooling, process, or ownership.
Accept / run to failure	The consequence is tolerable and proactive work costs more than the harm.	State the trigger, owner, and recovery action.

Do not create busywork for random or unobservable events. Escalate instead when the risk is high and the proposed task cannot plausibly prevent, detect, or recover from it.

Complete when every material failure mode has one justified response, with no unowned "monitor" or unsupported claim that a task will reduce risk.

4. Write atomic control-loop items

Each item does one observable piece of work and has this shape:

- [ ] **[ID] Action** — [imperative action on one target].
  - Depends on: [completed IDs, decision, or `none`]
  - Failure addressed: [failure mode ID] | Response: [prevent / detect / recover / change / accept]
  - Verify: [command, observation, metric, or named reviewer]
  - Pass evidence: [artifact or result that meets the stated criterion]
  - On fail: [bounded retry, diagnose, recover, or escalate to named owner]
  - Exit: [done / accepted risk / blocked / escalated]

Keep discovery, decision, execution, and verification separate when they can fail independently. Use one owner for action and one named escalation destination; they can be the same person. A checkmark means the verifier observed pass evidence, not merely that somebody attempted the action. If no independent evidence can exist, write a question, assumption, or decision item first.

Complete when every item has one action, explicit prerequisites, a verifier, a pass criterion, and a failure path.

5. Sequence by dependency and feedback

Place prerequisites before dependents. Put cheap, high-consequence uncertainty early so the plan fails fast. Follow any state-changing action with its verification before allowing dependent work. Add checkpoints after a meaningful group of actions: evaluate the evidence, decide whether the risk is now tolerable, and either proceed, recover, revise the plan, or escalate.

Parallelize only items with no shared prerequisite, mutable resource, or unresolved decision.

Complete when the checklist has a valid dependency order, every branch leads to a defined exit, and a person can tell what is ready to start from the completed evidence alone.

Check before use

Read the finished checklist from the perspective of the next operator:

• Can they state the goal and success condition without context outside the checklist?
• Does each high-impact failure have a proportional response and an owner?
• Does every action say what proves success and what happens if it fails?
• Are dependencies and decision points explicit rather than implied by list order?
• Are retries bounded, recoveries safe, and escalations actionable?
• Are accepted risks intentional, documented, and reversible where possible?

If any answer is no, repair the affected item rather than adding a vague final review step.

Output format

Start with Goal, Operating context, and Stop conditions. Then list the failure modes and the checklist in dependency order. Finish with an Accepted risks and escalations section. Keep the checklist as short as the evidence permits.

Source and adaptation boundary

This skill adapts the article's function → failure mode → consequence → task-or-change sequence, including its use of preventive, detective, run-to-failure, and system-change responses. It does not claim to perform formal RCM, FMECA, or satisfy SAE JA1011. Read references/wikipedia-reliability-centered-maintenance.wikitext when checking the source language or extending this skill from the article.