all-deploy

all-deploy

プロジェクトを検出・監査し、プレビューから本番環境への確認済みのフローで適切なホストにデプロイします。独自の価値は、CLI をラップすることではなく、検出 → 監査 → 適切な CLI への振り分けです。

設定（デフォルトの動作を変更するには、これらの行を編集してください）

CONFIRMATION_MODE: ask_at_start
  # ask_at_start (default): the skill asks at the start of each cloud deploy
  #                         whether to run full-auto or step-by-step.
  # full_auto:              skip the question. Audit → preview → prod with a
  #                         5-second ESC window before prod.
  # always_ask:             skip the question. Require explicit "yes" before prod.
VISUAL_VERIFY: false           # true → screenshot preview via chrome-bridge-automation (frontend only)
ALLOW_DIRTY_TREE: false        # true → skip the "HEAD is clean" audit check

デフォルトの ask_at_start は、個人で開発する場合にもコミュニティで利用する場合にも適しています。モードの選択は実行時に行います。full_auto または always_ask に固定するのが有用なのは、対話形式で質問に答えられない自動化でこのスキルをラップする場合に限られます。

厳守事項（決して破らないでください — これが安全性を担保するルールです）

1. 監査を省略したり、緩和したりしてはいけません。 full_auto モードでは、監査だけがユーザーの意図と本番インフラの間にある唯一のゲートです。チェックを実行できない場合、それ自体がブロックの理由であり、省略する理由にはなりません。
2. 2xx/3xx のヘルスチェックに成功したプレビューを経ずに、本番環境へデプロイしてはいけません。 プレビュー → 概要 → 本番環境の順です。同じセッション内でプレビューが成功していなければ、本番環境へはデプロイしません。(一部の静的なターゲットにはプレビュー環境がありません。GitHub Pages やブラウザーからのアップロードなどです。その場合は、公開対象ディレクトリをそのまま python3 -m http.server でローカル実行し、同じ方法でヘルスチェックを行った成果物を成功したプレビューとします。ゲートは必須のままです。変わるのは配信場所だけです。)
3. シークレットをコミット、出力、ログ記録してはいけません。 追跡対象ファイルでシークレットが見つかった場合は停止し、削除と履歴の書き換えを別途ユーザーの承認を得て行うよう案内します。シークレットの値を概要、ログ、コミットメッセージに出してはいけません。
4. サードパーティー製 CLI を自動でインストールしたり、認証したりしてはいけません。 ! プレフィックス付きのコマンドをユーザーに提示してください（例：! vercel login、! railway login）。
5. フラグを隠すカスタムスクリプトで、ターゲットの CLI をラップしてはいけません。 リファレンスファイルには、ユーザーが読んで確認できる実際のコマンドを記載します。
6. 差分を先に提示せず、監査に通すためにコードを変更してはいけません。 .gitignore、.env.example、Dockerfile のひな形、ポートバインドの修正は、適用前にすべて提示し、承認を得てください。
7. ALLOW_DIRTY_TREE: true が設定されていない限り、作業ツリーが汚れた状態でデプロイしてはいけません。 コミットされていない変更があると、ロールバックが複雑になります。
8. 「待って」という指示を尊重してください。 プレビューから本番環境への間に、ためらいを示す表現（wait/hold/stop/not yet/abort など）がユーザーからあれば、本番環境への手順を適切に中止してください。

2 つのモード

ユーザーの表現から、最初にモードを判断します。

• クラウドデプロイ（デフォルト）— 以下のフェーズ 0〜6 を実行します。トリガー：「deploy」、「ship」、「push to prod」、「get it online」、「/all-deploy」。
• ローカル実行 — フェーズ 0、1、2 の後に、ローカル実行の手順を行います。トリガー：「run it locally」、「corre esto localmente」、「/all-deploy local」、「just run it」、または --local。

プロジェクトの分類（3 つ目のモードではなく、クラウドデプロイ内で決定）

クラウドデプロイには 2 種類あり、分類は検出によって決まり、ユーザーには尋ねません。

• app（デフォルト）— ランタイム、起動コマンド、ポートを持つサービスです。
• static — ウェブサイトです。ホストが CDN にコピーするファイルのフォルダーで構成されます。サーバー、ポート、ランタイムはありません。以下のフェーズ 0.0 で分類します。フェーズ 0、2、3.2、4、4.5、5、6 の内容が変わります。調整内容の全体については references/static-sites.md を参照してください。

