launchdarkly-factory-settings

LaunchDarkly Factory の設定

LaunchDarkly MCP を通じて Factory（GitHub App のコード自動化）を設定するスキルを使用しているか、PR が分類されなかった理由を調べています。Factory はプルリクエストを作成・変更（自動フラグ設定）したり、自動リリースを実行したりできます。書き込みはすべて、本番環境の自動化であり、影響範囲が広いものとして扱ってください。

前提条件

このスキルには、リモートホスト型の LaunchDarkly MCP サーバーが必要です。

必須の MCP ツール：

• get-factory-settings / update-factory-settings
• list-factory-github-repos（GitHub App のインストール — マッピング可能なリポジトリ）
• list-factory-repo-settings（すでにマッピング済み）
• update-factory-repo-settings / get-factory-repo-settings / delete-factory-repo-settings

これらのツールがない場合は、処理を停止してください。REST 呼び出し、数値の GitHub ID、または設定を推測した「修正」を捏造しないでください。

Factory の設定はアルファ版です。基盤となるエンドポイントは enable-factory-settings フラグによって制御されています。Factory のすべてのツールが 404 を返す場合、そのアカウントはアルファ版を利用できません。再試行や REST へのフォールバックはせず、その旨をユーザーに伝えてください。

基本原則

1. 安全側に倒す。 原因の調査は読み取り専用です。現在の状態と変更案をユーザーに示し、対象の書き込みについて確認を得るまでは、「分類が機能するように」設定を変更しないでください。
2. アカウント設定が最上位の制御です。 マッピング済みのリポジトリでも、アカウントで無効になっている機能を有効にはできません。アカウントレベルで機能を無効にすると、すべてのマッピング済みリポジトリでその機能が無効になります。アカウントレベルで機能を有効にすると、オフの上書き設定をしていない継承対象のマッピング済みリポジトリすべてで、PR の自動処理が開始される可能性があります。
3. Factory への書き込みの前に、毎回確認を得てください。 アカウントへの PATCH、マッピング、リポジトリの上書き設定、マッピング解除には、すべて書き込み前の確認を適用してください。ユーザーが指定したリポジトリだけを操作してください。
4. 最小権限を守ってください。 ユーザーが自動リリースを明示的に依頼していない限り、自動リリースを有効にしないでください（コードがリリースされる可能性があります）。ユーザーが承認ゲートを外すよう明示的に依頼していない限り、approvalRequired をオフにしないでください。ユーザーが指定していないリポジトリをマッピングまたはマッピング解除しないでください。インストール一覧を順に処理して、すべてをマッピングしないでください。
5. 確認してからマッピングしてください。 owner/name を渡してください。数値の GitHub ID は求めないでください。「このリポジトリ」または「この PR」と言われた場合は、現在のワークスペースの git remote を優先してください（フォークと上流リポジトリでリモートが一致しない場合は、どちらを指すのか確認してください）。owner/name は GitHub App のインストール一覧に対してのみ解決されます。Factory は App を通じて動作するため、インストール対象外のリポジトリは解決も操作もできません。リポジトリがインストール対象外、または App がインストールされていないことを示す 404 が返った場合は、それが回答です。別の表記を試したり、他の場所でリポジトリを検索したりしないでください。
6. 初回マッピングでは projectKey が必須です。 マッピングの作成時に必要です。以降の更新では省略できます。
7. autoCleanup は省略してください。 これはまだ Factory の設定に含まれていません。送信しないでください。レスポンスからコピーして PATCH に含めることもしないでください。
8. GitHub の接続にはブラウザーリンクを使います。 list-factory-github-repos が githubConnectUrl を返した場合は、その URL をそのままユーザーに提示し、ユーザーが完了したと伝えるまで待ってください。その後、list-factory-github-repos をもう一度呼び出してください。GitHub のインストールや認可をユーザーに代わって行わないでください。flow=install は GitHub App のインストール、flow=authorize は GitHub の認可です。どちらもインテグレーションのドロワーと同じページを開きます。ユーザーは、そのブラウザーで LaunchDarkly にログイン済みである必要があります。

書き込み前に確認する

停止してください。 このターンの提案に対してユーザーが「はい」と回答するまで、update-factory-settings、update-factory-repo-settings、delete-factory-repo-settings を呼び出さないでください。前のターンでの「はい」や、設定を明示していない曖昧な「修正して」「進めて」では不十分です。

