flag-and-release-change

PR の変更をフィーチャーフラグ化してリリースする

あなたは、変更がフィーチャーフラグの背後で出荷されるべきプルリクエストを受け取り、それをエンドツーエンドで進めるスキルを使用しています。フラグが必要だと判断し、ガードするフラグを作成し、PR のブランチ上で新しい動作をその背後に配線し、自動リリースを記録して、PR のマージ後に変更が安全に出荷されるようにします。

デプロイはリリースではありません。 マージによって出荷されるのは制御パスです。フラグは OFF で作成されるため、デプロイは常に変更前の動作を提供します。リリースとは、その後で自動ロールアウトが実行するフラグ操作であり、環境のポリシーによって制御されます。フラグを OFF で作成することとリリースを記録することは、意図的に別々のものになっています。

このスキルはポータブルな PR オーケストレーターです。フラグの仕組みやリリースの仕組みを自ら所有するのではなく、3 つの焦点を絞ったスキルを組み合わせ、さらに PR ワークフロー（diff を読み、クローンで作業し、ブランチへプッシュする）と plan→implement の順序付けを追加します。

ステップ	所有するもの	このスキルの役割
フラグ化すべきかどうかを判断する	should-flag-change（アドバイザリ、読み取り専用）	「はい」に基づいて行動する。実行されていなければ自分で判断する
フラグを作成し、コードを配線する	launchdarkly-flag-create	変更に対してこれを呼び出す。フラグ作成や SDK パターンを再説明しない
リリースを記録する	flag-release	フラグが存在しコードがプッシュされたら引き継ぐ。ロールアウトの仕組みを再説明しない

ここで、組み合わせた各スキルの仕組みを重複して説明しないでください。このスキル独自の内容は、PR ラッパー（クローン、スリードット diff、ブランチへのコミット/プッシュ）と、3 つをつなぎ合わせる plan→implement のフローだけです。

自動化に関する注意。 オーケストレーションするハーネス（例: PR パイプライン）は、このスキルをスキップして、組み合わせた 3 つのスキルを直接呼び出すことができます — should-flag-change → launchdarkly-flag-create → flag-release — git と順序付けを自ら駆動します。このスキルは、開発者が PR を手作業で進めるための、ポータブルで human-in-the-loop な経路です。

あなたは 2 つのフェーズ — plan、次に implement — で作業し、その間でユーザーに確認を取ります。plan フェーズでは、何も作成または変更しないでください。

前提条件

• リモートでホストされた LaunchDarkly MCP サーバー。
• PR のリポジトリを読み取り、プッシュできる git CLI。
• 利用可能な組み合わせ対象のスキル: launchdarkly-flag-create（フラグ作成 + コード配線）と flag-release（ロールアウトの記録）。フラグの判断がまだ行われていない場合は should-flag-change を使用します。

MCP ツールは組み合わせたスキルを介して使用されます — create-flag/get-flag は flag-create を通じて、match-release-policies/create-automated-rollout-config は flag-release を通じて使用します。このスキルはどれも直接呼び出しません。

プルリクエストの扱い

変更を読み取り、フラグの配線をそのブランチへプッシュできるように、クローンから作業します。認証情報は環境によって提供されます — トークンを要求したり、出力したり、保存したりしないでください。

git clone https://github.com/<owner>/<repo>.git && cd <repo>
git fetch origin pull/<pr_number>/head
git diff origin/HEAD...<head_sha>       # three-dot: change relative to the PR's base

スリードット diff（base...head）は、PR が導入する内容を正確に示します。変更とそのリスクを理解するために必要な変更ファイルを読み取ってください。両方のフェーズを通じてこのクローンに留まってください — implement ではここで編集し、コミットし、プッシュします。PR の完全な仕組み（クローン、スリードット diff、ブランチへのコミット/プッシュ）: references/pr-wiring.md。

計画フェーズ

このフェーズでは何も作成しないでください。

1. フラグを立てるべきか確認します。 should-flag-change がすでに実行されている場合は、その判定に従って行動します。そうでない場合は同じ判断を適用します。ユーザー向けの変更やリスクのある変更にはフラグを推奨し、設定のみ、依存関係の更新、インフラ、テストのみ、ドキュメントの変更はスキップします。フラグが明らかに不要な場合は、その旨を伝えて停止します。
2. 変更と規約を理解します。 three-dot diff と変更されたファイルを読みます — それは何をするのか、影響範囲はどこまでか？ 次に flag-create のステップ 1 に従い、このコードベースがすでにフラグをどのように使用しているか（SDK、ラッパー、主要な定数、命名）を学びます。ここでその調査を再発明しないでください。
3. フラグを設計します。 通常は新しい経路を囲む単一の boolean キルスイッチです（flag-create の flag-types に選択肢がまとめられています）。変更が必要とする以上に多くのフラグを提案しないでください。ステップ 1（または should-flag-change）で、まだ有効になっていない親フラグ／機能への依存が見つかった場合は、それを記録します — リリースのステップで前提条件としてそれらを結合できます。
4. リリースを計画します。 flag-release の計画フェーズに従います。対象環境を選び、match-release-policies でそれぞれをプレビューし、人間のリリース意図（マージ時にリリース / 保留 / notBefore / セグメント / 前提条件）を記録します。ここでロールアウトモデルを再導出しないでください — それは flag-release の役割です。
5. 統合した計画を提示して停止します。 以下を要約します。フラグ（key、name、boolean、tags）と、なぜそれがこの変更をゲートするのか。コード内でガードをどこに置くか。環境ごとのリリース計画と記録した意図（および保留するもの）。その後、待機します。フィードバックに基づいて修正し、明確な承認があった場合にのみ進めます。本当に何かが欠けている場合（プロジェクトキー、環境、欠落したポリシー）は、推測するのではなく焦点を絞った質問をします。

