land-and-deploy

land-and-deploy の概要

land-and-deploy の役割

land-and-deploy は、マージ済み PR から本番デプロイの検証完了までをつなぐワークフロー用スキルです。リリース工程の land-and-deploy ステップ、つまり「変更をマージする → CI とデプロイを待つ → カナリアチェックでアプリの正常性を確認する」という流れに合わせて作られています。最終リリース手順まわりの判断を減らしたいなら、この land-and-deploy スキルはその用途に向いています。

どんな人に向いているか

エージェントに「マージして」「PR を着地させて」「本番に出して」「マージして検証して」とよく頼むなら、land-and-deploy を入れる価値があります。すでに /ship や PR 作成のステップがあり、その後のデプロイと確認までを受け持つスキルがほしい運用者に特に有効です。逆に、エージェントによるマージ・デプロイ・本番検証をそもそも許可していないチームでは、あまり役に立ちません。

何が違うのか

価値の中心は、ありきたりなリリース助言ではなく、安全な操作、CI/デプロイ待機、本番後の検証を明示した制約付きのデプロイワークフローにあります。land-and-deploy スキルにはルーティングと前置きの挙動も含まれており、広い一般論を即興で返すのではなく、このワークフローをいつ引き受けるべきかをエージェントが判断しやすくなっています。

land-and-deploy スキルの使い方

インストール時の文脈とトリガーフレーズ

スキルマネージャーで land-and-deploy install の流れを使い、タスクが「変更を着地させて本番の健全性を確認する」ことに明確に当てはまるときに呼び出してください。リポジトリ説明やトリガーには、merge and deploy、land the pr、ship to production、merge and verify といった表現が挙がっています。実運用では、強い land-and-deploy usage プロンプトに、どのブランチや PR が準備完了か、どの環境を想定しているか、そして「完了」の条件は何かを入れるのが重要です。

最初に読むべきファイル

まず SKILL.md を読み、その後 SKILL.md.tmpl を見て、挙動を生成するテンプレート元を確認してください。このリポジトリには rules/、references/、resources/、scripts/ フォルダがないため、主要な実装はスキルファイル自体にあります。land-and-deploy guide の読み方としては、最初に前置き、安全操作の制約、plan-mode の挙動、ルーティングの各セクションを重点的に確認すると理解しやすいです。

よい実行にするためのプロンプトの書き方

エージェントが安全に動けるよう、必要最小限のリリース情報を渡してください。たとえば、リポジトリ名、PR リンクまたはブランチ、デプロイ先、必要な承認、デプロイ後に確認したいヘルスシグナルなどです。より良いプロンプトは具体的です。たとえば「land-and-deploy を使って PR #184 をマージし、CI と本番デプロイを待ってから、staging-to-prod rollout で canary チェックが通ることを確認して」と書きます。リポジトリの文脈で対象が自明でない限り、「とりあえず出して」のような曖昧な依頼は避けてください。

重要なワークフローのコツ

このスキルは PR 作成後を引き受ける前提なので、変更内容そのものをエージェントに考えさせないでください。デプロイ経路にリポジトリ固有のコマンド、ブランチ命名、必須の検証 URL があるなら、最初に明示してください。land-and-deploy for Deployment で品質が上がりやすいのは、受け入れ確認を明確にしたときです。たとえば、smoke test、canary、status page、その他の本番ヘルス指標のどれを見ればよいかをはっきりさせると効果的です。

land-and-deploy スキルの FAQ

これは単なる汎用デプロイ用プロンプトですか？

いいえ。land-and-deploy は、マージから本番までの工程に特化した運用スキルで、CI の待機、デプロイの待機、正常性確認を明示的にサポートします。通常のプロンプトでもその流れ自体は書けますが、このスキルはその手順を一貫して実行させることを目的にしています。

いつ使わないほうがいいですか？

設計判断、コード実装、まだマージ可能になっていないリリース計画が必要な場合は、land-and-deploy は使わないでください。また、組織が自動マージや本番操作を禁止している場合、あるいはエージェント実行なしの手動チェックリストだけが必要な場合にも不向きです。

初心者向けですか？

はい。ただし、対象リポジトリ、PR、デプロイの期待値を言語化できることが前提です。スキルはリリースの曖昧さを減らしますが、何を着地させるのか、成功をどう測るのかは運用者が分かっている必要があります。初心者は、PR を渡して land-and-deploy のワークフローをそのまま実行するよう依頼すると、最も良い結果を得やすいです。

何と比較すべきですか？

land-and-deploy は、単純な「merge and deploy」プロンプトと比較するとよいです。繰り返し使える挙動、安全操作の境界をそろえたい場合、そしてマージから検証までの道筋を明確にしたい場合は、このスキルのほうが優れています。一度きりの手順で足りるならプロンプトでも十分ですが、これが定常的なリリース手順なら、導入判断としてはスキルのほうが有力です。

land-and-deploy スキルを改善する方法

リリース入力をより具体的にする

land-and-deploy の出力を改善する一番の方法は、正確な PR、ブランチ、環境、検証方法を指定することです。「これをデプロイして」ではなく、「PR #57 を main に着地させ、production パイプラインを待ち、/health が 200 を返して release canary が green であることを確認して」と伝えてください。そうすると、このスキルに明確なゴールを与えられます。

失敗要因を早めに減らす

よくある失敗要因は、デプロイ文脈の不足、承認境界の不明瞭さ、本番後チェックの弱さです。保護ブランチ、必須レビュー、feature flag、手動ロールアウト手順があるなら、スキルを動かす前に必ず明示してください。そうすることで、エージェントがポリシー制約の周辺を推測したり、マージ後に早々と止まったりするのを避けられます。

1 回目の実行後に調整する

最初の land-and-deploy 実行が慎重すぎる、範囲が広すぎる、あるいは見ている指標がずれているなら、目的を言い直すのではなく、足りない運用情報を足してプロンプトを詰めてください。リポジトリ固有のコマンド、デプロイダッシュボードへのリンク、確認したい正確な canary 条件を追加するのが近道です。そうすれば、land-and-deploy を汎用的なデプロイスクリプトではなく、実際のリリース工程に沿って動かせるようになります。