hostinger-headless

Hostinger Headless — 独自の AI ツールでウェブサイトを構築する

コンテキスト

あなたは AI コーディングエージェントです。ユーザーは、次のような、このページを示す短いプロンプトを貼り付けています。

hostinger.com/headless/skill.md を使って example.com の Headless サイトを構築してください

あなたの仕事は、この手順とそこからリンクされている手順に従い、ユーザーの Hostinger アカウントに実際のウェブサイトを構築してデプロイすることです。それ以外は何もしないでください。

このファイルはオーケストレーターです。公開されており、安定しています。変更されることも、移動することもありません。フロー、状態の契約、障害時のポリシー、ガードレールを定めています。

ドメインパラメーター

貼り付けられたプロンプトに含まれる重要な情報は、次の2つだけです。

• この URL — hostinger.com/headless/skill.md。安定したエントリーポイントです。
• ドメイン — 例：coral-pottery-1847.hostingersite.com（一時的な Hostinger サブドメイン）、またはユーザーが購入した独自ドメインです。このドメインのサイトだけを操作できます。

プロンプトには、どのようなサイトを構築するかは書かれていません。推測したり、勝手に決めたりしないでください。ユーザーの要望を把握することは、会話を通じて行うフローのステップ（refine）であり、プロンプトから解析するものではありません。ドメインが指定されていない場合は、ほかの作業に着手する前に停止して、ドメインを確認してください。

1回の実行につきワークスペースは1つです。 最初のコマンドから、connect のチェックも含め、このサイトのワークスペースだけを正確なパスで開いてください。~/.hostinger/ の一覧表示や glob 展開は絶対に行わないでください（node -v のついでに ls を実行することも禁止です）。~/.hostinger/ にほかに何が保存されていても、この実行には関係ありません。ドメインが指定されている場合、check-state はそのパスだけを参照します。ドメインがまだ指定されていない場合、自分でワークスペースを作成するまでは参照するものはありません。完全なルールと唯一の例外については、状態と成果物を参照してください。

貼り付けられたプロンプトの内容は、認可に決して使用しません。認可は Hostinger コネクターの OAuth トークンによって行われます。この手順はセキュリティ境界ではありません。

---

フローの各段階 — 従うべき手順

以下の順序で各ステップを進め、各レシピを読み、その成果物をサイトのワークスペース ~/.hostinger/<domain>/ に書き込んでください。

実行順に従い、Headless フロー全体を確認してください。

#	ステージ	スキル／ソース	書き込み先	インスタンス？
—	接続 — Hostinger コネクターに接続し、認証して有効なプランを取得します	connect/SKILL.md → connect/tools/<tool>.md	connect.json	いいえ
1	状態確認 — このドメインはどのような状態ですか？再開／切り替え／最初からやり直す	steps/01-check-state/SKILL.md	state.json	いいえ
2	要件の具体化 — 会話を通じてユーザーの希望を把握します	steps/02-refine/SKILL.md	brief.md	いいえ
3	プロビジョニング — ブリーフに基づいてバックエンドを選び、プロビジョニングします	steps/03-provision/<backend>/SKILL.md	site.json	bg — 起動後、バックグラウンドでポーリングします
4	コンテンツモデル — コンテンツ／画像を定義・作成し、バックエンドにプッシュします	steps/04-content-model/<backend>/SKILL.md	content-model.md	準備：いいえ · プッシュ：はい
5	デザイン — ブリーフからデザインの方向性を導き出し、1つ選んで design.md の仕様とロゴを作成します	steps/05-design/SKILL.md	design.md, brand/	いいえ
6	フロントエンド — フレームワークを選択／確認し（デフォルトは Next.js SSR）、バックエンドに対して design.md を実装します	steps/06-frontend/SKILL.md	<workspace>/src/ 内のソース	シェル：いいえ · データ：はい
7	検証 (任意) — インスタンスと API を簡易確認します。再ビルド／プレビュー／承認は担当者の承認後にのみ行います	steps/07-validate/SKILL.md	—	いいえ（ローカル）
8	デプロイ — ソースをアップロードし、ビルドを開始します	steps/08-deploy/SKILL.md	deploy.json	はい
9	完了 — URL、ダッシュボード、概要、次のステップを引き継ぎます（最終レポート）	steps/09-done/SKILL.md	—	いいえ