ローカル実行モードでは、対象を絞った監査を行います。対象は、追跡対象ファイル内のシークレット、起動コマンドの有無、妥当なポートバインドのみです。git-remote、clean HEAD、npm audit/pip-audit、.env.example の完全性、環境変数の受け渡し（受け渡し先のリモートがないため）は省略します。その後、検出した起動コマンド（npm run dev / uvicorn main:app --reload --host 0.0.0.0 --port $PORT / docker compose up など）をフォアグラウンドで実行し、Monitor 経由で出力をストリーミングします。ローカルサーバーの公開も求められた場合は、references/targets/cloudflared-tunnel.md の手順に進みます。このファイルのその他の内容はすべて、クラウドデプロイに関するものです。

クラウドデプロイのワークフロー

モードの選択（ask_at_start モードでフェーズ 0 の前に実行）

この実行で有効な CONFIRMATION_MODE を決定します。

1. ユーザーの呼び出しに明示的なモードマーカーが含まれている場合は、そのモードを採用し、質問を省略します。

   • full_auto のトリガー：「auto」、「full auto」、「auto deploy」、「deploy auto」、「/all-deploy auto」、「yolo」。
   • always_ask のトリガー：「step」、「step by step」、「one at a time」、「confirm each step」、「paso a paso」、「/all-deploy step」。

2. それ以外の場合、上の設定ブロックで CONFIRMATION_MODE が full_auto または always_ask に固定されている場合は、その値を使用し、質問を省略します。

3. **それ以外の場合（デフォルトは ask_at_start）**は、フェーズ 0 の実行前に一度だけユーザーに質問します。

   「開始前に、デプロイの進め方を選んでください。

   1. 完全自動 — 監査 → プレビュー → 本番への昇格を順番に実行します。本番への反映は、5 秒間の ESC ウィンドウの後に実行されます。 2. ステップごと — 監査、プレビュー、本番の各段階で、承認を確認してから進みます。

   「auto」または「step」と返信してください。」

選択したモードは今回の実行にのみ適用されます。次回の呼び出しでは、ユーザーがトリガーフレーズで明示的に選択するか、設定ブロックでモードが固定されていない限り、再度質問します。

どちらのモードでも、いつでも「Wait」「stop」「hold」と指示すると、本番の手順は中止されます（ハードルール 8）。違いは、本番コマンドの実行前に 5 秒間の ESC ウィンドウ（full_auto）があるか、明示的な「yes」が必要な停止確認（always_ask）があるかです。

フェーズ 0.0 — プロジェクトの分類（前提条件の確認より先に実行）

ルートまたは dist/、_site/、public/、build/、out/、site/ 内に HTML ファイルがあり、かつルートに package.json、pyproject.toml、requirements.txt、Pipfile、Dockerfile、docker-compose.yml、Procfile、go.mod、Gemfile がない場合は、PROJECT_CLASS: static に設定します。それ以外の場合は PROJECT_CLASS: app に設定します。

マニフェストの確認により、index.html も含む Vite／Next／Astro リポジトリがアプリ向けのパイプラインで処理されます。static の場合は、ここで references/static-sites.md を読み込みます。以降のすべての処理は、そのフェーズ表に従います。

これは意図的にフェーズ 0 より前に実行します。先に前提条件を確認する方式では、不要な Git リモートがないという理由で HTML のフォルダーを不適切に除外していました。

フェーズ 0 — 前提条件（デプロイ先に依存しない）

次の順に確認します。いずれかに失敗した場合は、ユーザーが実行する ! コマンドを示して停止します。

