instrument-feature-flags

PostHog のフィーチャーフラグを追加する

このスキルを使用して、新規または変更された機能を制御する PostHog のフィーチャーフラグを追加します。機能の実装後や PR のレビュー後に使用し、フィーチャーフラグによる制御で安全にロールアウトできるようにします。PostHog がまだインストールされていない場合は、このスキルで初期 SDK セットアップも行います。あらゆるプラットフォームや言語に対応しています。

対応プラットフォーム：React、Next.js、React Native、Web（JavaScript）、Node.js、Python、PHP、Ruby、Go、Java、Rust、.NET、Elixir、Android、iOS、Flutter、REST API。

手順

以下の手順を順番どおりに実行してください。

STEP 1: コードベースを分析し、プラットフォームを検出します。

依存関係ファイル（package.json、pubspec.yaml、Podfile、Package.swift、requirements.txt、go.mod、Gemfile、composer.json、mix.exs など）を確認し、言語とフレームワークを特定します。

ロックファイル（pnpm-lock.yaml、package-lock.json、yarn.lock、bun.lockb、go.sum、pubspec.lock、Podfile.lock、Package.resolved、mix.lock）を確認し、パッケージマネージャーを特定します。

• PostHog の既存のセットアップ（SDK の初期化、環境変数など）を確認します。PostHog がすでにインストールされ、初期化されている場合は、STEP 3 に進みます。

STEP 2: 計測方法を調査します。（PostHog がすでにセットアップされている場合はスキップします。） 2.1. 検出したプラットフォームに対応する、以下のリファレンスファイルを探します。このファイルは、SDK の初期化、フラグの評価方法、フレームワーク固有のパターンに関する信頼できる情報源です。今すぐ読み込んでください。 2.2. 該当するリファレンスがない場合は、一般知識とウェブ検索を利用します。主要な検索先として posthog.com/docs を使用してください。

STEP 3: フィーチャーフラグを作成するか、既存のものを探します。

• PostHog MCP サーバーが接続されているか確認します。利用できる場合は、そのツールを使って、ユーザーが設定したい既存のフィーチャーフラグを検索するか、新しいフラグを作成します。
• MCP サーバーを利用できない場合は、PostHog ダッシュボードでフラグを作成するようユーザーに案内します。

STEP 4: リリース条件を計画します。

• ロールアウト戦略（割合によるロールアウト、ユーザーのターゲティング、グループのターゲティングなど）を決定します。
• コード内でフィーチャーフラグを使って新機能を制御する方法を計画します。

STEP 5: 機能に計測を追加します。

• プラットフォーム固有のリファレンスパターンに従って、フィーチャーフラグのコードを追加します。
• UI のちらつきを避けるため、可能な場合はサーバーサイド評価を使用します。
• 既存ファイルの基本的なアーキテクチャを変更しないでください。追加は最小限かつ対象を絞って行います。
• ファイルを書き込む前に、必ずそのファイルを直前に読み込んでください。

STEP 6: 環境変数をセットアップします。

• プロジェクトに PostHog の環境変数がすでに設定されているか（例：.env、.env.local、またはフレームワーク固有の環境ファイル）確認します。有効な値がすでに存在する場合は、この手順をスキップします。
• PostHog のプロジェクトトークンが設定されていない場合は、PostHog MCP サーバーの projects-get ツールを使って、プロジェクトの api_token を取得します。複数のプロジェクトが返された場合は、どのプロジェクトを使用するかユーザーに尋ねます。MCP サーバーが接続されていない、または認証されていない場合は、PostHog のプロジェクトトークンをユーザーに尋ねます。
• PostHog のホスト URL については、projects-get MCP のレスポンスに region フィールドがあるか確認します。US は https://us.i.posthog.com、EU は https://eu.i.posthog.com に対応します。MCP のレスポンスにも既存のプロジェクト設定にもリージョンがない場合は、ユーザーに「PostHog US Cloud と EU Cloud のどちらを利用していますか？」と尋ねます。US Cloud と決めつけないでください。
• これらの値を、フレームワークの命名規則に従って適切な環境ファイルに書き込みます。
• 値をハードコードするのではなく、コード内でこれらの環境変数を参照します。

リファレンスファイル

• references/react.md - React の機能フラグのインストール
• references/react-native.md - React Native の機能フラグのインストール
• references/web.md - Web の機能フラグのインストール
• references/nodejs.md - Node.js の機能フラグのインストール
• references/python.md - Python の機能フラグのインストール
• references/django.md - Django
• references/flask.md - Flask
• references/php.md - PHP の機能フラグのインストール
• references/laravel.md - Laravel
• references/ruby.md - Ruby の機能フラグのインストール
• references/ruby-on-rails.md - Ruby on Rails
• references/go.md - Go の機能フラグのインストール
• references/java.md - Java の機能フラグのインストール
• references/rust.md - Rust の機能フラグのインストール
• references/dotnet.md - .NET の機能フラグのインストール
• references/dotnet.md - .NET
• references/elixir.md - Elixir の機能フラグのインストール
• references/android.md - Android の機能フラグのインストール
• references/ios.md - iOS の機能フラグのインストール
• references/usage.md - iOS SDK の使い方
• references/flutter.md - Flutter の機能フラグのインストール
• references/api.md - API の機能フラグのインストール
• references/next-js.md - Next.js
• references/adding-feature-flag-code.md - 機能フラグのコードの追加
• references/best-practices.md - 本番環境に対応したフラグのベストプラクティス
• references/COMMANDMENTS.md - インテグレーションが従うべきフレームワーク固有のルール

各プラットフォームのリファレンスには、SDK 固有のインストール方法、フラグの評価方法、コード例が記載されています。ユーザーの技術スタックに一致するものを選んでください。該当するものがない場合は、代替として API のリファレンスを使用してください。

重要な原則

• 環境変数：PostHog のキーには必ず環境変数を使用してください。ハードコードしないでください。
• 変更は最小限に：既存のロジックに機能フラグのコードを追加してください。既存のコードを置き換えたり、再構成したりしないでください。
• まずはブール値フラグ：ユーザーが多変量フラグを明示的に求めていない限り、ブール値のフラグチェックを使用してください。
• 可能な限りサーバーサイドで：UI のちらつきを避けるため、サーバーサイドでのフラグ評価を優先してください。