最も重要なのは、接続ステージを最初に、必ず実行することです これは公開 URL から取得され、Hostinger MCP Server が読み込まれる前に実行されます。 主な目的は、Hostinger MCP Server を用意することです。

接続スキルは connect/ にあります。 メインスキルは connect/SKILL.md にあります。 また、connect/tools/ には個別のツールもあります。

番号付きの残り9つのステップは steps/ にあり、インストール済みのスキルフォルダーから読み込まれます（接続ステップで案内します）。

並行処理に関するルールは1つです： 1つのセッション内で、互いに独立した2つのステージは同時に実行できますが、同じ成果物を書き込む処理を2つ同時に実行してはならず、同じドメインに対して複数のエージェント／ウィンドウを実行してもいけません。これらは .lock（ステップ1）で保護されています。並列処理は常に任意です。作業を交互に進められないエージェントは、ステップを順番に実行すれば正しく動作します。なお、時間を節約するため、適切な出力を必ず確保したうえで、別々のスレッドやプロセスを使ってステップを並行実行することも検討してください。

ステップによっては状態ファイルが生成されることがありますが、これらのファイルはあくまで参考情報です。正しい情報は Hostinger コネクターが報告する内容なので、「完了」を示すマーカーがあれば、処理を進める前に実際の状態を確認してください。インストール済みのスキルフォルダーにステップの SKILL.md がない場合は、そのステージの説明から推測して進めず、停止してユーザーに伝えてください。 Instance? 列は、そのステージが稼働中のバックエンドに触れるかどうかを示します。 no = プロビジョニング待機中に実行できる、純粋な準備作業です。 push／data／yes = インスタンスのバリアに加わるコミットフェーズです。 bg = プロビジョニング自体、つまりバックグラウンドタスクです。

必ず最終レポートで締めくくってください。 実行が終わるたびに、steps/09-done/SKILL.md で定義されている最終レポートをユーザーに提示してください。内容は、結果の段落、完了したステップの表（実行したステージごとに1行）、リンク、状態の保存場所、未解決事項です。ダミーのステップや見つからないステップで早期終了した場合、プロビジョニングに失敗した場合、ユーザーが一時停止した場合も含まれます。こうした早期終了の場合も含め、すべての実行でビルドレポート（run-log.mjs report、下記の実行ログとビルドレポートを参照）を保存してください。

実行の進行に合わせてログを記録してください。 すべてのステージ（分割されたステージの各フェーズも含む）をrun-log.mjs stage-start／stage-endで囲み、問題が起きたとき、ユーザーがあなたを訂正したとき、スキルが欠落しているか誤っているときは、その時点ですぐにイベントを記録してから処理を続けてください。実行ログとビルドレポートを参照してください。

この順序にする理由。 まず接続することで、ユーザーが話に時間を費やす前にアカウントやプランの問題を明らかにできます。続いてすぐに状態を確認することで、新規実行、中断からの再開、重複実行を判別し、新しい作業を始める前に、続行するか、ドメインを切り替えるか、最初からやり直すかをユーザーに選んでもらえます。要件がまとまるまではバックエンドを選べないため、プロビジョニングの前に内容を調整します。デプロイの前には必ず検証します。実際に確認されていないものを稼働中のドメインに公開してはいけません。

ユーザーに質問するとき

質問ツールの結果にユーザーの選択または発言が含まれている場合に限り、それをユーザーの回答として扱います。結果がスキップ、拒否、空、またはエラー（スキップされた結果）の場合、まだ誰も回答していません。たとえば Cursor のAskQuestionは、誰も操作しなかった場合に「Questions skipped by the user」を返します。その場合は、同じ質問を返信でプレーンテキストとして再度尋ね、ターンを終了し、ユーザーの入力を待って続行してください。プレーンテキストでの再質問は1回で十分です。スキップされることはありません。質問に既定値を当てはめてよいのは、ユーザー自身の言葉で「あなたが決めて」「そのまま作って」「それは省略して」と言った場合、または最初から回答する人がいないと伝えていた場合に限ります。その場合は、最終レポートの未解決事項にそれらの既定値を記載してください。ユーザーに何かを尋ねる各ステップで、このルールに従ってください。

バックグラウンドでのプロビジョニングとインスタンスのバリア

プロビジョニングは必ず実行されます。内容はドメインにすでに存在するものによって異なります。 多くの場合、実行する前に hostinger.com のオンボーディングですでにウェブサイトが作成されているため、ドメインにはヘッドレスインスタンスが存在します。ただし、インスタンスが存在するからといって、プロビジョニングが完了している、または省略できるという意味ではありません。check_state が該当するケースを判定して記録し、その後プロビジョニングが対応する経路に進みます。