1. Git リポジトリ。 git rev-parse --is-inside-work-tree を実行します。リポジトリでない場合は、モードが run locally（Git 不要）の場合、または PROJECT_CLASS: static の場合を除き、停止します。静的サイトは通常のフォルダーからデプロイできます。リポジトリがないことを伝え、続行します。判断はフェーズ 3.2 で行います。指示なしに git init を実行してはいけません。
2. Git リモート（クラウドデプロイのみ）。git remote -v を実行します。リモートが設定されていない場合は、デプロイ先がリモートなしでデプロイ可能な docker-vps である場合、または PROJECT_CLASS: static かつデプロイ先が GitHub Pages または Render 以外の場合を除き、停止します。Cloudflare Pages のダイレクトアップロードと Netlify Drop には、リポジトリが不要です。この 2 つ目の条件はフェーズ 3 の後で再評価します。
3. 言語の範囲。 v1 では Node と Python を判別します。主要言語が Go、Rust、Ruby、Elixir、Bun、Deno の場合は、次のメッセージを表示して終了します：「v1 は Node／Python エコシステムのみを検出します。デプロイ先の CLI（vercel、railway、flyctl、docker）を直接実行してください。この言語への対応は v2 で予定されています。」ただし PROJECT_CLASS: static の場合は適用されません。ビルド手順の有無にかかわらず、HTML／CSS／JS は常に対象です。

デプロイ先の CLI の認証は、デプロイ先の選択後、フェーズ 3.5（以下）で確認します。

フェーズ 0.5 — 権限プロンプトの初期設定（初回のみ）

ユーザーに次のように伝えます：「このプロジェクトで fewer-permission-prompts スキルを一度実行し、デプロイ許可リストを .claude/settings.json に設定してください。そうしないと、各手順で確認が求められます。」案内のみとし、ここではユーザーの設定を編集してはいけません。

フェーズ 1 — 検出

references/project-types.md（スキルからの相対パス。Claude はインストール済みのスキルディレクトリを基準に解決します）を読み、フィンガープリント表全体を確認します。次を調べます。

• パッケージマネージャーとマニフェスト： package.json、pnpm-lock.yaml、yarn.lock、package-lock.json、bun.lockb、pyproject.toml、requirements.txt、poetry.lock、uv.lock、Pipfile。
• フレームワークのシグナル： next.config.*、vite.config.*、astro.config.*、remix.config.*、nuxt.config.*、svelte.config.*、app/ と pages/ のどちらがあるか、FastAPI()、Flask()、app = FastAPI() を含む main.py、server.py、ルートにある index.html。
• ランタイムのバージョン： .nvmrc、.node-version、package.json の engines、.python-version、pyproject.toml の python_version。長時間稼働するターゲットを選択した際、ランタイムが固定されていない場合は、監査でブロックします。
• データベース／状態を保持する依存関係： sqlalchemy、psycopg、prisma、mongoose、redis、ioredis、sqlmodel のインポート。見つかった場合は、Railway のリファレンスにある Railway アドオンのコマンドとともに、「このサービスにはデータベースが必要です。本番環境の前にプロビジョニングしてください」 と通知します。
• ポートと起動コマンド： uvicorn、gunicorn、next start、node server.js、python -m ...。0.0.0.0 へのバインドと $PORT の使用を確認します。長時間稼働するターゲットで localhost のみにバインドしている場合はブロックします。
• モノレポ： pnpm-workspace.yaml、turbo.json、nx.json、lerna.json、またはルートの package.json にある "workspaces" → パッケージを列挙し、どれをデプロイするかユーザーに確認します。推測してはいけません。
• ライブラリ／CLI（Web デプロイではないもの）： Node のシグナル — package.json に bin: フィールドがある、または（files: 配列があり、scripts.start がなく、express、fastify、hono、next、koa などの HTTP フレームワークのインポートがない）。Python のシグナル — pyproject.toml に [project.scripts]／console_scripts があり、宣言されたスクリプトやインポートに uvicorn／gunicorn／flask／fastapi がない。main: だけをライブラリのシグナルとして使ってはいけません — Node の Web アプリのほとんどが main: も設定しています。次のメッセージを表示して正常終了します。「これはパッケージのようです — /all-deploy の対象は Web サービスであり、npm／PyPI への公開ではありません。」
• 既存のデプロイ設定： vercel.json、railway.toml、fly.toml、Dockerfile、render.yaml — 既存の設定を尊重して監査し、明示的に求められない限り再生成しません。
• 既存のプロジェクト連携： .vercel/project.json → その Vercel プロジェクト ID を再利用します。project フィールドを含む railway.toml → 既存の設定を再利用します。再デプロイが一般的なケースです。新規プロジェクトの作成には、明示的な「最初から始める」という指示が必要です。

