Menu
Requires a feature flag for any user-facing change, giving teams an instant kill switch without a deployment.
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
Detects files that always change together, exposing hidden coupling that inflates Lead Time for Change and makes every PR bigger than it needs to be.
Generates a deployment-specific checklist before any code ships, covering rollout, monitoring, communication, and rollback. Directly reduces Change Failure Rate and Mean Time to Restore.
Identifies flaky tests in the affected test suite before shipping, because flaky tests kill Deployment Frequency by making CI untrustworthy.
Blocks shipping code where test coverage for changed files drops below threshold, and flags untested paths that directly raise Change Failure Rate.
Detects breaking changes to public APIs, interfaces, and exported symbols, and blocks shipping without a migration path.
Audits any new dependency before it enters the codebase, covering license, maintenance health, CVEs, and bundle impact.
| name | feature-flag-gate |
| description | Requires a feature flag for any user-facing change, giving teams an instant kill switch without a deployment. |
| when_to_use | Apply automatically when a change touches user-facing behavior, a new endpoint, a changed UI path, or any code that affects what a user sees or experiences. |
The fastest rollback is not a git revert. It is a flag toggle. A revert requires a new build, a new deployment, and pipeline time. A flag toggle takes seconds. This skill ensures that user-facing changes ship with that option available.
This directly protects two DORA metrics: Change Failure Rate (you can turn it off before it spreads) and Mean Time to Restore (seconds to dark, not minutes to redeploy).
A feature flag is required when the change:
A feature flag is NOT required for:
## Feature Flag Gate
**User-facing change detected:** [yes / no]
**Flag required:** [yes / no — reason if no]
### Flag Specification
Flag name: [service.feature.description — snake_case, namespaced]
Default value: [true / false — and why]
Rollout type: [boolean / percentage / user-segment]
Kill switch: [what turning this to false does, in one sentence]
### Rollout Plan
Phase 1: [internal / dogfood — % of traffic or user list]
Phase 2: [gradual rollout — % and criteria to advance]
Phase 3: [full rollout — criteria to remove the flag entirely]
### Flag Cleanup
Estimated removal date: [sprint or date]
Owner responsible for cleanup: [team or role]
If a user-facing change ships without a feature flag and something goes wrong in production, the options are:
A flag makes option 4 available: turn it off in 30 seconds while the team investigates.
Feature flags that are never cleaned up become permanent complexity. Every flag is an if-branch that every future engineer has to reason about. The gate includes a cleanup date for this reason. An uncleaned flag more than two sprints past its estimated removal date is tech debt.
Flag debt is real. This skill tracks the creation. Your team is responsible for the cleanup.