From build-like-amazon
Guides gradual feature flag rollout from creation to cleanup with kill switches and A/B testing. Useful for safely launching features and managing risk.
How this skill is triggered — by the user, by Claude, or both
Slash command
/build-like-amazon:feature-flag-lifecycleThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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 ...
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 |
npx claudepluginhub robisson/build-like-amazon-agent-skillsGuides feature flag design, gradual rollouts, A/B testing, kill switches. Recommends LaunchDarkly, Unleash, Flagsmith based on flag count and needs for safer deployments.
Operational discipline for feature flags as production infrastructure: flag types, naming, targeting, rollout strategy, lifecycle, governance, stale flag management, and technical debt patterns.
Manages feature flag lifecycle: detect flags in codebases, classify categories, and design rollout strategies with naming conventions. For auditing stale flags or planning new flag architecture.