PROJECT_CLASS: static の場合、 フレームワーク／ランタイム／ポート／データベース／モノレポのフィンガープリント確認は省略します。検出するのは次の 3 点だけです。index.html があるフォルダーである公開ディレクトリ（.、dist/、_site/、public/、build/、out/、site/）、ビルド手順の有無、Git リポジトリの有無です。公開ディレクトリの表は references/static-sites.md にあります。ここを誤ると、公開後のサイトが / で 404 を返すことが最もよく起こります。

出力：分類ブロックと、候補ターゲットを理由を 1 行ずつ添えて優先順位順に並べたリスト。ターゲットの優先順位付けルール全体については、references/project-types.md を参照してください。

フェーズ 2 — 監査（厳格、ブロッキング）

このスキルに同梱されている監査スクリプト（scripts/audit.py）を、現在のプロジェクトディレクトリに対して実行します。Claude はスキルの読み込み時にスキルのパスを解決します。呼び出し方は次のとおりです。

python3 <SKILL_DIR>/scripts/audit.py <project-path>

PROJECT_CLASS: static の場合：

python3 <SKILL_DIR>/scripts/audit.py <project-path> --profile static --publish-dir <dir> [--target <name>]

依存関係ツリー、起動コマンド、ポート、Git リモートを前提とするチェックはすべてスキップされます。HTML だけの単純なフォルダーでは重大な問題と誤判定されるためです。代わりに scripts/static_check.py を実行します。選択したデプロイ先が GitHub Pages の場合は、--target github-pages を指定してください。リモートが実際に必要な唯一の静的デプロイ先であり、.nojekyll とルート相対パスが問題になる唯一のデプロイ先です。チェック項目は references/static-sites.md に記載されています。

<SKILL_DIR> はスキルのインストール先（通常は ~/.claude/skills/all-deploy/）、<project-path> は通常 . です。このスクリプトは references/audit-checklist.md のすべての項目を確認します。追跡対象ファイル内のシークレット、.gitignore の適用範囲、ロックファイルの妥当性、.env.example の完全性（scripts/env_extract.py を使用）、ビルド／起動スクリプトの有無、ポートのバインド、HEAD のクリーンさ、Git リモートの一致、npm audit --production --audit-level=high または pip-audit を確認します。

問題が一つでもあれば停止します。問題ごとに、該当する場合は修正内容を差分として提示し、適用前にユーザーの OK を待ちます。自動モードでも監査は省略されません。

Git 履歴内のシークレットスキャンは自動ではなく、ユーザーが実行します。監査結果では、trufflehog git file://. または git log -p -S 'sk_' -S 'AKIA' -S 'ghp_' を別の手順として提示してください。このスキルが Git 履歴を書き換えることはありません。

フェーズ 3 — デプロイ先の選択

フェーズ 1 で選ばれた候補を、理由を一行添えて優先順位順に提示します。ユーザーが選ぶか、「ok」と答えて最上位の候補を受け入れます。その後で初めて、対象のリファレンスを読み込みます。

• references/targets/vercel.md — Next、Vite、Astro、Remix、Nuxt、SvelteKit、静的サイト
• references/targets/railway.md — FastAPI、Flask、Express、Python ワーカー、MCP HTTP、Claude Agent SDK
• references/targets/docker-vps.md — Dockerfile があるプロジェクト全般、ステートフルなワークロード、セルフホスト可能
• references/targets/cloudflared-tunnel.md — ローカル開発環境の公開、簡易デモ
• references/targets/cloudflare-pages.md — 静的サイト。誰かが報酬を得ている場合のデフォルト候補
• references/targets/netlify.md — フォームが必要な静的サイト、ドラッグ＆ドロップ
• references/targets/github-pages.md — すでに GitHub にあるポートフォリオ、ドキュメント、デモ
• references/targets/render.md — 静的サイト、低トラフィック

PROJECT_CLASS: static の場合は、候補を提示する前に references/static-hosting.md を読み込みます。ここには比較、無料プランの制限、商用利用のマトリックス、そして順位を決める実際の質問が記載されています。「このページに関連して、誰かが報酬を得ていますか？」「はい」の場合は、Vercel Hobby（Fair Use 条項では「サイトの作成、更新、ホスティングに対する報酬の受け取り」は商用利用にあたります）を候補から外し、通常は GitHub Pages も候補から外します。

