flag-release

フラグの自動リリースを記録する

あなたは、プルリクエストの変更をガードする既存のフィーチャーフラグ（OFF で作成済み）を使用し、PR のマージ後に変更が安全にリリースされるよう自動ロールアウトを記録するスキルを使用しています。人間がフラグを切り替える必要はありません。環境ごとにチームのリリースポリシーに従い、人間が表明したリリース意図を尊重します。

これは PR フラグワークフローのリリースステップであり、意図的にアトミックになっています。

ステップ	担当
フラグ化すべきかどうかを判断する	should-flag-change（助言）
フラグを作成し、コードを配線する	launchdarkly-flag-create
リリースを記録する	このスキル

このスキルが実行される時点で、フラグは存在し（OFF）、ガード用のコードは配線済みでプッシュされています。このスキルはロールアウトを記録するだけであり、フラグを作成したりコードを編集したりすることはありません。自動化ハーネスから直接駆動することも、flag-and-release-change オーケストレーターの最終ステップとして実行することもできます。

デプロイはリリースではありません。 マージによって制御パス（フラグ OFF）が出荷されます。リリースとは、このロールアウトがその後に行うフラグ操作であり、環境のポリシーによって統制されます。

ホールドを尊重することが、絶対に間違えてはならない唯一のポイントです。 「ホールド」というリリースタイプは存在せず、policy は手動ゲートではありません。 マージ時に、policy は環境のリリース（即時、段階的、またはガード付き）を自動的に実行し、人間によるプロモーションのステップはありません。ガード付きロールアウトであっても、PR がマージされた瞬間に自動的に開始されます。したがって、ホールドしたい環境を policy として記録しても、その環境はホールドされず、notBefore の日付よりも前にマージ時にリリースされてしまいます。環境をホールドする唯一の方法は、その環境を environments 配列から完全に省略することであり、これによりその環境ではフラグが OFF のままになります。ユーザーが環境をホールドしたい（または特定の日付までリリースしたくない）場合は、その環境を呼び出しから除外し、ホールドとして報告してください。迷ったときは、省略してください。

前提条件

• リモートでホストされている LaunchDarkly MCP サーバー。
• ガード用のフラグが LaunchDarkly にすでに存在し、合意したキー/タグを付けて OFF で作成されていること。
• プルリクエストの参照（repoFullName + prNumber、または prUrl）。これによりロールアウトが正しいマージに紐付きます。

このスキルが使用する MCP ツール:

• create-automated-rollout-config — PR に対してフラグのロールアウトを記録する (成果物)
• match-release-policies — 各環境を統制するリリースポリシーを解決する（計画を提案する前に呼び出す）
• list-release-policies — プロジェクトのリリースポリシーと、それらが自動的に付与するメトリクスを確認する
• get-flag — 記録する前にフラグが存在し OFF であることを確認する

リリースモデルの全体像 — simple と policy、優先順位、プレビュー、前提条件、メトリクスの妥当性: references/auto-release.md。

計画フェーズ

このフェーズでは何も記録しません。

1. フラグを確認します。 get-flag を実行して、ガード用のフラグが存在し、OFF であることを確認します。まだ存在しない場合は停止してください — 作成は launchdarkly-flag-create の役割であり、存在しないフラグに対してロールアウトを記録すると、紛らわしいエラーで失敗します。
2. 対象環境を選びます。 ユーザーまたはハーネスが指定した環境を使用してください。セットをハードコードしないでください — 特定の変更が常にすべての環境にリリースできるとは限りません。何も指定されていない場合は、プロジェクトの実際のキーを列挙し、推測せずにそのセットを確認してください。
3. 各環境のポリシーをプレビューします。 match-release-policies を（flagKey + environmentKey で）呼び出し、policy リリースが環境ごとに何を行うかを決定論的に解決します — winningReleaseMethod（immediate / progressive / guarded / none）。ポリシーのスコープを手作業で推論しないでください。guarded が勝者となる場合は、自動付与されたメトリクスがこの変更を実際に比較できるかを確認してください（references/auto-release.md のメトリクス適切性に関する注記を参照）。
4. 人間のリリース意図を把握します。 簡潔に（まだ述べられていない場合のみ）尋ねてください: マージ時にリリースするか、保留するか（記録するがまだリリースしない）、それとも notBefore の日付まで待つか。最初に対象とするコホート/セグメントはありますか。これより先に実行してはならない前提条件となる親フラグはありますか。意図は優先順位においてポリシーより上位に位置し、尊重されるか明示的に保留されるかのいずれかであり、暗黙に破棄されることは決してありません。
5. 環境ごとの計画を提示して停止します。 各環境について、記録される releaseType（simple / policy、およびマージ時にそれが何を行うか）または 保留されること（記録される設定から省略され、その環境ではフラグが OFF のままになる）を、その理由とともに述べてください。確認を待ち、フィードバックに応じて修正してください。

実装フェーズ

確認が取れてからに限り、以下を実施します。

