feature-flags-architect

feature-flags-architect skill の概要

feature-flags-architect の用途

feature-flags-architect は、feature flag を散在する if 文ではなく、リリースライフサイクルとして計画・レビュー・監査・整理するためのエンジニアリング skill です。Progressive delivery、リスクの高いローンチ、実験、kill switch、または LaunchDarkly、GrowthBook、Statsig、Unleash、Flipt、DIY の flag システムなどをまたいだ provider 選定に取り組むチームに特に向いています。

向いているユーザーと解決できる仕事

具体的な rollout plan、flag request template、stale flag の検出、kill-switch ドキュメント、provider のトレードオフ整理が必要なときに使います。特に、release engineer、platform team、staff engineer、product engineer が「これは flag にすべきか」「どの種類の flag か」「誰が owner か」「どう段階的に展開するか」「どの metrics で中止するか」「いつ削除するか」に答える場面で役立ちます。

一般的なプロンプトとの違い

通常のプロンプトでも「feature flag を使う」と提案することはできます。一方、feature-flags-architect は request → design → ship → ramp → cleanup → archive までの完全なライフサイクルを前提に考えます。この repository には、flag taxonomy、lifecycle、provider comparison、rollout strategies に関する実践的な reference に加え、flag debt scanning、rollout planning、kill-switch audit のための stdlib Python scripts が含まれています。

導入時に確認すべきポイント

この skill は、repository 内に認識しやすい flag 呼び出しがあり、docs/feature-flags.md のような flag registry が書かれている場合に最も効果を発揮します。scanner は isEnabled(...)、useFlag(...)、LaunchDarkly 風の variation(...)、Unleash、GrowthBook、Statsig の SDK call など、一般的な pattern を探します。組織で大きくカスタマイズされた wrapper を使っている場合は、audit 結果を信頼する前に regex pattern を調整する前提で考えてください。

feature-flags-architect skill の使い方

feature-flags-architect の install と repository path

たとえば次のように、skill manager を使って GitHub source から skill を install します。

npx skills add alirezarezvani/claude-skills --skill feature-flags-architect

source は次の場所にあります。

engineering/skills/feature-flags-architect

install 後は、まず SKILL.md を読み、その後 assets/flag_request_template.md、references/flag_taxonomy.md、references/flag_lifecycle.md、references/rollout_strategies.md、references/provider_comparison.md を確認します。運用で使う場合は、scripts/flag_debt_scanner.py、scripts/kill_switch_audit.py、scripts/rollout_planner.py も確認してください。

有用な出力に必要な入力情報

feature-flags-architect を効果的に使うには、「flag を追加して」だけでなく、feature 名、risk level、影響を受ける path、想定 lifetime、owner、現在の provider、code locations、metrics、rollout target、cleanup rule まで含めます。

弱いプロンプト:

Add a flag for the new checkout.

より強いプロンプト:

Use feature-flags-architect for Deployment. We are launching new-checkout-flow in 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 is payments-platform. Produce a flag request, rollout plan, kill-switch criteria, tests, and cleanup conditions.

この程度の context があると、skill は flag を分類し、より安全な ramp を選び、測定可能な abort rule を定義できます。

新しい flag を作るときの推奨 workflow

まず assets/flag_request_template.md から始め、PR を開く前にすべての項目を埋めます。次に、references/flag_taxonomy.md を使って、その flag が Release、Experiment、Operational、Permission のどれに当たるかを skill に分類させます。そのうえで、references/rollout_strategies.md の risk-based strategy を使って rollout plan を生成します。merge 前には scripts/kill_switch_audit.py を実行または調整し、すべての code flag に owner、type、kill switch、dashboard entry があることを確認します。

質の高い出力には、code 上の decision point が 1 つであること、release flag が production で OFF-by-default であること、ON/OFF branch tests、dashboard link、具体的な abort threshold、そして「100% rollout 後 7 日間 incident がなければ削除」のような cleanup trigger が含まれているべきです。

cleanup と audit の推奨 workflow

stale flag については、flag debt scanner を repository に対して実行し、threshold を調整します。

