Sign inGet started
Skills / Productivity-habits

The Checklist Manifesto

Good checklists are precise. They are efficient, to the point, and easy to use even in difficult situations. They do not try to spell out everything — a checklist cannot fly a plane. Instead, they provide reminders of only the most critical and important steps.

Atul Gawande's methodology transforms complex, high-stakes workflows into precise, deployable checklists that eliminate ineptitude errors — the steps experts skip under pressure, distraction, or overconfidence. This is not a generic list-making tool; it's a design science for encoding tacit knowledge into a repeatable system that enforces the critical steps even when attention fails. Built for teams and operators in medicine, aviation, engineering, and operations who need reliability, not reminders.

By Atul Gawande · Free
Specimen 01 · Live diagnosisThe Checklist Manifesto
Input

“We do production deployments about twice a week. We've had three incidents this year where engineers skipped the database migration validation step.…”

Diagnosis
Let's build a checklist that actually works — not a comprehensive list, but a precise one that catches the steps your team knows and still skips.
Full transcript ↓
Calibrated referenceagent-skills.ai
The gap

Design checklists that catch the errors expertise alone will never prevent

Gawande's framework begins with a critical distinction: most high-stakes failures are not ignorance errors (we didn't know what to do) but ineptitude errors (we knew and still skipped the step). Checklists target ineptitude specifically. The design process requires identifying the exact 'pause point' — the moment in a workflow when the checklist must fire — and choosing between two checklist styles: DO-CONFIRM (team acts from memory, then verifies against the list) and READ-DO (each item is read aloud and completed in sequence). The heart of the methodology is 'killer item' extraction: ruthlessly limiting the checklist to 5–9 steps that are simultaneously critical to success and prone to being skipped. Format rules are non-negotiable — one page, simple sentence fragments, completable in 60–90 seconds. Finally, checklists must embed explicit communication triggers to surface information siloing between team members, and must be tested and refined in real operational conditions, not simulations.

The problem

Experts fail not because they lack knowledge but because they skip steps under pressure — what Gawande calls ineptitude errors. A surgeon who has performed 1,000 procedures still forgets to confirm antibiotic dosing. A DevOps engineer who knows the deployment script still skips the rollback test on a Friday night. Generic checklists make this worse: they become too long to use, get ignored, and provide false assurance that the process is covered. The methodology exists because expertise is not enough.

The solution

You will leave with a checklist you can actually deploy — short enough to use under pressure, precise enough to catch the step that keeps getting skipped, and designed to trigger the right communication between your team at the exact moment it matters.