エージェントに関係するプロジェクトでは、エージェントの種類ごとの調整内容（FastAPI／Flask HTTP、MCP stdio と HTTP、Claude Agent SDK スクリプト、汎用 Python ワーカー）を確認するために、references/agents.md も読み込みます。

フェーズ 3.2 — Git の判断（静的クラス、リポジトリなし）

PROJECT_CLASS: static で Git リポジトリがない場合に限ります。選択できるデプロイ先が決まるため、結果を添えて一度だけ尋ねます。

「変更をプッシュして、後でページを更新できるようにしますか？ それとも今回限りですか？」

• 更新をプッシュしたい場合 → リポジトリが必要です。git init -b main、git add -A && git commit -m "Initial site"、gh repo create <NAME> --public --source=. --push を提示します。最後のコマンドを実行する前に確認してください。コードがユーザーの GitHub アカウントで公開されます。gh が認証されていない場合は、! gh auth login を提示して待ちます（ハードルール 4）。
• 今回限り、または GitHub アカウントがない場合 → Cloudflare Pages の直接アップロードまたは Netlify Drop に案内し、後で更新するにはフォルダーを再度アップロードする必要があることを明確に伝えます。公開後に初めてそれに気づくことがないようにしてください。

フェーズ 3.5 — 対象の CLI がインストールされ、認証済みであることを確認

対象を選んだら、その CLI がインストールされ、認証済みであることを確認します。自動インストールや自動ログインはせず、ユーザーに ! を付けたコマンドを提示します。

• Vercel: vercel whoami（インストール：npm i -g vercel、ログイン：! vercel login）。
• Railway: railway whoami（インストール：npm i -g @railway/cli または brew install railway、ログイン：! railway login）。
• Docker + SSH: ssh -o BatchMode=yes <host> true（SSH キーの事前設定が必要です）；ローカルで docker --version を実行します。
• cloudflared: cloudflared tunnel list（インストール：brew install cloudflared、ログイン：! cloudflared tunnel login）。
• Cloudflare Pages: npx wrangler whoami（インストール：! npm i -D wrangler@latest、ログイン：! npx wrangler login）。
• Netlify: netlify status（インストール：! npm install -g netlify-cli、ログイン：! netlify login）。
• GitHub Pages: gh auth status（インストール：! brew install gh、ログイン：! gh auth login）。
• Render: ダッシュボードまたは render.yaml を使用します。CLI（render login）は任意であり、静的サイトの作成には未検証です。

確認に失敗した場合は停止し、インストール／ログインコマンドを提示します。ユーザーから完了の報告があったら、フェーズ 3.5 から再開します。

CLI を使わない場合（静的クラス）。 何もインストールしないでください（絶対ルール 4）。PROJECT_CLASS: static で対象の CLI が PATH にない場合は、2 つの方法を提示してユーザーに選んでもらいます。ブラウザーを使う方法をデフォルトの推奨として提示してください。

1. 自分でインストールする — ! を付けたコマンドはこちらです。
2. ブラウザーを使う — 公開用フォルダーを Cloudflare Pages（Workers & Pages → Create → Pages → Upload assets）または Netlify Drop にドラッグするか、github.com にアップロードします（Add file → Upload files、続いて Settings → Pages）。

Render 以外のすべての静的ターゲットには、ブラウザーで完結する方法があります。ターミナルが使えない人も作業を続けられます。その場合は方法 2 を選んでください。

フェーズ 4 — 実行（必ず最初にプレビュー）＋環境変数の受け渡し

対象のリファレンスにあるプレビュー手順に従ってください。最初の実行は必ずプレビュー／ステージングとし、このフェーズでは絶対に --prod を使わないでください。

長時間実行コマンドの処理。 デプロイコマンドの実行には 3〜10 分かかるため、Bash のデフォルトのタイムアウト（2 分）では処理が強制終了されます。

