Menu
Complete lifecycle of feature flags from creation through gradual rollout to cleanup, including kill switches and A/B testing.
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
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.
| name | Feature Flag Lifecycle |
| description | Complete lifecycle of feature flags from creation through gradual rollout to cleanup, including kill switches and A/B testing. |
| leadership_principles | ["Customer Obsession","Bias for Action","Invent and Simplify","Ownership"] |
Feature flags decouple deployment from release. Code ships dark (behind a flag), then is gradually exposed to increasing percentages of traffic. Every flag has a defined lifecycle: creation → gradual rollout → full rollout → cleanup. Flags that live forever become tech debt that obscures code paths and creates combinatorial testing nightmares. Kill switches provide instant off-switches for new features without requiring deployment.
Amazon treats feature flags as first-class operational controls. A feature without a kill switch is a feature you can't turn off at 3 AM when it's causing problems. The gradual rollout pattern (1% → 5% → 25% → 50% → 100%) is not arbitrary—each stage allows you to detect different classes of problems. 1% catches crashes and obvious errors. 5% catches performance issues. 25% catches capacity problems. 50% catches subtle behavioral differences. Flags that outlive their purpose are aggressively cleaned up because stale flags are a source of both confusion and incidents.
feature.payment.new-checkout-flow)Stage 1: Internal (dogfooding) — 0% external
Stage 2: 1% of external traffic
Stage 3: 5% of external traffic
Stage 4: 25% of external traffic
Stage 5: 50% of external traffic
Stage 6: 100% of external traffic
Every feature flag serves as a kill switch:
When using flags for experimentation:
Flags MUST be removed after reaching 100% rollout + stabilization:
Cleanup timeline:
| Intention | Mechanism |
|---|---|
| "I'll clean up the flag after launch" | Automated alerts when flags pass expiration date. Stale flag report in weekly operational review |
| "I'll monitor the rollout carefully" | Automated rollout gates that block progression without green metrics |
| "The kill switch will work if we need it" | Kill switch tested monthly as part of operational drills |
| "I'll define success criteria before launch" | Flag creation template requires metrics and criteria fields—pipeline blocks without them |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "This flag is simple, it doesn't need gradual rollout" | Simple flags gate complex behavior. You don't know what breaks until real traffic hits it | Every customer-facing flag follows the rollout stages. No exceptions. |
| "We'll clean up flags next sprint" | Next sprint never comes. Flags accumulate and interact in unexpected ways | Set expiration at creation. Automated ticket creation on expiry. Block new flags if team has >10 stale flags |
| "We can't remove this flag, someone might need it" | If it's been at 100% for 30+ days and no one has toggled it, no one needs it | Remove it. If you need the capability again, create a new flag with a new lifecycle |
| "Let's leave the flag so we can rollback" | Rollback via flag beyond 30 days means you haven't committed to the feature | Commit or revert. Long-lived flags are not a substitute for deployment rollback |