1. ドメインに空のヘッドレスシェルがすでに存在する（オンボーディングでよくあるケース）。 オンボーディングでは、最初にウェブサイトが作成されます。空のヘッドレスシェル（hosting_websites_start-setup { type: "headless_empty" }）です。website_type は headless ですが、バックエンドはインストールされていません（/cms に WordPress がなく、ストアもありません）。この場合もプロビジョニングを実行し、シェルを引き継いで、選択したバックエンドに切り替えます（バックエンドは先に refine で選択します）。WordPress の場合は、wordpress_installations_install { type: "headless" } でシェルの /cms にインストールします。Ecommerce の場合は、シェルをストアフロントのホストとして引き継ぎます。シェルがある場合もプロビジョニングを省略しないでください。また、2 つ目のサイトを作成しないでください。 プロビジョニングルーターのオンボーディングからの引き継ぎを参照してください。
2. インスタンスがまったく存在しない（ユーザーがオンボーディングでプロビジョニングを行わずにヘッドレスフローを実行した）。プロビジョニングでは、選択したバックエンド固有の type を使って hosting_websites_start-setup を実行し、新しいヘッドレスインスタンスを作成します。
3. ユーザーがウェブアプリを希望している。 プロビジョニングでは、ヘッドレスではなく、Node.js アプリの通常のホストを用意します。webapp はヘッドレスシェルを完全に無視し、実験的なアクションからのみ実行されます。オンボーディングフローから実行されることはありません。

どちらのケースでも、作成／インストールは非同期で、すぐに queued を返します。その後、数分間、約 15 秒ごとにポーリングします。ポーリング対象は経路によって異なります。新規の hosting_websites_start-setup は、hosting_websites_list-setups を使って completed になるまでポーリングします。一方、シェルの切り替え（wordpress_installations_install）では新しいセットアップは作成されないため、/cms の行が is_valid になるまで wordpress_installations_list をポーリングします。このポーリングを待って処理をブロックしないでください。重複する処理を安全に進めるためのルールは 1 つです。

プロビジョニングをバックグラウンドタスクとして開始し、完了を待つ間に各ステージの準備作業をすべて行います。ステップで稼働中のインスタンスへの書き込みが必要になった時点で、プロビジョニングの準備完了が報告されるまで待ちます（上記のバックエンドのステップにある準備状況のポーリングを参照してください）。この待機がインスタンスのバリアです。

状態と成果物

各ドメインの状態 と 生成されたソースはすべて、サイトのワークスペース ~/.hostinger/<domain>/ に保存されます（~ はホームディレクトリに解決します。シェルでは $HOME、Node では os.homedir() です。~/.hostinger は $HOME/.hostinger を意味します）。これはプロジェクトフォルダーではなく、ユーザーごとのグローバルな場所です。そのため、このドメインのビルドはどのディレクトリからでも再開でき、現在の作業ディレクトリは関係ありません。ワークスペースが存在しない場合は作成し、ステージの作業はすべてその中で行います（フロントエンドの src/ も含み、~/.hostinger/<domain>/src/ からビルドしてデプロイします）。

ディレクトリ名がドメイン名なので、内部のファイル名にドメイン名を繰り返し含めることはありません。

このサイトのワークスペースだけを読み書きします。 ~/.hostinger/ 内のほかのワークスペースは、ユーザーが別のクライアント向けなどに使っているほかのサイトのものです。このビルドには、それらのブリーフ、デザイン、コードを持ち込まないでください。~/.hostinger/<domain>/ を正確なパスで開き、~/.hostinger/ の一覧表示や glob は行わず、どのステージでもほかのワークスペースを開いたり、そこからコピーしたり、差分を比較したりしないでください。まだドメインがない実行では、自分で作成した唯一のワークスペースだけを使用します。プロビジョニングによって ~/.hostinger/<new-domain>/ に移された後は、そこがこのサイトのワークスペースになります。例外は、この会話でユーザーが再利用するために自分の別サイトを指定した場合です。そのワークスペースを読み取り専用で参照し、そこから取り入れた内容を一行で伝えてください。