1. まず現在の状態を確認します（変更がリポジトリに限定される場合は、get-factory-settings と、リポジトリの取得／一覧表示を行います）。
2. 現在の状態と提案内容を、1〜2文で伝えます。影響範囲を含めます。マッピングの場合は、get-factory-settings を先に読み取り、アカウントから継承される自動フラグ付けと自動リリースの両方を伝えます。
3. ユーザーの返答を待ちます。質問と同じツール実行ラウンドで書き込みをまとめて行ってはいけません。

アカウントの変更（update-factory-settings のすべてのフィールド。機能を有効にする場合も含む）：

このアカウントでは自動フラグ付けがONです。マッピングされているすべてのリポジトリでOFFにしますか？自動フラグ付けPRは、再びONにするまで停止します。

このアカウントでは自動フラグ付けがOFFです。アカウントでONにしますか？この設定を継承するマッピング済みリポジトリでは、自動フラグ付けPRが開始される可能性があります。

自動フラグ付けのapprovalRequiredはONです。OFFにしますか？自動フラグ付けPRにこの承認ゲートが不要になります。

自動リリースについても同じ形式で確認し、自動リリースによってリリースが実行される可能性があることを伝えます。

マッピングまたは1つのリポジトリの変更（update-factory-repo-settings）：

提案では、継承されるアカウントの機能を両方必ず明示します。上書き項目を省略すると、自動フラグ付けと自動リリースの両方が継承されます。自動フラグ付けだけに触れた確認では、マッピングを行わないでください。

launchdarkly/gonfalon はマッピングされていません。プロジェクト default にマッピングし、アカウントの自動フラグ付け（ON）と自動リリース（OFF）を継承しますか？Factory はこのリポジトリで分類を開始し、自動フラグ付けPRを作成できるようになります。アカウント（またはリポジトリの上書き設定）でONにしない限り、自動リリースはOFFのままです。

launchdarkly/gonfalon はマッピングされていません。プロジェクト default にマッピングし、アカウントの自動フラグ付け（ON）と自動リリース（ON）を継承しますか？Factory はこのリポジトリで自動フラグ付けPRと自動リリースを開始できるようになり、リリースが実行される可能性があります。

launchdarkly/gonfalon は、自動フラグ付けの実効値がON、自動リリースの実効値がOFFで、default にマッピングされています。このリポジトリだけ自動フラグ付けをOFFにする上書き設定を行いますか？自動リリースは継承された設定（OFF）のままです。

マッピング解除（delete-factory-repo-settings）：

launchdarkly/gonfalon は、自動フラグ付けの実効値がON、自動リリースの実効値がOFFで、プロジェクト default にマッピングされています。マッピングを解除しますか？再びマッピングされるまで、Factory はこのリポジトリの自動フラグ付けと自動リリースを停止します。

ユーザーの確認後、提案したフィールドだけを適用します。その後、検証します（安全確認として検証を使ってはいけません）。

ワークフローを選択する

• 「Factory がPRを分類／自動フラグ付けしなかったのはなぜですか？」（または同様の質問） → まずPRが分類されなかったのはなぜですか？を参照してください。このワークフローでは設定を書き込まないでください。
• 設定、マッピング、有効化、マッピング解除 → 設定する。

PR が分類されなかったのはなぜですか？

PR が分類されなかった、自動フラグが付けられなかった、または Factory が PR を無視した理由をユーザーが尋ねた場合に使用します。読み取り専用です。 次の順に確認してください。最初に問題が見つかった時点で確認を止め、修正方法を伝えてください（修正の適用を求められた場合は、書き込み前に確認してください）。

PR の URL、git remote、またはユーザーが伝えた名前から GitHub リポジトリ（owner/name）を特定してください。リポジトリを 1 つに特定できない場合は、ユーザーに確認してください。別のリポジトリを診断してはいけません。

1. アカウントで自動フラグ付けは有効になっていますか？ get-factory-settingsを実行します。autoFlagging.enabledが false の場合、それが理由です。アカウント側で無効になっているため、どのリポジトリでも自動フラグ付けされません。ここで終了してください。
2. このリポジトリはプロジェクトにマッピングされていますか？ repo: "owner/name"を指定してget-factory-repo-settingsを実行するか、list-factory-repo-settingsで該当リポジトリを探します。エラーまたはlist-factory-github-reposの結果にgithubConnectUrlが含まれる場合は、flowを確認してください。
   • flow=install：GitHub App がインストールされていないため、Factory は PR を認識できません。それが理由です。ユーザーにリンクを提示して終了してください。
   • flow=authorize：このメンバーは GitHub を認証していないため、owner/nameを照会できません。これは Factory が PR を処理しなかった理由ではありません。その旨を伝え、リンクを提示して、ユーザーが認証を完了した後にこの手順から再開してください。これを修正方法として報告してはいけません。

