Menu

Individual skill

feature-flags

0upvotes

Designs feature-flag systems and lifecycle policy - flag taxonomy (release, ops/kill-switch, experiment, permission), percentage rollouts with stable bucketing, safe defaults, and mandatory removal deadlines so flags don't rot into dead code. Use when someone asks "how should I roll this out behind a flag", "kill switch vs feature flag", "how do I do a percentage rollout", "we have hundreds of stale flags", or is wiring up LaunchDarkly or a homegrown flag service. Do NOT use for designing the A/B test analysis itself - use ab-test-analyzer instead - and do NOT use for CI/CD pipeline gating - use github-actions instead.

skills/feature-flags/SKILL.md

Read pinned source

Source commit 97a13607d669157a4a16d5ba79b77f208319f7b9

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
Yes
Observed behavior
Not checked yet
Last checked
Nov 6, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
24
Repository last updated
Oct 13, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Feature Flags

Flags decouple deploy from release: code ships dark and turns on safely, in stages, with an instant off switch. The costly mistake this skill prevents is flag debt - every flag is a fork in your codebase that doubles the test matrix, and a flag without an owner and a removal deadline set at creation becomes permanent dead code that someone flips three years later during an incident with no idea what it does.

## Operating procedure

### Step 1: Gather inputs

Before creating any flag, collect:

1. Purpose - which of the four types below it is. If the answer is "two of them", that is two flags.
2. Blast radius if the new path misbehaves (cosmetic / degraded / data-corrupting / revenue-affecting).
3. Bucketing key - usually user id; sometimes account id so a whole team sees one variant.
4. Owner (a person, not a team) and the removal condition.