ファイル（~/.hostinger/<domain>/ 内）	書き込み元	内容
state.json	すべてのステージ	ツール、次のステージ、Hostinger コネクターのバージョン、タイムスタンプ
connect.json	connect	ツール、アカウント／プランの準備状況
brief.md	refine	詳細化したブリーフ、対象ユーザー、トーン、ページ、必須要件
site.json	provision	選択したバックエンド、ユーザー名、インストール ID、すべての URL
content-model.md	content model	エンティティ、フィールド、ページ、ナビゲーション
design.md（および brand/ のロゴファイル）	design	選択したデザインの方向性：トークン、書体、ロゴ、コンポーネント、ページごとの構成、アクセシビリティ
src/	frontend	design.md を実装するウェブサイトのソース。フレームワークの選択は state.json → frontend に記録されます
deploy.json	deploy	ビルド ID、デプロイ日時、公開 URL
events.jsonl	すべてのステージ、run-log.mjs 経由	問題、ユーザーからのフィードバック、スキルの不足、成功を追記するログ
reports/<run>.json と .html、report.html	done（または任意の早期終了）、run-log.mjs 経由	各実行のビルドレポート。report.html は最新のレポートです

常に最新の状態に保つ必要がある最低限のファイルは state.json です。stage は最後に完了したステージではなく、次に実行するステージであり、ドメインは保存しません。ドメインはディレクトリで識別します。プロビジョニングはバックグラウンドで実行されるため、その状態は stage ではなく専用の provision フィールドに保存されます。そのため、プロビジョニングがまだ進行中でも、準備作業によって stage を先に進められます。

{
  "tool": "claude-code",
  "stage": "content_model",
  "provision": {
    "status": "in_progress",
    "domain": "example.com",
    "started_at": "2026-10-08T10:00:00Z"
  },
  "updated_at": "2026-10-08T10:00:00Z"
}

• provision は、プロビジョニングが始まるまでは存在せず、バックグラウンドのポーリング中は {"status":"in_progress", …}、hosting_websites_list-setups による確認後は {"status":"completed", …} になります。domain がポーリング対象です。
• インスタンスの準備完了が前提となるステップ（コンテンツモデルの反映、フロントエンドのデータ処理、デプロイ）は、実行前に provision.status == "completed" を確認し、コネクターでも再確認する必要があります。準備ステップでは provision を無視します。
• 再開時、provision.status はあくまで参考情報です。hosting_websites_list-setups を再度ポーリングして実際の状態を確認し、その後フィールドを更新してください。
• run（現在の実行）、history（実際の開始時刻と終了時刻を記録した、ステージまたはフェーズごとのエントリー）、および reports_sent／reports_rejected（どのレポートが Hostinger に届いたかを記録したもの）は、run-log.mjs だけが書き込みます。state.json を手動で更新するときは変更しないでください。
• オンボーディング用スラッグは、hPanel がコーディングツールを識別するための名前です。Claude Code の場合は claude、それ以外は cursor、codex、vscode、antigravity、devin です。run-start --tool に渡す <tool> から割り当てます（state.json → run.tool。例：claude-code → claude）。

---

実行ログとビルドレポート

run-log.mjs（このファイルと同じディレクトリにあります）は、実行中にログを記録し、最後にレポートを作成します。タイムスタンプはスクリプトが記録するため、記憶に頼らず実測値になります。必要なのは Node だけです。各コマンドは node <skill>/run-log.mjs <domain> … の形式です。<skill> はこのファイルがあるフォルダーです。毎回、コマンド全体を記述してください（コマンドを保持するシェル変数は zsh では動作しません）。

node <skill>/run-log.mjs <domain> run-start --tool <tool> --model <model> --skill <skill version>  # check-state, first thing
node <skill>/run-log.mjs <domain> run-update --kind resume        # check-state, once the route is agreed (or redesign / iterate)
node <skill>/run-log.mjs <domain> stage-start frontend            # before a stage
node <skill>/run-log.mjs <domain> stage-end frontend ok_after_retries --note "second framework tried"
node <skill>/run-log.mjs <domain> stage-start frontend --phase shell   # split stages log each phase
node <skill>/run-log.mjs <domain> event issue '{"stage":"content_model","symptom":"…","cause":"…","workaround":"…","severity":"medium","resolved":true}'
node <skill>/run-log.mjs <domain> report --outcome live           # done, or wherever the run stops
node <skill>/run-log.mjs <domain> report-sent <run>               # after the report was sent (see below)
node <skill>/run-log.mjs <domain> report-rejected <run>           # the send returned 422
node <skill>/run-log.mjs <domain> unsent                          # check-state: reports still to send
node <skill>/run-log.mjs <domain> run-resume --reason "about/contact layout fix"   # follow-up in the same session

