Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From build-like-amazon
Enforces automated quality gates at every CI/CD stage: pre-commit, pre-merge, pre-deploy, and during-deploy. Blocks deployments on active alarms, provides one-click rollback, and creates an audit trail.
npx claudepluginhub robisson/build-like-amazon-agent-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/build-like-amazon:pipeline-safetyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
Reviews AWS CI/CD release safety across CodePipeline, CodeBuild, CodeDeploy, GitHub Actions, and GitLab. Audits deployment gates, artifact provenance, rollback, change correlation, and incident prevention for production reliability.
Analyzes CI/CD pipeline configuration and deployment topology. Evaluates strategy (blue-green, canary, rolling) and checks environment isolation.
Defines CI/CD pipeline stages for build, parallel testing, staging/production deployment with verification, monitoring, rollbacks, and zero-downtime strategies to ensure safe continuous delivery.
Share bugs, ideas, or general feedback.
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 |