setup-deploy

setup-deploy スキルの概要

setup-deploy は gstack 向けのデプロイ設定スキルで、プロジェクトのデプロイメタデータを整え、今後の land-and-deploy 実行を自動で回せるようにします。特に、ざっくりした「これ、どうやってデプロイする？」という依頼を、再利用できるデプロイ設定に落とし込みたいエージェントや開発者に向いています。ターゲットのプラットフォームがまだ固まっていない場合にとくに有効です。

setup-deploy skill の主な役割は、実用的な情報収集です。デプロイ先プロバイダ、本番 URL、ヘルスチェックのエンドポイント、デプロイ状態の確認コマンドを特定し、その設定を CLAUDE.md に書き込みます。単なるプロンプトよりも役立つのは、毎回同じ質問を繰り返すのではなく、決定事項を残すことを前提にしているからです。

デプロイ設定作業に最適なケース

アプリはデプロイ可能だと分かっているものの、デプロイ経路を明確にして記録したいなら setup-deploy を使います。Fly.io、Render、Vercel、Netlify、Heroku、GitHub Actions、またはカスタムのデプロイフローに向いています。

何が違うのか

このスキルは、単なる助言ではなく設定の収集に主眼があります。デプロイの選択をプロジェクトの記憶に落とし込み、後続の自動化が正しい文脈で動けるようにするのが価値です。複数の環境があるリポジトリ、ステータスチェックが曖昧なケース、既存ファイルからデプロイ先を推測する必要があるケースでは、この違いが特に重要になります。

使わないほうがよいケース

サンプルアプリのデプロイ方法を一度だけ説明してほしいだけなら、通常のプロンプトで十分なことがあります。すでに完成度の高い安定したデプロイ仕様があり、設定を書き戻す必要がないなら、setup-deploy は構造化された情報収集以上の価値をあまり生みません。

setup-deploy スキルの使い方

正しいプロジェクト文脈でスキルを導入する

リポジトリの skill コマンドでインストールし、デプロイ設定を記録したいプロジェクト内で実行します。典型的な setup-deploy install の流れは次のとおりです。

npx skills add garrytan/gstack --skill setup-deploy

インストール後は、エージェントが CLAUDE.md を更新すべきアプリのリポジトリで動いていることを確認してください。スキルリポジトリ自体で実行してはいけません。

目的だけでなく、デプロイの事実を渡す

setup-deploy usage のパターンは、アプリの種類、現在のホスティング先、リリースやヘルスチェックについて既に分かっていることをプロンプトに含めたときに最も効果を発揮します。入力の良い例は次のようなものです。

• 「Render 上の Node API のデプロイを設定してください。本番 URL は https://api.example.com です。ヘルスエンドポイントは /health、ステータス確認コマンドは curl -f です。」
• 「Vercel 上の Next.js アプリのデプロイを設定してください。main ブランチを使い、CI で既に使っているデプロイ確認コマンドをドキュメント化してください。」

「デプロイを手伝って」のような弱い入力だと、スキルが推測しなければならない範囲が広すぎて、セットアップが遅くなります。

スキルファイルはこの順番で読む

まず SKILL.md を見て処理の流れを把握し、生成物の組み立て方を確認したい場合は SKILL.md.tmpl を参照します。このリポジトリには rules/、references/、resources/ フォルダがないため、中心となるスキルファイルが唯一の信頼できる情報源です。

スキルが想定しているワークフローで使う

setup-deploy guide は、まずプラットフォームを検出し、本番エンドポイントを確認し、デプロイのヘルス確認方法を確認してから、その結果を永続化するというシンプルな流れで進めるべきです。リポジトリに複数のデプロイ先候補があるなら、エージェントに推測させず、どれが正しいかを明示してください。確認ステップが明確なほど、誤ったプラットフォーム名やステータスコマンドが CLAUDE.md に残るリスクは下がります。

setup-deploy スキル FAQ

setup-deploy は完全なデプロイ自動化専用ですか？

いいえ。setup-deploy for Deployment の用途は自動化だけよりも広く、将来の実行に必要な最低限のデプロイ情報を確実に残しておくためにも使います。

先にホスティングプラットフォームを知っている必要がありますか？

必須ではありません。setup-deploy を導入する理由のひとつは、プロジェクトが Fly.io、Render、Vercel、Netlify、Heroku、GitHub Actions、あるいはカスタム経路のどれに当たるのかを見極める助けにすることです。すでにプラットフォームが分かっていれば、より速く、より正確に進められます。

通常のプロンプトより優れていますか？

多くの場合はそうです。目的がリポジトリにデプロイ設定を記録し、後続の deploy を再現可能にすることなら、特に有効です。通常のプロンプトでもデプロイの説明はできますが、setup-deploy skill は適切な入力を集めてプロジェクトの記憶に書き込むよう設計されています。

インストール前に何を確認すべきですか？

プロジェクトに既存のデプロイ慣例、CI のステータスチェック、保持すべき環境前提があるかを確認してください。そうした前提がなければ、このスキルは時間節約につながりやすくなります。逆に、すでに完全に標準化されているなら、重複になる可能性があります。

setup-deploy スキルを改善するには

具体的なデプロイ根拠をスキルに渡す

品質を最も大きく上げるのは、プラットフォーム名、本番 URL、ヘルスエンドポイント、ブランチ名、現在の deploy または status コマンドなど、正確な事実を渡すことです。ひとつ分からない項目があっても、分かっていることを伝え、残りはリポジトリから確認するよう依頼してください。

CLAUDE.md に書く前に曖昧さを解消する

最大の失敗パターンは、断片的な手がかりだけで誤ったターゲットを選ぶことです。リポジトリが複数の方法でデプロイできそうなら、vercel.json、render.yaml、GitHub Actions の workflow、既存の package.json スクリプトなど、どのシグナルを優先すべきかをスキルに明示してください。

最初の実行後に見直して改善する

最初の setup-deploy 実行後は、書き込まれた CLAUDE.md の項目を確認し、プラットフォーム名の食い違い、古い URL、一般的すぎる status check がないかをチェックしてください。設定が広すぎると感じたら、2 回目の実行で、保存したい具体的な service、environment、validation command を指定して絞り込みます。