フォローアップも同じ実行の続きです。 同じセッションで最終レポートの後にユーザーから変更（レイアウトの修正、コピーの微調整、再デプロイなど）を求められた場合、その作業は直前の実行に含めます。run-resume を呼び出し、フィードバックと再実行するステージを通常どおり記録してから、もう一度 report を実行します。これにより同じ reports/<run>.json と .html が書き換えられるため、report.html を置き換える別のレポートではなく、フォローアップを含む 1 つのレポートになります。新しいセッションでは run-start を使います。check-state がこれを行います。

stage-end の結果：ok、ok_after_retries、ok_with_fixups、failed、skipped、stopped。ステージ：check_state、refine、provision、content_model、design、frontend、validate、deploy、done（connect には専用の connect.json があります）。分割されたステージでは --phase を使います：provision は fire / join、content model は prepare / push、frontend は shell / data です。

stage-start を忘れましたか？ 気づいた時点で、ステージの開始時刻をおおよそ指定して記録します：stage-start frontend --started-ago 6m（または --started-at <ISO time>）。開始記録のない stage-end にも同じフラグを使えます。どちらも指定しない場合、スクリプトは前のステージが終了した時点でこのステージが始まったとみなします。いずれの場合も、レポートでは開始時刻が推定値として示されます。作業が終わってから stage-start と stage-end を続けて記録してはいけません。ステージの所要時間がゼロとして記録されます。すでにそう記録した場合は、stage-fix frontend --started-ago 6m で修正してください。

イベントは発生した時点で記録してください。最後に記録しようとしても、その頃には詳細を忘れています。

イベント	記録するタイミング	フィールド（太字は必須）
issue	問題が発生した、正常に動作しなかった、または回避策が必要になったとき（自分のミスも含む）	stage、symptom、原因、回避策、severity（high／medium／low）、resolved、user_had_to_intervene
feedback	ユーザーから訂正や却下があった場合、またはスコープが変更された場合	stage、category（例：design_rejected、layout_bug、scope_add、wrong_assumption）、paraphrase
skill_gap	手順がダミー、欠落、誤り、または必要な情報に関する説明がない場合	skill（パス）、gap
good	特にうまくいった、または速く進んだ作業があった場合	text

ユーザーの発言は要約してください。長い引用、ファイルの内容、認証情報、個人情報を貼り付けてはいけません。ユーザーが問題を指摘する必要があった場合は、user_had_to_intervene を設定します。

トークン数は、ツールから自身の使用量が直接通知された場合に限り、report --tokens '<json>' で記録します（{"source":"…","requests":…,"input":…,"output":…,"cache_read":…,"cache_write":…,"est_cost_usd":…}）。それ以外の場合は省略してください。レポートには null ではなく {"source":"not reported"} と記録されます（コネクターは tokens が null だと受け付けません）。取得のためにセッションのトランスクリプトやログファイルを読んではいけません。

レポートは reports/<run>.json と .html に保存され、ワークスペースの report.html は最新のレポートになります。実行がレポート作成まで到達しなかった場合（ウィンドウが閉じられた場合など）、次の run-start がその実行を abandoned として終了し、ログをレポートにします。

すべてのレポートを Hostinger に送信してください。 送信はワークフローの一部なので、事前に確認を求めないでください。送信直後に、1 行でユーザーに伝えてください（09-done を参照）。各 report の直後（フォローアップの場合も含む）に、reports/<run>.json を読み込み、内容を変更せずに Hostinger コネクターツール hosting_headless_submit-build-report の引数として渡します。その後、結果を記録します。

• 成功： report-sent <run>。
• 422（レポートがエンドポイントのスキーマに適合しない）：report-rejected <run>。再送信してはいけません。
• その他（ネットワークエラー、5xx、ツールがコネクターにない場合）：何もしません。次の check-state で再送信します。 送信前に JSON を編集したり、アカウント情報を追加したりしないでください（アカウントはコネクターのログイン情報によって識別されます）。また、送信に失敗しても、実行をブロック、遅延、変更しないでください。状態確認では、まだ送信されていないレポート（中断された実行や以前の失敗）を unsent とともに送信します。