feature-flag-guide
Write a feature flag management guide and lifecycle playbook for a service or team — covering flag taxonomy, creation checklist, rollout strategy, monitoring requirements, cleanup policy, and governance. Use when asked to document feature flag practices, create a flag rollout plan, write a feature flag policy, or guide a team on flag lifecycle management. Produces a flag lifecycle playbook, taxonomy reference, per-flag creation template, rollout decision tree, and cleanup checklist.
npx skills add mohitagw15856/pm-claude-skills --skill feature-flag-guide --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Feature Flag Guide Skill Produce a complete feature flag management guide for a service or team — covering how flags are named and categorised, how to create and roll out a flag safely, what to monitor during rollout, when and how to clean up flags, and who is responsible for each stage. Feature flags without discipline become permanent technical debt. This guide gives the team a repeatable process so flags are created intentionally, rolled out safely, and removed when done. ## Required Inputs Ask for these if not already provided: - **Service or team name** — scope of the guide - **Feature flag platform** — LaunchDarkly, Split, Unleash, Flagsmith, Flipt, or a custom/in-house solution - **Flag being documented** (if writing a per-flag guide) or "general guide" (if writing team-wide policy) - **Rollout constraints** — any compliance, data privacy, or contractual constraints on who can see a feature (e.g. HIPAA, EU-only, enterprise customers only) ## Output Format --- # Feature Flag Management Guide: [Service / Team Name] **Team:** [Team name] | **Platform:** [LaunchDarkly / Split / Unleash / Custom] **Document owner:** [Name] | **Last updated:** [Date] **Review cycle:** Quarterly,
- Required Inputs
- Output Format
- 1. Flag Taxonomy
- 2. Flag Naming Convention
- 3. Flag Creation Checklist
- 4. Rollout Strategy
- Decision Tree
- Rollout Stages
- Segment-Based Targeting
- 5. Monitoring Requirements
- Required Metrics Per Flag
- Guardrail Metrics
- 6. Per-Flag Creation Template
- 7. Emergency Kill-Switch Procedure
ld-cli flag update [project-key] [flag-key] --default-variation off
split-cli update-treatment [flag-name] --treatment "off" --percentage 100
curl -X POST https://[unleash-host]/api/admin/features/[flag-name]/disable \
These flags are "on" by default and turned "off" to disable a feature
Confirm the flag polarity before toggling — "off" may mean "disabled" or "enabled" depending on naming
Flag [flag-name]: OFF = [feature behaviour when off]
Run weekly — flags past cleanup date or at 100% for > 30 days
LaunchDarkly API
curl -s "https://app.launchdarkly.com/api/v2/flags/[project-key]" \
jq '.items[] | select(.creationDate < (now - 2592000) * 1000) | {key: .key, created: .creationDate}'What does the feature-flag-guide skill do?
Write a feature flag management guide and lifecycle playbook for a service or team — covering flag taxonomy, creation checklist, rollout strategy, monitoring requirements, cleanup policy, and governance. Use when asked to document feature flag practices, create a flag rollout plan, write a feature flag policy, or guide a team on flag lifecycle management. Produces a flag lifecycle playbook, taxonomy reference, per-flag creation template, rollout decision tree, and cleanup checklist.
How do I install it?
Run `npx skills add mohitagw15856/pm-claude-skills --skill feature-flag-guide --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From mohitagw15856/pm-claude-skills, a repository with 1,255 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.