feature-flagging

What it does

The skill instructs the agent to treat feature flags as production infrastructure, covering flag types (release, experiment, operational, permission, configuration), naming conventions, lifecycle phases (birth, adolescence, launch, maturity, death), targeting rules across user/account/request/time dimensions, rollout strategies (percentage, cohort, geo-staged, time-based), stale flag management with a quarterly cleanup cadence, and governance/permissions for flag changes. It emphasizes avoiding mixing flag types, and prescribes creating new flags when the flag’s purpose changes.

It prescribes: use of explicit metadata at birth (owner, type, target removal date, rollout plan, monitoring), staged rollout with monitored gates, and a cleanup workflow for removing flags via per-flag PRs after removal in code and platform. It highlights naming as type_owner_semantic_name_version_or_date, and warns against vague names.

The skill outlines lifecycle entry/exit criteria for each flag phase and prescribes quarterly stale-flag reviews, with a mechanical cleanup process including reporting, triage, and one-PR-per-flag removals. It defines governance roles (Viewer, Editor, Approver, Admin) and requires audit trails for flag changes, with promotion through dev → staging → production and explicit abort criteria. It also covers dependencies and conflicts between flags, performance considerations, and caching for evaluation efficiency. The content references external patterns and playbooks for details but the skill itself provides the operational shape for flag management.

How it works

The agent should:

• Enforce five flag types and enforce separate lifecycles for each, with explicit birth metadata and a plan for death/removal.
• Apply naming: <type><owner><semantic_name>_<version_or_date>, and ensure uniform casing and avoidance of vague names.
• Implement a birth process that includes owner, type, target removal date (for release/experiment), rollout plan, and monitoring approach.
• Execute rollout strategies with staged percentage or cohort progression, monitoring at each step per the ramp-and-watch rule.
• Schedule and perform quarterly stale flag management, generating reports, identifying owners, and issuing one PR per code-side removal upon retirement.
• Implement governance: tiered permissions, audit logs, and promotion steps dev → staging → production with required reviews and approvals.
• Detect and avoid inter-flag dependencies and conflicts through documentation, tests, and planning.
• Consider performance: encourage caching, use bulk evaluation when supported, and minimize per-flag evaluation overhead.

When to use it

Use when introducing a flag, modifying a flag, auditing existing flags, or designing a flag governance policy. It applies at the lifecycle level from creation to retirement, and whenever flag naming, targeting rules, rollout, or governance policies are being established or updated.

What it can touch

The skill references platform-agnostic concepts and requires a feature-flag platform (any of LaunchDarkly, Flagsmith, Split.io, VWO FME, GrowthBook, Statsig, PostHog, Optimizely). It prescribes governance and operational workflows but does not specify exact tooling commands beyond general guidance. The provided content discusses the need for PRs for cleanup and for promotion through environments; it does not enumerate concrete tool commands in this section.

Caveats

The skill emphasizes that the platform implementation details are left to the platform’s documentation, and it does not provide experimental design or statistical analysis guidance. It also notes that the five flag types must be kept separate to avoid mess, and that death/retirement requires intentional cleanup planned at birth. Audit trails and staged promotion are required for changes.