• 標準の方法： Bash ツールで run_in_background: true を指定してデプロイコマンドを実行します。CLI が終了すると完了通知が届くので、その時点で Bash の出力ファイルを Read して URL を確認し、エラーを検出します。sleep を使ったループを連結しないでください。
• 途中の行を早めに確認したい場合（例：Railway が実行中にプレビュー URL を表示する場合、cloudflared が安定する前にトンネル URL を表示する場合）：同じ出力ファイルを対象に、URL パターンと既知のエラー表記（Traceback、FAILED、error:）に一致する正規表現を指定して Monitor ツールを使います。一致するたびに通知が届きます。最初に一致した URL がフェーズ 4.5 でプローブされます。

環境変数の受け渡し（プレビューの実行前）。正しい値の参照元はユーザーのローカル .env です（コミットはしません）。必要なキーを対象環境に設定します。

• Vercel： vercel env add <KEY> preview、続けて vercel env add <KEY> production を実行します（値を貼り付けるか、パイプで渡します。例：echo -n "$value" | vercel env add <KEY> <env>）。vercel env ls で確認します。
• Railway： railway variables --set "KEY=value" をキーごとに 1 回実行します。一括インポート用のフラグはありません。ローカルの .env をシェルでループ処理してください（references/targets/railway.md を参照）。
• Docker+SSH： scp .env.production user@host:/app/.env を実行するか、docker-compose.yml の environment: ブロックを使います。
• cloudflared： ローカル環境を引き継ぐため、リモート側の変数は不要です。
• 静的サイトのホスティング（Cloudflare Pages、Netlify、GitHub Pages、Render、Vercel static）： このフェーズはスキップし、その理由を伝えてください。 公開ディレクトリ内のものはすべて一般公開されます。ビルド時の変数（VITE_*、PUBLIC_*、NEXT_PUBLIC_*）はビルド時に JavaScript バンドルへ埋め込まれます。リポジトリがプライベートでも役に立ちません。配信されるのはリポジトリではないからです。「環境変数に設定すれば秘密を保てます」とは決して提案しないでください。 静的サイトではこの説明は誤りです。正当な例外は、公開を前提としたキー（Stripe の pk_、リファラー制限付きの Google Maps キー）と、公開されるビルド時の値です。これらはデプロイし、公開されることを明確に伝えてください。それ以外はサーバーが必要です。その旨を伝え、アプリのパイプラインに切り替えてください。詳細は references/static-sites.md を参照してください。

値は絶対に出力しないでください。キーのみを確認してください。

フェーズ 4.5 — プレビューのヘルスチェック（必須）

デプロイ CLI の標準出力からプレビュー URL を取得します。各ターゲットのリファレンスに、正確な解析手順が記載されています。例：

• Vercel： プレビュー URL は、標準出力の最後の空でない行に https://<project>-<hash>-<scope>.vercel.app の形式で出力されます。
• Railway： railway up の出力から Deployment live at <url> を探します。
• Docker+SSH： URL はユーザーが設定した http://<host>[:port] です。スキルは docker-compose.yml のポートマッピングを確認するか、ユーザーに尋ねる必要があります。
• cloudflared： URL は https://<random>.trycloudflare.com または設定済みのホスト名として出力されます。

取得した URL を $PREVIEW_URL に代入し、次のコマンドで確認します：

curl -sSL -o /dev/null -w "%{http_code}" "$PREVIEW_URL"

（-f は指定しません。指定すると、HTTP エラー時に %{http_code} の出力が抑制されます。-sSL を指定すると、成功時は curl の出力を抑えつつ、転送エラーを表示し、リダイレクトを追跡できます。）

静的クラス — エントリーページが参照する最初のスタイルシートも確認します：

curl -sSL -o /dev/null -w "%{http_code}" "$PREVIEW_URL/<first-stylesheet-href>"

/ が 200 で /estilo.css が 404 になるのは、本番環境でファイル名の大文字・小文字の誤りが起きた場合の典型例です。ルートへのプローブだけでは、そのデプロイは正常と判定されてしまいます。

2xx または 3xx のステータスならフェーズ 5 に進みます。4xx/5xx、出力が空（接続拒否、DNS 解決失敗）、または curl の終了コードが 0 以外の場合は停止します。ターゲットのログコマンド（vercel logs、railway logs、ssh ... 'docker compose logs'）で失敗したエンドポイントを報告します。先には進みません。

