Menu
CI/CD pipeline safety with automated gates, deployment blockers, alarm checks, and one-click rollback.
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 | Pipeline Safety |
| description | CI/CD pipeline safety with automated gates, deployment blockers, alarm checks, and one-click rollback. |
| leadership_principles | ["Customer Obsession","Insist on the Highest Standards","Ownership","Dive Deep"] |
A safe pipeline is one that makes it harder to deploy bad code than good code. It enforces automated quality gates at every stage, blocks deployments when alarms are firing, provides one-click rollback, and creates an audit trail of every production change. The pipeline is not a convenience tool—it is a safety system that protects customers.
Amazon's deployment philosophy: the pipeline should be the safest, fastest path to production. If developers feel tempted to bypass the pipeline, the pipeline is broken—either too slow or too fragile. A good pipeline deploys hundreds of times per day across a large organization while catching the handful of changes that would have caused customer impact. The investment in pipeline safety is what enables high deployment velocity.
Every deployment must support instant rollback:
The pipeline MUST block deployment when:
Override requires: documented justification + senior engineer approval + post-deploy review within 24 hours.
| Intention | Mechanism |
|---|---|
| "I'll check alarms before deploying" | Pipeline automatically blocks on active alarms |
| "I'll rollback quickly if something goes wrong" | Automatic rollback on alarm, not human decision |
| "I'll make sure tests pass" | Pipeline blocks merge on any test failure |
| "I won't deploy during incidents" | Pipeline queries incident system and blocks |
| "I'll deploy during business hours" | Deployment windows enforced by pipeline |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "The pipeline is too slow" | A pipeline that catches bugs before production saves more time than it costs | Optimize the pipeline (parallel tests, caching) rather than removing gates |
| "This fix is urgent, I need to skip gates" | Urgent fixes are exactly when you make mistakes under pressure | Use the emergency pipeline—fewer gates but never zero |
| "Tests are flaky, we have to ignore them" | Flaky tests mask real failures. Fix them. | Mark flaky tests with expiration dates; fix or delete within 2 weeks |
| "The alarm is a false positive" | You don't know that until you investigate | Fix the alarm signal, don't deploy over it |
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.
Blameless post-incident analysis focused on timeline, 5 Whys, mechanisms over people, and concrete action items with owners.
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.
