Menu
Blameless post-incident analysis focused on timeline, 5 Whys, mechanisms over people, and concrete action items with owners.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | Correction of Errors |
| description | Blameless post-incident analysis focused on timeline, 5 Whys, mechanisms over people, and concrete action items with owners. |
| leadership_principles | ["Ownership","Earn Trust","Dive Deep","Insist on the Highest Standards","Learn and Be Curious"] |
A Correction of Errors (COE) is a blameless post-incident document that analyzes what happened, why it happened, and what mechanisms will prevent recurrence. The goal is not to assign blame—it is to improve the system so the same class of failure cannot happen again. COEs produce mechanisms (automated safeguards), not promises ("we'll be more careful"). Every COE must result in concrete action items with owners and due dates that make the system more resilient.
Load agents/coe-reviewer.md when reviewing a COE. Use it to enforce blameless analysis, timeline accuracy, root-cause depth, mechanism quality, and concrete action items with owners and dates.
Amazon's COE process is one of its most powerful learning mechanisms. The document is written by the team that experienced the incident, reviewed by senior leadership, and shared broadly for organizational learning. The key insight: people don't cause failures—systems allow failures. If a single person's mistake can cause a customer-impacting incident, the system lacks sufficient safeguards. COEs that conclude "the engineer should have been more careful" are rejected. COEs that conclude "we will add an automated check that prevents this class of error" are accepted.
Start with the customer impact and ask "why" until you reach systemic root causes:
Root causes from this example:
Section 1: Summary
Section 2: Customer Impact
Section 3: Timeline
Section 4: Root Cause Analysis (5 Whys)
Section 5: Action Items
Section 6: Lessons Learned
| Intention | Mechanism |
|---|---|
| "We'll be more careful during code review" | Automated static analysis that detects the specific pattern that caused the incident |
| "We'll remember to check that next time" | Automated pre-deploy check that verifies the condition |
| "The on-call will know to look for this" | Alarm that automatically detects this condition and pages |
| "We'll test this scenario" | Integration test added to the pipeline that fails if this scenario recurs |
| "We'll document this for future reference" | Runbook entry with specific steps, linked to the relevant alarm |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "It was a human error" | Humans always make errors. The question is: why did the system allow it to cause customer impact? | Identify the missing safeguard. Add automation that catches this error before it reaches production |
| "It was an edge case we couldn't predict" | If it happened, it can happen again. Every edge case needs a mechanism once discovered | Add the test case, add the alarm, add the guard. "Unpredictable" means "we hadn't thought about it yet" |
| "We were unlucky" | Luck is not an operational strategy. If a system can fail given bad luck, it will | Design for resilience. Assume failure will happen and build safeguards |
| "We need to train people better" | Training fades. People rotate. Knowledge is lost | Build the knowledge into the system: automated checks, guardrails, circuit breakers |
After corrective actions are defined, check whether any action item is an implementation-level corrective action (something that should change how code is written in future builds — not an org/process/people action). If so:
skills/implementation-memory/SKILL.md.docs/implementation-memory.md.If no implementation-level action item exists (all actions are org/process/infra), skip this step silently.
Applying Amazon's raise-the-bar principle to every code review. What reviewers look for — clarity, correctness, design, reuse, operational readiness. "Ship It" means the change raises or maintains the quality bar.
Internal /build flow mechanism that maintains fixed-size procedural memory of durable implementation-quality lessons.
Review a technical design before specs or implementation. Evaluate problem clarity, requirements, alternatives, trade-offs, architecture, dependency behavior, security, operations, cost, testability, and simplicity.
Bridge between an approved Design Document and code. Decompose the system-level blueprint into N vertical specs (requirements → design → tasks), each independently deliverable. Fail fast by ordering hardest-first. Execute wave-by-wave with approval gates.
Stage 4 of Working Backwards: Write the PR/FAQ — a press release announcing the product as if it already exists, plus a comprehensive FAQ addressing hard questions. This is the core Amazon mechanism that forces clarity, customer-centric thinking, and rigorous pre-mortems before any code is written.
Reverse-engineer an existing project to produce a Design Doc, API contracts, and a Threat Model anchored in the real code, IaC, and observability. Run once per project. Output anchors all subsequent /spec and /build invocations.