python scripts/flag_debt_scanner.py --repo /path/to/repo --max-age-days 90 --min-uses 2

結果は自動削除リストではなく、review queue として扱います。feature-flags-architect に、検出結果を safe removals、needs-owner-review、permanent permission/operational flags に分類させてください。kill-switch readiness については、kill_switch_audit.py を使って code flag と registry を照合します。これは pre-merge や release-freeze gate として使うと特に有効です。

feature-flags-architect skill FAQ

feature-flags-architect は LaunchDarkly 専用ですか？

いいえ。feature-flags-architect skill は LaunchDarkly、GrowthBook、Statsig、Unleash、Flipt、DIY approach を扱えます。provider comparison reference は、flag count、targeting、audit requirements、experimentation needs、self-hosting、budget をもとに判断する助けになります。LaunchDarkly は大規模な enterprise program に向いており、GrowthBook と Unleash は self-host 可能な選択肢として一般的です。Flipt はより軽量で、DIY は単純な要件に限って現実的です。

feature flag を使わないほうがよいのはどんなときですか？

すべての変更に flag を追加すべきではありません。この skill は、価値の低い flag を明示的に問い直します。たとえば、見た目だけの変更、rollback 価値のない変更、重複した flag、cleanup criteria のない flag です。直接 deploy したほうが安全でシンプルなら、そちらを選ぶべきです。Feature flag は operational surface area、testing branch、stale code risk、ownership requirement を増やします。

初心者でもこの skill を使えますか？

はい、template に沿えば使えます。taxonomy と lifecycle reference により、曖昧なリリース上の問いを checklist に変えられるため、初心者にも扱いやすくなっています。ただし、payments、authentication、data migrations、authorization、infrastructure behavior など高リスク領域では、経験のある reviewer を必ず関与させるべきです。default や targeting rule を誤ると production incident につながる可能性があります。

rollout plan を頼むだけの場合と何が違いますか？

通常の rollout prompt は、一般的な percentage を返すだけになりがちです。feature-flags-architect は rollout を risk、monitoring、kill-switch trigger、ownership、cleanup、provider constraint と結びつけます。また、実際の code を検査できる scripts も含まれているため、単独の recommendation ではなく repository からの evidence が必要な Deployment workflow でより役立ちます。

feature-flags-architect skill を改善する方法

より良い context で feature-flags-architect の結果を改善する

最も重要な入力は、運用上の具体性です。baseline metrics、target cohorts、provider name、SDK/wrapper details、environment defaults、release deadline、blast-radius concerns、そして何を「悪い状態」とみなすかを提供してください。「安全な rollout」ではなく、「authentication path, 2M daily users, abort on login failure +0.5pp, p99 latency x1.15, start with internal users, hold each ring 48 hours」のように伝えるほうが有効です。

scripts を自分たちの codebase に合わせる

同梱の Python scripts は、一般的な regex pattern と標準的な code extension を使っています。精度を上げるには、社内 wrapper 名、config file location、registry format、skip する directory を追加してください。flag が YAML、Terraform、database migrations、generated clients で宣言されている場合は、application code 以外にも discovery を広げます。script output は完全な真実ではなく、review のための signal として扱ってください。

よくある失敗パターンに注意する

大きな失敗は、曖昧な owner、恒久化した「一時的な」release flag、散らばった conditional check、OFF-branch test の欠落、document 化されていない kill switch、実際の action につながらない cleanup date です。code review output でこれらを明示的に指摘するよう skill に依頼してください。良い review は、どの flag を却下すべきか、どれにより強い runbook が必要か、どれを release flag ではなく permission flag または operational flag にすべきかを示します。

最初の出力のあとに反復する

最初の回答を得たら、feature-flags-architect に自分たちの制約に合わせて詰め直すよう依頼します。たとえば、「reduce rollout duration to 10 days」、「make this work for Unleash」、「convert this into a PR checklist」、「write the docs/feature-flags.md entry」、「turn scanner findings into cleanup tickets」のように依頼できます。最良の結果は、この skill を一度きりの generator ではなく、release-engineering reviewer として使うことで得られます。