任意のビジュアル確認。 VISUAL_VERIFY: true で、プロジェクトがフロントエンドの場合は、chrome-bridge-automation を使用してプレビューのスクリーンショットを撮影し、ページが表示されること（空白でもエラーページでもないこと）を確認します。ゲートとなる条件は引き続き curl の 2xx/3xx です。スクリーンショットは追加確認です。

フェーズ 5 — 本番環境への昇格

full_auto モードでは、監査とプレビューのヘルスチェックの両方に合格した後、次の手順を実行します：

1. 1 画面に収まる要約ブロックを表示します。対象 URL、これから実行するコマンドの正確な内容、DNS への影響（ある場合）、費用への影響を記載します。料金については、最新の Vercel/Railway 料金を deep-research で調査することを優先します。利用できない場合は、プロバイダーの料金ページへのリンクを記載します。このファイルにプラン料金をハードコードしないでください。
2. 「5 秒後に本番環境へ昇格します — 中断するには ESC を押してください。」 と表示します。その後、Bash ツールで sleep 5 を独立した呼び出しとして実行します。これは形式だけの手順ではありません。スリープ中に ESC を押すと、実際にターンが停止します。ユーザーが中断した場合、再開時に本番コマンドを実行せず、代わりにどうしたいかを尋ねてください。
3. スリープがエラーなく終了した後、本番コマンドを run_in_background: true を指定して別の Bash 呼び出しとして実行します。完了通知を待ってから、Bash の出力ファイルを Read して本番 URL を抽出します。CLI の終了前に URL を解析する必要がある場合（Railway、cloudflared）に限り、同じ出力ファイルに対して Monitor を使用します。

always_ask モードでは、手順 2～3 を省略し、本番コマンドを実行する前に同じターン内で明示的な「はい」を求めます。スリープは行いません。

静的クラス — プレビューから本番環境への昇格がないターゲット。 Cloudflare Pages（--branch）と Netlify（--prod）は通常どおり動作します。次の 3 つは異なります：

ターゲット	実際の動作
Vercel	保留します — ただし、新規プロジェクトへの初回デプロイは、--prod なしでも必ず本番環境になります。このことを実行前に伝えてください
GitHub Pages	1 つのブランチにつき 1 つのサイトです。プレビューはありません
Direct upload / Netlify Drop	アップロードがそのまま本番環境になります

最後の 2 つについては、公開対象の正確なディレクトリをローカルで配信してヘルスチェックを行い、ハードルール 2 を満たします。インストールは不要で、Python に同梱されています：

python3 -m http.server -d <PUBLISH_DIR> 8000
curl -sSL -o /dev/null -w "%{http_code}" http://localhost:8000

プロジェクトのルートではなく、公開対象のディレクトリを配信します。ルートを配信すると、これを検出するための「フォルダーの指定間違い」というバグが隠れてしまいます。その後、通常の確認を経て一度だけ公開します。

プレビュー後の中断を尊重します。 プレビューから本番環境への昇格までの間に、ユーザーがためらいを示す言葉（「待って」「保留」「停止」「まだ」「中止」など）を入力した場合は、本番環境への昇格を進めないでください。プレビューを最後の正常な状態として扱い、明示的な指示を待ちます。

フェーズ 6 — デプロイ後の確認とロールバック方法の提示

• 本番 URL に curl し、ステータスを確認します。
• リモート環境に環境変数が設定されていることを確認します（vercel env ls、railway variables、ssh ... 'docker compose config'）。
• このターゲットのロールバック手順を表示します（ユーザーが後で必要に応じてコピーできるようにします）。
  • Vercel：vercel rollback（対話型ピッカー）または vercel rollback <previous-deployment-url> — 現在の CLI 構文を確認してください。
  • Railway：専用の rollback コマンドはありません。以前のコミットを再デプロイします：git checkout <prev-sha> && railway up && git checkout -。または、ダッシュボードの Deployments → 以前のビルドにある「Redeploy」を使います。
  • Docker+SSH：以前のイメージに再タグ付けしてから ssh <host> 'docker compose up -d --no-deps <service>' を実行するか、以前の SHA を再度 rsync してビルドします。両方の手順については references/targets/docker-vps.md を参照してください。
• ログ末尾を表示するコマンドを表示します：vercel logs <url> --follow、railway logs --follow、ssh <host> 'cd /app && docker compose logs -f'。