1. すべての対象環境を、必ず1つのバケット — RELEASE または HOLD — に分類します。 これは呼び出しを組み立てる 前に 行ってください。3つ目のバケットは存在せず、releaseType がそれを作り出すこともありません。

   バケット	意味	呼び出しに含めるもの
   RELEASE	マージ時に本番稼働する — 即時、またはそのポリシーに従って	environments 配列に { environmentKey, releaseType } を追加する
   HOLD	まだ本番稼働しない — 日付、承認、セグメント、または親フラグ待ち	何も含めない。 environments から完全に除外し、レポートで保留中として明記する

   releaseType（simple と policy）は、RELEASE 環境が どのように 本番稼働するかを選ぶだけであり、環境を保留にすることは決してありません。どちらもマージ時にリリースします: simple は即座に true を配信し、policy はその環境のポリシー（即時 / 段階的 / ガード付き）を自動的に実行し、人による昇格ステップはありません。「policy は ポリシー に委ねる」のであって、あなたに委ねるのでも、特定の日付まで待つのでもありません。保留中の環境を留めておくために policy に頼ってはいけません。それは notBefore より前に、マージ時点でその環境を出荷してしまいます。 保留を表現する唯一の方法は 配列から除外すること です。

2. RELEASE バケットのみから environments を組み立て、その後キーを読み返します。 配列にはすべての RELEASE 環境が含まれ、HOLD 環境は1つも含まれていてはいけません。呼び出しを送信する前に、配列内の environmentKey を確認してください。保留している環境がそこに現れている場合は、そのエントリを削除します。この呼び出しには 日付や保留のためのフィールドはありません — エントリに holdUntil、notBefore、hold を追加したくなったら（あるいは「待たせるため」に policy のままにしておきたくなったら）、それはその環境が HOLD であるというシグナルです: エントリを削除し、フィールドをでっち上げないでください。 日付と理由は呼び出しではなくレポートに記載します。

   具体例 — 「staging はマージ時にリリース、production は 2026-09-01 まで保留」: staging は RELEASE、production は HOLD です。

   {
     "projectKey": "default",
     "flagKey": "new-checkout-flow",
     "environments": [{ "environmentKey": "staging", "releaseType": "simple" }],
     "repoFullName": "acme/storefront",
     "prNumber": 482
   }
   

   production は呼び出しのどこにも現れません。2026-09-01 まで保留であることと、その理由（法務承認）をレポートします。フェイルクローズドで: 環境の意図が不明確な場合は RELEASE ではなく HOLD です。

3. ロールアウトを記録します。 projectKey、flagKey、RELEASE のみの environments 配列、および PR 参照を指定して create-automated-rollout-config を呼び出します。前提条件の親フラグが合意されている場合は、MCP サーフェスが対応していれば接続し、そうでなければ手動ステップとして報告します。詳細: references/auto-release.md。

4. 検証します。 呼び出しは created、config_id、および正規化された環境ごとのプランを返します — config_id を記録してください。検証できたことのみを報告し、確認できなかったことは断言せずに指摘してください。

5. 報告します: 環境ごとのリリースプラン + config_id、保留されたもの（およびその理由）とマージ時にリリースされるもの、そしてマージ時に何が起こるか（例: 「production はポリシー X を解決 → マージ時にガード付きロールアウト、staging は即座に true を配信、production は意図に従い 2026-08-01 まで保留」）。

エッジケース

状況	対応
フラグがまだ存在しない	停止してください — 作成は launchdarkly-flag-create です。存在しないフラグに対してロールアウトを記録すると、紛らわしい形で失敗します。
このフラグ + PR に対してロールアウト設定がすでに存在する	2 つ目を記録しないでください — 重複はスケジューラーを混乱させます。計画を変更するには、既存の設定をユーザーに示してください。
PR が存在する前に登録する	simple 環境は PR なしでも機能しますが、policy 環境はマージ時にトリガーするために repoFullName/prNumber が必要です。PR がオープンした後に記録することを推奨します。早期に記録する場合は、PR が接続されるまで policy は発火しないことを伝えてください。
どのリリースポリシーも環境に一致しない	policy はデフォルト（多くの場合、即時）にフォールバックします。ユーザーに伝えてください。simple を提案するか、リリースポリシーの設定を案内してください。
ユーザーが保留、または notBefore 日付を設定したい	それらの環境ではリリース計画をスキップし、理由とともに保留として報告してください。明示された意図に反して暗黙にリリースしないでください。
変更がまだ稼働していない親フラグに依存している	前提条件でそれらを結合してください（MCP サーフェスが対応していれば設定します）。そうでなければ、その結合を必要な手動ステップとして報告してください。このフラグを親より先にリリースさせないでください。
policy 環境がガード付きに解決されるが、関連するメトリクスがない	その旨を伝えてください — 意味のあるメトリクスのないガード付きロールアウトは何もガードしません。simple を推奨するか、メトリクスの設定を案内してください。

やってはいけないこと

• フラグを作成したりコードを編集したりしないでください — それは launchdarkly-flag-create です。このスキルはリリースを記録するだけです。
• 自分でフラグをオンにしたり、設定を記録した後にトグルしたりしないでください。 ロールアウトがそれを担います。二重のトグルは監査ノイズを生み、スケジューラーを混乱させます。
• match-release-policies をスキップしないでください。 何に解決されるか知らずに policy を提案するのは推測です。
• 明示された保留 / notBefore に反して暗黙にリリースしないでください。 意図を尊重するか、保留してください — 決して破らないでください。
• 認証情報を扱ったり出力したりしないでください。 アクセスは環境によって注入されます。

リファレンス

• references/auto-release.md: 自動ロールアウト / リリースポリシーのモデル、simple と policy、優先順位（意図 → オーバーライド → ポリシー → デフォルト）、プレビュー、前提条件、メトリクスの妥当性。(このスキルの中核です。)
• launchdarkly-guarded-rollout: どのポリシーでも表現できないオーダーメイドのロールアウト向け — ここでその環境を simple に設定し、マージ後にガード付きロールアウトを手動で進めてください。