feature-flags-architect
by alirezarezvanifeature-flags-architect helps teams plan, audit, and clean up feature flags for progressive delivery. Use it for rollout plans, kill-switch checks, stale flag scans, provider comparisons, and lifecycle guidance across LaunchDarkly, GrowthBook, Statsig, Unleash, Flipt, or DIY systems.
This skill scores 84/100, which means it is a solid listing candidate for directory users who want agents to design, audit, and retire feature flags with less guesswork than a generic prompt. The repository evidence shows substantial workflow content, practical templates, and stdlib Python tools, though installation/discovery polish and the missing visible slash-command artifact create minor adoption cautions.
- Strong triggerability: the frontmatter explicitly names common intents such as adding flags, rollout plans, kill switches, stale flags, provider names, and progressive-delivery questions.
- Operationally useful materials: includes a flag request template, lifecycle guidance, taxonomy, provider comparison, rollout strategies, and Python scripts for debt scanning, rollout planning, and kill-switch auditing.
- Good agent leverage: the skill gives concrete decision rules such as rejecting flags without cleanup criteria, requiring owners and dashboards, using single decision points, and choosing rollout strategies by risk.
- No install command or README is present in the skill path, so directory users may need to rely on the broader repository installation flow.
- The advertised /flag-cleanup slash command is mentioned in the description, but the provided file tree does not show a corresponding command/rules file.
Overview of feature-flags-architect skill
What feature-flags-architect is for
feature-flags-architect is an engineering skill for planning, reviewing, auditing, and cleaning up feature flags as a release lifecycle instead of scattered if statements. It is best suited to teams doing progressive delivery, risky launches, experiments, kill switches, or provider selection across tools such as LaunchDarkly, GrowthBook, Statsig, Unleash, Flipt, or a DIY flag system.
Best-fit users and jobs to be done
Use this skill when you need a concrete rollout plan, a flag request template, stale flag detection, kill-switch documentation, or a provider trade-off discussion. It is especially useful for release engineers, platform teams, staff engineers, and product engineers who need to answer: should this be a flag, what type is it, who owns it, how will it roll out, what metrics abort it, and when will it be removed?
What makes it different from a generic prompt
A normal prompt can suggest “use a feature flag”; feature-flags-architect pushes for a complete lifecycle: request → design → ship → ramp → cleanup → archive. The repository includes practical references for flag taxonomy, lifecycle, provider comparison, and rollout strategies, plus stdlib Python scripts for flag debt scanning, rollout planning, and kill-switch audits.
Key adoption considerations
The skill works best when your repository has recognizable flag calls and a written flag registry such as docs/feature-flags.md. Its scanners look for common patterns like isEnabled(...), useFlag(...), LaunchDarkly-style variation(...), and SDK calls for Unleash, GrowthBook, or Statsig. If your organization uses heavily customized wrappers, expect to adapt the regex patterns before relying on audit results.
How to Use feature-flags-architect skill
feature-flags-architect install and repository path
Install the skill from the GitHub source using your skill manager, for example:
npx skills add alirezarezvani/claude-skills --skill feature-flags-architect
The source lives at:
engineering/skills/feature-flags-architect
After installation, read SKILL.md first, then inspect assets/flag_request_template.md, references/flag_taxonomy.md, references/flag_lifecycle.md, references/rollout_strategies.md, and references/provider_comparison.md. For operational use, review scripts/flag_debt_scanner.py, scripts/kill_switch_audit.py, and scripts/rollout_planner.py.
Inputs the skill needs for useful output
For strong feature-flags-architect usage, provide more than “add a flag.” Include the feature name, risk level, affected path, expected lifetime, owner, current provider, code locations, metrics, rollout target, and cleanup rule.
Weak prompt:
Add a flag for the new checkout.
Stronger prompt:
Use feature-flags-architect for Deployment. We are launching
new-checkout-flowin a TypeScript service using LaunchDarkly. It affects payment confirmation and order creation. Start at 1%, target 100% in 21 days, abort if error rate rises by more than 1 percentage point or p99 latency exceeds baseline by 20%. Owner ispayments-platform. Produce a flag request, rollout plan, kill-switch criteria, tests, and cleanup conditions.
This gives the skill enough context to classify the flag, choose a safer ramp, and define measurable abort rules.
Suggested workflow for a new flag
Start with assets/flag_request_template.md and fill every field before opening a PR. Then ask the skill to classify the flag as Release, Experiment, Operational, or Permission using references/flag_taxonomy.md. Next, generate a rollout plan using the risk-based strategies in references/rollout_strategies.md. Before merge, run or adapt scripts/kill_switch_audit.py so every code flag has an owner, type, kill switch, and dashboard entry.
A high-quality output should include one decision point in code, OFF-by-default behavior in production for release flags, ON/OFF branch tests, a dashboard link, concrete abort thresholds, and a cleanup trigger such as “remove after 100% rollout for 7 days with no incidents.”
Suggested workflow for cleanup and audits
For stale flags, run the flag debt scanner against your repository and tune thresholds:
python scripts/flag_debt_scanner.py --repo /path/to/repo --max-age-days 90 --min-uses 2
Use the result as a review queue, not as an automatic delete list. Ask feature-flags-architect to group findings into safe removals, needs-owner-review, and permanent permission/operational flags. For kill-switch readiness, cross-reference code flags against your registry with kill_switch_audit.py; this is most useful as a pre-merge or release-freeze gate.
feature-flags-architect skill FAQ
Is feature-flags-architect only for LaunchDarkly?
No. The feature-flags-architect skill covers LaunchDarkly, GrowthBook, Statsig, Unleash, Flipt, and DIY approaches. The provider comparison reference helps decide based on flag count, targeting, audit requirements, experimentation needs, self-hosting, and budget. LaunchDarkly fits large enterprise programs; GrowthBook and Unleash are common self-hostable options; Flipt is lighter; DIY is realistic only for simple needs.
When should I not use a feature flag?
Do not add a flag for every change. The skill explicitly challenges low-value flags: cosmetic changes, changes with no rollback value, duplicate flags, or flags without cleanup criteria. If a direct deploy is safer and simpler, use that. Feature flags add operational surface area, testing branches, stale code risk, and ownership requirements.
Can beginners use this skill?
Yes, if they follow the templates. The taxonomy and lifecycle references make it beginner-friendly because they turn vague release questions into checklists. However, beginners should still involve an experienced reviewer for high-risk domains such as payments, authentication, data migrations, authorization, or infrastructure behavior, where the wrong default or targeting rule can create production incidents.
How is this better than asking for a rollout plan?
A plain rollout prompt usually gives generic percentages. feature-flags-architect ties the rollout to risk, monitoring, kill-switch triggers, ownership, cleanup, and provider constraints. It also includes scripts that can inspect real code, which makes it more useful for Deployment workflows where you need evidence from the repository rather than a standalone recommendation.
How to Improve feature-flags-architect skill
Improve feature-flags-architect results with better context
The most important input is operational specificity. Provide baseline metrics, target cohorts, provider name, SDK/wrapper details, environment defaults, release deadline, blast-radius concerns, and what “bad” looks like. Instead of asking for “a safe rollout,” say “authentication path, 2M daily users, abort on login failure +0.5pp, p99 latency x1.15, start with internal users, hold each ring 48 hours.”
Adapt the scripts to your codebase
The included Python scripts use common regex patterns and standard code extensions. Improve accuracy by adding your internal wrapper names, config file locations, registry format, and directories to skip. If your flags are declared in YAML, Terraform, database migrations, or generated clients, extend discovery beyond application code. Treat script output as a signal for review, not a perfect source of truth.
Watch for common failure modes
The biggest failures are vague owners, permanent “temporary” release flags, scattered conditional checks, missing OFF-branch tests, undocumented kill switches, and cleanup dates that never trigger action. Ask the skill to flag these explicitly in code review output. A good review should say which flags should be rejected, which need a stronger runbook, and which should become permission or operational flags instead of release flags.
Iterate after the first output
After the first answer, ask feature-flags-architect to tighten it against your constraints: “reduce rollout duration to 10 days,” “make this work for Unleash,” “convert this into a PR checklist,” “write the docs/feature-flags.md entry,” or “turn scanner findings into cleanup tickets.” The best results come from using the skill as a release-engineering reviewer, not just a one-time generator.