静的サイトの分類。 この場合、ロールバックよりも、ユーザーが実際に尋ねる「後でどうやって変更するのか」のほうが重要です。両方を説明してください。Cloudflare Pages と Netlify は、ダッシュボードから以前のデプロイにロールバックできます（どちらにも CLI コマンドはありません）。GitHub Pages は git revert <sha> && git push でロールバックします。直接アップロードまたは Drop には、以前のフォルダーを再アップロードする以外にロールバック方法がありません。そのため、公開前にコピーを保管するようユーザーに伝えてください。 カスタムドメインを希望する場合は references/custom-domain.md を案内し、ホスティングは無料ですがドメインは無料ではない（年間約 $10～15 USD）ことを明確にしてください。

ターゲット選定 — ランキング基準（クイックリファレンス）

プロジェクトの特徴	第一候補	理由
HTML/CSS/JS だけのフォルダー、クライアントのページ、または有償案件	Cloudflare Pages	無料、商用利用の制限なし、デプロイクレジットの急な上限到達なし
お問い合わせフォームが必要な静的サイト、バックエンドなし	Netlify	Netlify Forms は無料です。300 クレジットの上限に注意してください
すでに GitHub にあるポートフォリオ、ドキュメント、デモ	GitHub Pages	新しいアカウントは不要。ストアフロントには適しません（商用利用の制限あり）
トラフィックが少なく、すでに Render を使っている静的サイト	Render	その規模なら問題ありません。無料枠は月 5 GB です
next.config.*、vite.config.*、astro.config.*、SPA、SSG	Vercel	設定不要、プレビュー URL、エッジネットワーク。Hobby は非商用利用のみ
FastAPI / Flask / Express を使った長時間稼働のサーバー	Railway	シンプルでデプロイが速く、データベースのアドオンも利用可能
Dockerfile が存在する、データベース／ボリュームが必要、セルフホストを希望	Docker + SSH VPS	完全な制御が可能で、ステートフルな構成に適しています
ローカル開発環境が稼働中で、すぐに公開 URL が欲しい	cloudflared tunnel	ホスト不要ですぐに利用可能
MCP サーバー	Railway（HTTP モード）または Docker+SSH	references/agents.md を参照してください
Claude Agent SDK スクリプト	Railway（ワーカーモード）または cron	references/agents.md を参照してください

特徴が一致しない場合は、理由とともに上位 2 つを提示し、ユーザーに選んでもらいます。

バンドルされているリソース

• scripts/audit.py — デプロイ前に実行する決定的な監査です。フェーズ 2 で実行されます。
• scripts/env_extract.py — ソースコード内の環境変数の使用状況をスキャンします。監査で .env.example の網羅性を確認するために使用されます。
• scripts/static_check.py — 静的サイトのチェックです。audit.py --profile static から実行されるほか、単独でも実行できます。
• references/project-types.md — フレームワークの完全なフィンガープリント表です。
• references/audit-checklist.md — すべての監査ルールを、修正方法の説明とともにまとめています。
• references/env-mapping.md — ローカルの .env から各デプロイ先へ環境変数を移す方法を説明しています。
• references/agents.md — 4 種類のエージェント構成と、種類ごとのデプロイ調整について説明しています。
• references/static-sites.md — 静的プロジェクトの分類、公開ディレクトリ、フェーズごとの調整、静的サイトのチェックについて説明しています。
• references/static-hosting.md — 商用利用の可否を示す表を含め、5 つの無料静的ホスティングサービスを比較しています。
• references/custom-domain.md — ホストごとの DNS レコード、ルートドメインと www の違い、待機中に想定される状況について説明しています。
• references/targets/*.md — デプロイ先ごとのプレイブックです。フェーズ 3 の後にのみ読み込まれます。
• assets/templates/ — Dockerfile.node、Dockerfile.python、docker-compose.example.yml、.env.example.template が含まれています。

プラットフォームに関する注意事項

• v1 では macOS と Linux のみ対応しています。 Windows を利用するコミュニティメンバーは、パスとシェルの互換性を確保するために WSL2 を使用してください。
• すべてのコマンドは bash/zsh を前提としています。パスには POSIX の規則を使用します。
• すべてのクラウドモードではネットワーク接続が必要です。「ローカルで実行」モードはオフラインで動作します。