インストール対象ではあるものの、マッピングされていないリポジトリの場合は、別の理由です。マッピングされていないインストール対象リポジトリでは Factory は実行されません。ここで終了してください。 3. このリポジトリで自動フラグ付けが無効に上書きされていますか？ リポジトリのペイロードで、自動フラグ付けのenabledが false の場合、またはenabledOverrideが true かつenabledが false の場合、アカウントで有効になっていても、このリポジトリでは無効になっています。ここで終了してください。

3 つすべてに問題がない場合（アカウントで有効、リポジトリがマッピング済み、リポジトリで自動フラグ付けが実質的に有効）：

• 「試しに」設定を変更してはいけません。
• Factory のランブックを案内してください。Factory はアルファ版のため、これらは内部向けの LaunchDarkly Confluence ページ（PD スペース）です。公開ドキュメントの URL はまだありません。この MCP インターフェースでは確認できない理由（誤った組織への GitHub App のインストール、インストール済みリポジトリに PR がない、ワークフロー／アプリの権限、分類器のスキップルールなど）で分類が失敗することもあります。
  • Flag Classification (ODD) Runbook — 分類器そのものについて説明しています。判定（not-suited、already-flagged）、エスカレーション、および PR がその判定になった理由を記録する PR ごとの台帳を扱います。
  • GitHub App Runbook — PR イベントが Factory に届かない場合について説明しています。インストール範囲、権限、Webhook を扱います。
• 任意の確認項目：リポジトリがインストールリストに含まれていることを確認するにはlist-factory-github-reposを実行します。また、PR が存在するのに承認待ちになっている場合、ユーザーが PR が処理されると思っていたのであればautoFlagging.approvalRequiredを確認します。

設定を構成する

手順 1：現在の設定を読み取る

1. get-factory-settings
2. list-factory-repo-settings
3. list-factory-github-repos（projectKeyは任意。インストール設定はアカウント全体に適用されます）

githubConnectUrlがある場合は、ユーザーにそのリンクを提示して、このターンを終了してください。後続の呼び出しで URL が表示されなくなるまでは、マッピングしてはいけません。

手順 2：アカウントのデフォルト設定（必要な場合）

アカウントの PATCH が必要な場合は、書き込み前に確認に従ってから、確認済みのフィールドのみを指定してupdate-factory-settingsを実行してください。

• autoFlagging.enabled / autoFlagging.approvalRequired（承認が有効なのはここだけです）
• autoReleasing.enabled

autoCleanupを送信してはいけません。updateFactorySettingsが必要です。

手順 3：リポジトリをマッピングまたは上書きする

ユーザーが指定したリポジトリのみを対象にします。書き込み前に確認に従ってから、update-factory-repo-settingsを実行してください。

1. repo: "owner/name"を優先します。
2. マッピングを作成する場合はprojectKeyを指定します。
3. リポジトリ単位のautoFlagging / autoReleasingの上書きは任意です。省略した機能はアカウント設定を継承します。アカウントで無効になっている機能を、リポジトリで有効にすることはできません。

マッピング先のプロジェクトでupdateFactoryRepoSettingsが必要です。

ステップ 4：確認（書き込みの確定後）

• 適切に get-factory-repo-settings / get-factory-settings を実行します。
• 有効な enabled は提案内容と一致している必要があります（アカウントがオフの場合、リポジトリをオンにはできません）。
• マッピングされたリポジトリが list-factory-repo-settings に表示されます。

マッピングを解除するには、書き込み前に確認してから、delete-factory-repo-settings を実行します。

対象範囲外

• 自動クリーンアップ
• ツール内での GitHub OAuth の完了。代わりに githubConnectUrl をユーザーに渡します。
• Vega BYOK
• Observability MCP（github_repositories）— Factory リポジトリをマッピングするためだけに、2 つ目の MCP サーバーを必須にしないでください
• このスキルを通じた分類ルール、GitHub App の権限、または組織のインストール範囲の変更