実装フェーズ

承認後のみ：

1. launchdarkly-flag-create（そのステップ 3〜4）を使用してフラグを作成し、コードを接続します。合意した key/tags でフラグを OFF で作成し、コードベースのパターンに一致する安全なデフォルトでガード評価を追加します。作成エラー時はフェイルクローズします。「すでに存在する」という結果のみが再利用による成功です。それ以外のフラグ作成失敗（認証、権限、not-found、サーバーエラー）はハードストップです — コードを接続したり、リリースを記録したり、成功を報告したりしてはいけません。偽の「フラグ作成済み」は、存在しないフラグを参照するグリーンな PR を生み出し、正直な失敗よりも悪い結果になります。エラーを提示して停止します。
2. フラグ ON / フラグ OFF の対になるテストを追加します。 リポジトリにテストスイートがある場合は、ラップされた経路の各状態に対するテストを追加します — フラグ ON は新しい動作を提供し、フラグ OFF は古い動作を保持します — リポジトリのフレームワークとフラグモックの規約に一致させます。それらを実行し、グリーンになってから続行します。テストは一般的なカバレッジではなく、フラグが付いた経路に範囲を絞ります。リポジトリにテストがない場合は、スキップしてその旨を伝えます。
3. コミットして PR ブランチにプッシュします。 接続をコミットし、PR の既存ブランチにプッシュして同じ PR に含めます — 新しい PR を開いたり、ベースブランチに触れたりしないでください。references/pr-wiring.md を参照してください。
4. flag-release の実装フェーズに引き継いでリリースを記録します。これにより、記録した意図を尊重して自動ロールアウトが記録され（意図がクリアしない環境は保留されます）、config_id が返されます。ここでロールアウトの仕組みを再教示しないでください。
5. 変更全体を報告します。フラグ key + LaunchDarkly リンク（OFF で作成）。接続したファイル／コード経路。追加したテスト。環境ごとのリリース計画 + config_id。保留したもの（およびその理由）とマージ時にリリースされるもの。検証したものだけを報告します。

エッジケース

状況	対応
変更がフラグを立てる価値がない	理由 (設定のみ、依存関係の更新、インフラ、テストのみ、ドキュメント) を説明して終了します。フラグを作成しないでください。
フラグがすでに存在する	それを再利用します — 「すでに存在する」は成功です。既存のキーを接続し、重複させないでください。
その他の理由 (認証、権限、5xx) でフラグの作成が失敗する	ハードストップです。コードを接続したり、リリースを記録したり、成功を主張したりしないでください — エラーを表面化させてください。
コードベースに LaunchDarkly SDK がない	接続だけではフラグを評価できません — SDK のインストールは別です (onboarding/sdk-install)。
ガードに boolean 以上のものが必要	boolean のキルスイッチを優先してください。変更が異なるバリアントに対応する場合にのみ多変量にしてください。flag-create の flag-types を参照してください。
リリース固有のケース (hold/notBefore、前提条件、一致するポリシーがない、設定の重複、有用なメトリクスがない)	flag-release で処理されます — そのエッジケースを参照してください。

やってはいけないこと

• 計画フェーズで何も作成しないでください。 計画は提案し、実装は作成します。
• ここでフラグの作成、SDK ガード、ロールアウトの仕組みを再ドキュメント化しないでください — それらは launchdarkly-flag-create と flag-release です。それらにリンクしてください。
• 自分でフラグをオンにしないでください。 記録されたリリースがそれを担います。フラグを OFF で作成することが要点です。
• 過剰にフラグを立てないでください。 1 つのキルスイッチが複数の投機的なフラグに勝ります。
• 認証情報を扱ったり出力したりしないでください。 Git アクセスは注入されます。

参照

• references/pr-wiring.md: PR の仕組み — クローン、スリードット差分、PR ブランチへのコミット。(このスキル独自の唯一の参照。)
• should-flag-change: フラグを立てる価値の判断。
• launchdarkly-flag-create: フラグの作成 + SDK ごとのガードパターン。
• flag-release: 自動ロールアウトの記録 (およびその auto-release.md リリースモデル)。