You bring
  • A specific workflow, process, or procedure where errors keep occurring
  • Knowledge of what steps are critical (even if you're unsure which get skipped)
  • Context about your team size, operational environment, and time constraints
  • An existing checklist or SOP to critique (optional — but accelerates refinement)
You get
  • A deployable checklist of 5–9 killer items with the correct style (DO-CONFIRM or READ-DO) for your context
  • A defined pause point — the precise moment in your workflow when the checklist must activate
  • Embedded communication checkpoints that force explicit information exchange between team members
  • A real-world testing protocol to validate the checklist before full deployment
In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01The same situation, two ways
Specimens A · B
Specimen AVague
Unaided

“Your DevOps team has a 23-step deployment runbook that everyone has read and knows. This quarter, three production incidents were caused by steps engineers skipped under time pressure — steps they could recite from memory. The runbook is comprehensive and ignored.”

×Vague — nothing concrete to act on.
Specimen BCalibrated
With The Checklist Manifesto

“A 4-item DO-CONFIRM checklist fires at the moment before the deploy script runs. Database migration validation, feature flag state, reviewer acknowledgment, and rollback plan confirmation — completed in 55 seconds. The runbook stays in the wiki. The incidents caused by known-but-skipped steps stop.”

Specific, grounded, and ends with one clear next step.
Fig.02A real session, unedited
In-app · assistant
The Checklist ManifestoClaude
The Checklist Manifesto
Let's build a checklist that actually works — not a comprehensive list, but a precise one that catches the steps your team knows and still skips. Before we write anything, I need to understand the workflow and where errors are happening. What's the process you're trying to protect, and what's gone wrong in it?
We do production deployments about twice a week. We've had three incidents this year where engineers skipped the database migration validation step. They know it's required — it's in the runbook — but under pressure they skip straight to the deploy.
That's a classic ineptitude error — not ignorance, but a step that gets dropped under time pressure despite being known. The runbook isn't working because it's comprehensive, not surgical. Let me ask a few things to find your pause point and killer items.
First: in your deployment sequence, what's the last reversible moment — the point after which a mistake requires rollback or causes an outage? And second, is this typically a solo operation or does your team deploy together?
The last reversible point is just before we run the deploy script. After that, if the migration is wrong, we're rolling back and that takes 45 minutes. It's usually one engineer on-call with one reviewer in a chat window.
Perfect. Your pause point is clear: the checklist fires immediately before executing the deploy script — not at the start of the deployment process, not when the PR merges. Right there, at that moment.
Now let's identify your killer items. I'll ask you this the way Gawande frames it: what are the steps that, if skipped, have actually caused or could cause an incident — and that your team skips specifically because they're relying on memory or feel time pressure? Don't try to be comprehensive. What's the migration validation check, and what else belongs in that category?
Migration validation for sure. Also confirming the feature flag is in the right state — we've deployed with the flag still on and it caused unexpected behavior. And the reviewer has to explicitly confirm they've seen the diff, not just be in the Slack channel. Those are probably the real ones.
Three killer items identified. Here's what I'm drafting, formatted DO-CONFIRM style — your engineers know these steps, they just need the explicit confirmation moment before the deploy runs:
---Pre-Deploy Checklist (DO-CONFIRM — complete before running deploy script)
☐ DB migration validated against staging data☐ Feature flags confirmed in correct state for this environment☐ Reviewer has acknowledged diff — not just present in channel
Complete in ≤60 seconds. Do not proceed until all three confirmed.---
Three items. One page. Under a minute. The reviewer acknowledgment item is also a communication trigger — it forces an explicit, on-the-record confirmation rather than assumed presence. Does this capture the actual failure modes, or are there steps I've missed that belong in this tier?
That's almost exactly right. I'd add one more — rollback plan confirmed before deploying to prod, not just having one written somewhere. That's caught us twice.
Reply to The Checklist Manifesto
What the skill is doing
01Pause Point Identification
02Killer Item Extraction
03DO-CONFIRM vs READ-DO Style Selection
Fig.03The same skill, in the channel you already use
WhatsApp · live
9:41
TCThe Checklist Manifestotyping…
Messages are end-to-end encrypted. No one outside of this chat can read them.
Today
We do production deployments about twice a week. We've had three incidents this year where engineers skipped the database migration validation step. T…9:14✓✓
Let's build a checklist that actually works — not a comprehensive list, but a precise one that catches the steps your team knows a…9:14
Before we write anything, I need to understand the workflow and where errors are happening.9:15
What's the process you're trying to protect, and what's gone wrong in it?9:15
Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

Reads the situation, names the pattern, returns one concrete next move.
Delivered in seconds, inside a conversation that already exists.
Specimen · WhatsApp Business API · live
Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Pause Point Identification

Most checklist efforts fail because the checklist fires at the wrong moment — too early to be actionable, too late to prevent errors. This capability maps your workflow to identify the single most effective activation point: the moment just before irreversible action, when all pre-conditions can still be verified.

Based on Gawande's framework for selecting the 'pause point' — the specific workflow moment when checklist activation maximizes both coverage of critical steps and team compliance, as demonstrated by the WHO Surgical Checklist's placement immediately before skin incision.
CapabilityC-02

Killer Item Extraction

The most common checklist design failure is comprehensiveness — trying to capture every step rather than the 5–9 that are both critical to success and most likely to be skipped. This capability guides a structured elicitation to distinguish between 'nice to confirm' and 'cannot proceed without' items, producing a list that will actually be used.

Based on Gawande's 'stupid but critical' principle: killer items must pass two tests — (1) critical enough that omission causes failure or harm, and (2) skip-prone enough under real conditions that memory alone is insufficient.
CapabilityC-03

DO-CONFIRM vs READ-DO Style Selection

Choosing the wrong checklist style creates friction that kills adoption. DO-CONFIRM works for expert teams who need a verification step after performing tasks from memory. READ-DO works for sequential procedures where step order is fixed and team members are executing, not verifying. Matching style to context is the difference between a checklist that integrates into a workflow and one that stops it.

Based on Gawande's two-style typology drawn from aviation practice: cockpit crews use DO-CONFIRM for pre-flight checks (performed from memory, then confirmed against the list) and READ-DO for emergency procedures where exact sequence is non-negotiable.
CapabilityC-04

Gawande-Format Checklist Drafting

Produces a finished checklist formatted to Gawande's design specifications: 5–9 items maximum, sentence-fragment language, single page, completable in 60–90 seconds. Each item is written for precision under pressure — not what you would write in a comfortable office, but what a team member can read, confirm, and move past in seconds.

Based on Gawande's empirically-derived format rules, rooted in cognitive load research: 5–9 items correspond to working memory limits, and the 60–90 second completion target reflects real-world compliance thresholds observed across the WHO hospital trials.
CapabilityC-05

Communication Trigger Design

The most powerful checklist items are not action verifications but communication mandates — moments where team members must exchange information explicitly rather than assuming shared understanding. This capability identifies information silos in your workflow and embeds checklist items that force named confirmation between specific roles.

Based on Gawande's finding that the WHO Surgical Checklist's most impactful item was 'everyone introduce themselves by name and role' — not because introductions prevent errors directly, but because they create the social infrastructure for team members to speak up when something goes wrong.
Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces
OutputD-01

Gawande-Format Checklist

A completed, deployment-ready checklist of 5–9 killer items in the correct style (DO-CONFIRM or READ-DO), formatted to fit one page and completable in under 90 seconds. Each item written in precise sentence-fragment language for use under real operational conditions.

OutputD-02

Pause Point Map

A structured summary of your workflow with the identified activation point marked — showing exactly where in the sequence the checklist fires, which steps precede it, and which follow. Includes rationale for why this moment was selected over alternatives.

OutputD-03

Killer Items Analysis

A documented elicitation record showing each candidate checklist item, why it qualified as a killer item (critical + skip-prone), and why items were excluded (critical but reliably performed, or skip-prone but low-consequence). The analysis justifies every inclusion and exclusion decision.

OutputD-04

Real-World Testing Protocol

A validation plan for running the checklist in actual operational conditions before full deployment — specifying what to observe, what constitutes a successful trial, and how to revise based on real-use friction. Distinguishes between simulation testing (insufficient) and operational validation (required).

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Atul Gawande

Atul Gawande is a practicing surgeon at Brigham and Women's Hospital, staff writer for The New Yorker, and professor at Harvard Medical School and the Harvard T.H. Chan School of Public Health. He led the WHO Safe Surgery Saves Lives initiative, producing the Surgical Safety Checklist tested across 8 international hospitals — it reduced major surgical complications by 36% and deaths by 47% in a landmark study published in the New England Journal of Medicine.

Status · Inspired by Atul Gawande’s work — not yet claimed. Are you Atul Gawande?
Primary sourceS-01

The Checklist Manifesto: How to Get Things Right

by Atul Gawande

Surgeon, Harvard Medical School professor, New Yorker staff writer, WHO Safe Surgery Saves Lives initiative lead, New York Times bestselling author.

Read the original ↗
Citationatulgawande.com
In the build queue

Be first to run it.

The Checklist Manifesto is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail
At launchI have a process that keeps breaking not because people don't know what to do, but because they skip steps under pressure. Can we build a Gawande-style checklist for it — starting with the pause point and killer items?