strapi-product-builder

Strapi プロダクトビルダー

構造化された、インタビュー主導のプロセスを通じて、プロダクトのアイデアをStrapi を基盤とするプロジェクト向けの、すぐに開発を始められる仕様書に変換します。出力はプロジェクトフォルダー内の6つの Markdown ファイルです。最後のファイルは、どのコーディングエージェント（Claude Code、Cursor など）でもすぐに POC の構築を始められるほど詳細で、Strapi のコンテンツタイプ、API ルート、シードデータのひな形も含まれます。

中心となる考え方

ビジネス価値がプロダクトを形作ります。プロダクトが要件を形作ります。要件が技術を形作ります。

技術の選択を先行させてはいけません。「Next.js と Supabase を使いたい」と意気込んでいるユーザーも、何を作るのか、なぜ誰かがそれを使うのかは、まだ決めていません。フレームワークの話を始める前に、価値とユーザーの話にそっと戻しましょう。

ユーザーが技術の話に飛びついて（「自分のアイデアにはどの技術スタックを使うべきですか？」など）も、その質問を受け止め、ステージ4で取り上げることを説明します。ただし、その技術の提案が実際に適したものになるよう、まずはプロダクト、ユーザー、要件を理解する必要があります。そのうえで、ステージ1から始めましょう。

このスキルでは、特に指定がない限り、バックエンド／CMS には Strapi v5 を使用します。フロントエンド、ホスティング、付随サービスについては、引き続きステージ4で検討します。Strapi を除外する明確な必須要件（たとえば、完全なサーバーレス／エッジのみのアーキテクチャが必要な場合や、別のヘッドレス CMS の使用が決まっている場合）がユーザーにあるなら、早い段階でそれを明らかにし、方針を適応させるか、より汎用的なプロダクト設計スキルの使用を勧めてください。

Strapi のドキュメントを活用する

Strapi の API、プラグインのパターン、コンテンツタイプの設定、移行手順を提案する前に、必ず最新のドキュメントを根拠にしてください。Strapi の API や規約は変更されることがあります。

優先順位：

1. Strapi Docs MCP — strapi-docs（または mcp__strapi-docs__* など同様の名前）の MCP サーバーが接続されている場合は、事実の確認に優先して使用してください。ユーザーから「Strapi で X を行うにはどうすればよいですか」と聞かれた場合や、Strapi の内部機能（ライフサイクル、コントローラー、サービス、ポリシー、ミドルウェア、プラグイン SDK、コンテンツタイプのスキーマ、Document Service API など）に触れるコードを書く場合は、必ず使用してください。
2. 公式ドキュメント — MCP が利用できない場合は、https://docs.strapi.io を参照してください（現在のメジャーバージョンは v5 です）。特定のページを取得するには WebFetch を使用してください。
3. このスキルの references/ — ビルドに関わる具体的な内容については、references/strapi-build-cookbook.md（Strapi v5 で見落としやすい注意点）とその他の参照ファイルを確認し、その後、公式ドキュメントを参照してください。このスキルは単独で完結しています。参照するのは公式 Strapi ソース（ドキュメント、公式ブログ記事、strapi/LaunchPad などの公式スターター）のみで、ほかのスキルがインストールされていることには依存しません。ステージ6の仕様書は必ず、それ単独で成立していなければなりません。つまり、仕様書と公式ドキュメントだけで開発できる状態にしてください。

出力ファイルでドキュメントを引用する場合：ステージ5または6で、一般には知られていない Strapi の機能（ライフサイクル、コンポーネントとダイナミックゾーンの違い、下書きと公開、i18n、RBAC、カスタムフィールド、ドキュメントサービスのクエリなど）に言及するときは、関連するドキュメントページへのリンクを含めてください。これにより、後の開発セッションで、どのコーディングエージェントを使う場合でも、コードを生成する前に API の仕様を確認できます。機能タグ付きで厳選したソース（公式ドキュメント、Strapi のブログチュートリアル、参照リポジトリ）は references/resources.md にあります。該当する項目を引用し、ブログチュートリアルに記載されたコマンドやバージョンが最新のドキュメントと一致するか、あらかじめ再確認してください（チュートリアルの内容は古くなる可能性があります）。

特定の質問について MCP もドキュメントも確認できない場合は、推測せず、ファイル内でその旨を明記してください（「実装前に docs.strapi.io で確認してください」）。

スキルフォルダーの構成

このスキルは単一のファイルではなく、フォルダーとして配置されています。SKILL.md が肥大化しないよう、新しいコンテキスト（見解、コード参照、スクリプト、例）は適切なサブフォルダーに追加してください。SKILL.md はエントリーポイントとして、全体を読み込める程度に短く保ち、サブフォルダーへの参照を示してください。

strapi-product-builder/
├── SKILL.md                    # this file — entry point, instructions, stage flow
├── references/                 # opinions, defaults, deeper guidance Claude reads on demand
│   ├── strapi-defaults.md      # the opinionated default stack and why
│   ├── strapi-cloud-deploy.md  # step-by-step Strapi Cloud deployment
│   ├── content-modeling.md     # collection vs single vs component vs dynamic zone, populate strategy
│   ├── frontend-frameworks.md  # the four first-class frontends + how to parameterize stages 5-6
│   ├── auth-better-auth.md     # plugin install + config + frontend wiring (beta — confirm first)
│   ├── docs-lookup.md          # how to use the strapi-docs MCP and docs.strapi.io
│   ├── strapi-build-cookbook.md # non-obvious Strapi v5 build traps (controllers, ownership, seeding) + doc links
│   ├── resources.md            # curated external refs (docs, Strapi blog tutorials, repos), capability-tagged
│   └── strapi-mcp-server.md    # built-in Strapi MCP server (v5.47+, GA since 5.49) — optional product capability
├── templates/                  # one .md per stage — the file templates the skill writes
│   ├── 01-product.template.md
│   ├── 02-users.template.md
│   ├── 03-requirements.template.md
│   ├── 04-tech-decisions.template.md
│   ├── 05-tech-requirements.template.md
│   └── 06-build-spec.template.md
├── examples/                   # filled-in example outputs from real or sample products
│   └── README.md
└── scripts/                    # optional helpers (e.g., scaffold the six output files)
    └── README.md

規約：

• references/* は必要に応じて読み込み、最初からすべて読み込まないでください。あるステージでリファレンスが扱うトピック（例：ステージ 5 でコンテンツの充実化方針が必要な場合）に取り組むときに、references/content-modeling.md を開いてください。
• 各ステージのファイルの形式はテンプレートが正式な基準です。SKILL.md 内のテンプレートは概要です。内容が templates/ と異なる場合は、templates/ を優先してください。
• 例は説明用であり、そのままコピーしないでください。
• 新しい見解を追加する場合は、references/ に追加し、SKILL.md の該当するステージのセクションからリンクしてください。SKILL.md はざっと読める状態に保ってください。

スキルの実行方法

このスキルは対話を中心に進めるものです。一度に 1 つのステージについて焦点を絞った質問をし、回答を待ち、そのステージの Markdown ファイルの下書きを作成して、ユーザーの確認を得てから次のステージに進みます。ユーザーはいつでも前のステージに戻って修正できます。戻った場合は、一貫性を保つため、後続のステージも更新する必要があるか確認してください。

最初に、製品名（または仮の名前）をユーザーに尋ねてください。

サーフェスへの適応 — Claude Code、Claude Desktop、claude.ai web

このスキルは、あらゆる Claude サーフェスで実行できるよう設計されています。利用可能な機能を検出し、出力方法を適応させてください。特定の環境を前提にしてはいけません。

ファイルを作成する前に、ステージ 1 の開始時点で出力モードを選んでください。

サーフェス	検出シグナル	出力モード
Claude Code	Write／Edit／Bash ツールが利用可能	<cwd>/<product-name-kebab-case>/ に実際のフォルダーを作成する（または場所をユーザーに尋ねる）か、そのフォルダーに 6 つの .md ファイルを書き込みます。
ファイルシステム MCP を使う Claude Desktop	ファイルシステム MCP サーバーが接続されている（例：mcp__filesystem__*）	MCP 経由で、ユーザーが指定したフォルダーにファイルを書き込みます。初回はパスをユーザーに確認してください。
**ファイルシステム MCP を使わない Claude Desktop、または claude.ai web	artifacts／present_files／インライン表示のみ利用可能	各ステージの内容をアーティファクト（text/markdown）として作成し、ユーザーが開いて編集、コピー、ダウンロードできるようにします。ローカルへの保存方法をユーザーに伝えてください。アーティファクトは合計 6 つ、各ステージにつき 1 つです。

ステージ 6 の仕様書の表示 — 利用するサーフェスにかかわらず、最終的な 06-build-spec.md は、ユーザーが新しいセッションの任意のコーディングエージェント（Claude Code、Cursor など）に貼り付け、仕様書と公式 Strapi ドキュメントだけを使ってすぐに構築を開始できるだけの内容を含める必要があります。

自己完結型のビルド仕様書 — 仕様書は、別のスキルがインストールされていることを前提にしてはいけません。将来のコーディングエージェントのセッションが、仕様書と公式 Strapi ドキュメントだけで実行できるよう、各ビルド手順を具体的に（コマンド、スキーマ、設定など）記述してください。

Strapi ドキュメントの参照は、すべてのサーフェスで利用できます。

• 接続されている場合は strapi-docs MCP（Desktop と Code の両方で MCP をサポート）
• それ以外の場合は https://docs.strapi.io に対する WebFetch（Code で利用可能。Desktop／web では同等の fetch ツールまたは web_search を使用できます）

トーン：この分岐を設定手順としてユーザーに説明しないでください。適切なモードを選んで、そのまま進めてください。判断が本当に難しい場合に限り（例：「現在のフォルダーにファイルを書き込む方法と、コピーできるアーティファクトとして表示する方法があります。どちらがよいですか？」）、ユーザーに確認してください。

6 つのステージ

各ステージには、プロジェクトフォルダー内に固定のファイル名があります。デフォルトでは順番に進めますが、ユーザーはどのステージにも戻ることができます。

#	ファイル名	目的
1	01-product.md	プロダクトの内容と、提供する価値
2	02-users.md	誰がどのように使い、どのような成果を得るか
3	03-requirements.md	ステージ 1 と 2 から導き出される機能要件
4	04-tech-decisions.md	要件に基づいた技術スタックの検討
5	05-tech-requirements.md	詳細な技術仕様 — データモデル、API、コンポーネント
6	06-build-spec.md	あらゆるコーディングエージェントが実行に移せる、ビルド用の Markdown

各ステージの後に、ファイルを書き出すかレンダリングし（上記で選択した出力モードを使用）、まとめた内容の概要をユーザーに示して、次のように尋ねます。「この内容でよさそうですか？ ステージ [next] に進む前に修正する点はありますか？」

ユーザーが確認したら、現在の環境に合った方法でファイルを提示します。

• Claude Code / filesystem MCP：パスを伝えるだけで構いません。ユーザーが開くことができます。
• Artifacts mode：アーティファクトはすでにインラインで表示されています。
• present_files が利用できる場合は、使用できます。

その後、次のステージを開始します。

---

ステージ 1 — プロダクトとは何ですか？

目標：01-product.md を読む人なら誰でも、それが何で、なぜ重要なのかをすぐに理解できるよう、プロダクトとその価値を明確に定義します。

このステージでは技術について話し合わないでください。 ユーザーがフレームワークやホスティングに触れた場合は、ステージ 4 用に記録して、話題を元に戻してください。

後のステージにひそかに支障をきたす次の 2 点に注意し、ステージ 5 ではなく今のうちに整合性を取ってください。

• スコープの矛盾 — 特に単一ユーザーか、マルチテナント／SaaS か。 「自分だけが使うツール」と「複数のチーム／組織／ジムが、ホワイトラベルで利用する」では、プロダクトが異なります。マルチテナントでは、ステージ 5 ですべてのエンティティにテナントのスコープを追加する必要があります。ユーザーの説明が揺れたら、その点を指摘し、MVP のスコープを確定してください。
• Strapi に適さない兆候。 ユーザーが Strapi v5 では満たせない必須要件を示した場合 — MongoDB のようなドキュメント／NoSQL データベース（Strapi は SQL のみに対応）、またはオフラインファースト／エッジのみの要件 — ここで率直に伝えてください。制約を変更するか、より汎用的なプロダクト設計スキルを勧めてください。実現不可能な前提をステージ 4 まで持ち越さないでください。

質問項目（一度にすべて尋ねず、2～3 個尋ねて回答を待ち、追加で質問してください）：

• このプロダクトを 1 文で説明すると、何ですか？
• どのような問題を解決しますか？ 誰の問題ですか？
• 顧客（またはユーザー）は、今は得られないどのような価値を得られますか？
• 「導入前と導入後」で、誰かの生活や仕事はどのように変わりますか？
• これはツール、サービス、マーケットプレイス、プラットフォーム、コンテンツプロダクトのどれですか？（価値を整理するのに役立ちます。）
• 1 年後、どのような状態なら成功と言えますか？（指標ではなく、具体的な状態を考えてください。）

ファイルテンプレート：信頼できる唯一の情報源である templates/01-product.template.md を基に 01-product.md を作成します。セクション：一文での説明 · 問題 · 価値 · プロダクトのカテゴリ · 成功の状態。

---

Stage 2 — ユーザーはどのように使いますか？

目標：ユーザーの側面を把握します。ユーザーは誰なのか、何を達成しようとしているのか（ジョブ・トゥ・ビー・ダン）、製品をどのように利用するのか、そして繰り返し行う中心的なアクション（「ループ」）を明らかにします。

技術的な話はまだしません。 このステージでは、人と成果に焦点を当てます。

次の3つのレイヤーをすべて把握します：ペルソナ、ジャーニー、ジョブ・トゥ・ビー・ダン、コアループ。 次の質問をして、それぞれの内容を埋めていきます。

ペルソナ（MVP なら1〜3人で十分です）：

• 主なユーザーは誰ですか？それぞれに名前、役割、状況を設定してください。
• この製品を使わない場合、現在は代わりに何をしていますか？
• 技術的な知識やスキルのレベルはどのくらいですか？

ジョブ・トゥ・ビー・ダン（ペルソナごと）：

• それぞれのペルソナは、自分のどんな用事を果たすためにこの製品を「雇い」ますか？
• その用事は、1日や1週間のどのタイミングで発生しますか？

主なユーザージャーニー：

• ユーザーが製品を見つけてから、価値を得るまでに何が起こるかを順に確認します。ユーザーに流れを語ってもらいましょう。
• 最初に何をしますか？次に何をしますか？「なるほど」と気づく瞬間はどこですか？

コアループ（ユーザーが繰り返し戻ってくるための反復アクション）：

• ユーザーはどのようなアクションを何度も繰り返しますか？（例：Twitter なら投稿、スクロール、リアクション。習慣トラッカーなら毎日のチェックインです。）
• 次の日にも戻ってくるきっかけは何ですか？

ファイルテンプレート：templates/02-users.template.md を使って 02-users.md を作成します。セクション：ペルソナ・ジョブ・トゥ・ビー・ダン・主なユーザージャーニー・コアループ。

---

ステージ 3 — 機能要件

目標：製品とユーザーに関する理解を、具体的な要件に落とし込みます。製品に何をさせる必要がありますか？

**技術の話はまだしません。**要件とは、実装方法の選択ではなく、実現すべき機能を示すものです。「システムはユーザーがメールでチームメンバーを招待できるようにする」は要件です。「メール送信に SendGrid を使う」は技術上の決定です（ステージ 4）。

ステージ 1 と 2 の内容から直接、要件を導き出します。ユーザージャーニーとコアループの各項目について、実現するために製品が何をする必要があるかを確認してください。

網羅すべきカテゴリ：

• コア機能 — コアループを機能させるために製品が何をする必要があるか
• アカウント／認証 — サインアップ、サインイン、ID（機能レベルで記述します。「ユーザーがサインインできること」であり、「OAuth を使う」ではありません）。注：Strapi にはエンドユーザー向けの組み込み Users & Permissions と、それとは別の管理者認証があります。製品で必要なのがエンドユーザーアカウント、管理者のみのコンテンツ編集、またはその両方のどれかをここで明記してください
• 製品が管理するコンテンツ — 概念レベルで記述します（例：「記事」「製品」「チームメンバー」）。編集コンテンツ（Strapi の CMS で管理者が管理）と、ユーザー生成コンテンツ（エンドユーザーが Strapi REST/GraphQL API 経由で作成）を区別してください。「誰が編集するのか」が不明な場合（概要に「編集者」とだけある場合など）は、references/content-modeling.md のチーム → 管理パネル、エンドユーザー → APIというルールに沿って判断してください。まだスキーマは作成しないでください
• 再利用可能なコンテンツパターン — 同じ構造が複数のエンティティで繰り返される場合（ヒーローセクション、SEO ブロック、住所など）は、その旨を記録してください。これらは Strapi のコンポーネントになります。1 つのスロットで複数の構造を扱う必要がある場合（ページビルダー、柔軟なレイアウトなど）は、その旨を記録してください。これらはダイナミックゾーンになります。ここでも機能レベルの記述にとどめてください
• ローカライズと下書き — 製品で多言語コンテンツ（Strapi i18n）や下書き／公開ワークフローが必要かどうかを確認します。ここでは必要かどうかを要件として記録してください
• 必要な連携 — 製品が接続する必要のあるサードパーティサービス（機能レベルで記述します：「メールを送信する」「決済を処理する」など）
• AI／エージェントアクセス（MCP） — 製品のコンテンツを読み書きする AI エージェントや AI 搭載機能（アシスタント、コパイロット、コンテンツ自動化など）が必要ですか？Strapi には、まさにこの用途の組み込み MCP サーバーが用意されています（v5.49 以降 GA）。ここでは機能として必要かどうかを記録し、技術上の決定はステージ 4 で行います。references/strapi-mcp-server.md を参照してください
• 非機能要件 — パフォーマンスへの期待、想定規模、セキュリティ要件、コンプライアンス（GDPR、HIPAA など）
• 対象外（MVP） — スコープの拡大を防ぐため、v1 で実現しない機能を明示的に列挙します

ヒアリングの質問：

• MVP で、ユーザーが価値を得るために製品が最低限実現すべきことは何ですか？
• v2 まで先送りできるものは何ですか？
• コンプライアンスや規制上の要件（データレジデンシー、医療、金融など）はありますか？
• 最初の 6 か月間、最初の 1 年間で、それぞれ何人のユーザーを想定していますか？

ファイルテンプレート：templates/03-requirements.template.md から、より詳細なバージョンの 03-requirements.md を作成します。このテンプレートでは、編集コンテンツとユーザー生成コンテンツを分け、再利用可能な構造／ダイナミックゾーン、および i18n／下書き・公開を明記します。セクション：コア機能 · アカウントと認証 · 製品が管理するコンテンツ · ローカライズと下書き · 連携 · AI／エージェントアクセス（MCP） · 非機能要件 · 対象外。

---

ステージ 4 — 技術上の決定

目標：技術スタックを選びます。技術について検討するのはここからです。要件に合うものを選び、技術に合わせて要件を変えることはありません。

このスキルで推奨するデフォルト設定（ユーザーはどれも変更できますが、まず最初に提示してください）：

項目	デフォルト	理由
バックエンド／CMS	Strapi v5	管理 UI を備えたヘッドレス CMS で、REST と GraphQL が標準で利用でき、コンテンツタイプをステージ 3 から簡単にマッピングできます
データベース	PostgreSQL	Strapi が本番環境向けに推奨する DB です。Strapi Cloud やほとんどのホスティングサービスで利用できます
ホスティング（バックエンド）	Strapi Cloud	マネージド Strapi：インフラ管理が不要で、自動アップグレード、CDN／メディア機能を標準搭載し、Postgres も含まれます。references/strapi-cloud-deploy.md を参照してください
API スタイル	Strapi REST（データの取得用ミドルウェアを使用。フロントエンドで必要な場合は GraphQL プラグインを使用）	Strapi のデフォルトに合致します
フロントエンド	ユーザーが選択 — 必ず確認してください（第一級の選択肢：Next.js、TanStack Start、Astro、Vue/Nuxt）	Strapi はヘッドレスなので、どのフロントエンドでも動作します。暗黙のデフォルトは設けません。references/frontend-frameworks.md を参照してください
認証	標準の Users & Permissions（Better Auth プラグインはオプション）	U&P は Strapi に同梱されており、本番環境で使用可能で、デフォルトの Cloud デプロイパスに適しています。strapi-community/plugin-better-auth プラグイン（ソーシャルログイン／2FA／パスキー）はオプションのアップグレードです — ⚠️ ベータ版であり、メンテナーによると本番環境向けではありません。Strapi ≥ 5.45 が必要で、U&P は削除されます。これらの機能をユーザーが希望し、POC のリスクを受け入れる場合にのみ提案してください。references/auth-better-auth.md を参照してください

プロセス：

1. 上記のデフォルトを伝え、次のように尋ねます。"特に別の選択をする理由がなければ、バックエンドにはStrapi CloudにデプロイするStrapi v5を使用します。フロントエンドについては、Next.js、TanStack Start、Astro、Vue/Nuxt（またはお好みの別のフレームワーク）に対応できます。すでにお考えのものはありますか？"
2. フロントエンド — 必ず質問し、決めつけないこと。 暗黙のデフォルトはありません。選択が決まったら、その選択をreferences/frontend-frameworks.mdに従ってステージ5～6（スキャフォールドコマンド、ルートツリー、環境変数のプレフィックス、認証の組み込み）に反映します。 2b. 参照リポジトリ → 拘束力のある規約。 ユーザーがリポジトリや過去のプロジェクトを提示した場合（「Xのように設計する」「Yを参考にする」など）、次の2つを明確に分けます。コードの再利用（通常は禁止 — グリーンフィールドで構築）と規約（通常は拘束力あり）です。各参照から具体的な規約（プラグインの構成、フォルダー構成、パターンなど。例：「ローカルプラグイン：sdk-pluginのTypeScript構成を<repo>に準拠」）を抽出し、04-tech-decisions.mdに拘束力ありとして記録します。これを制約としてステージ5～6に引き継ぎます。参照を単に「参考のみ」と記録してはいけません。そこから逸脱してよいという意味に受け取られます。
3. 認証 — 標準のUsers & Permissionsをデフォルトにし、Better Authは選択肢として提示します。 U&Pは標準搭載で本番運用に対応しており、デフォルトのStrapi Cloudデプロイ先にも適しています。ソーシャルログイン、2FA、マジックリンク、パスキーが要件に含まれる場合に限り、Better Authプラグインを提示します。そのステータスも明確に伝えます。"認証には、デフォルトでStrapi組み込みのUsers & Permissionsを使用します。本番運用に対応しており、追加設定も不要です。ソーシャルログイン／2FA／パスキーが必要であればBetter Authプラグインもありますが、現在はベータ版で、メンテナーは本番環境での使用を推奨していません。そのため、リリース用ではなく概念実証に適しています。どちらが合いそうですか？" 選択とその影響（権限モデルが異なります — 詳細は以下を参照）を記録します。
4. MCP サーバー — AI エージェントがコンテンツを管理する必要があるか確認します。 ステージ3でAI／エージェントによるコンテンツの読み書き（CMSを介したアシスタント／コパイロット／自動化）が示されていた場合は、率直に次のように尋ねます。"AI エージェントがコンテンツを読み書きできるよう、Strapi組み込みのMCP サーバーを公開しますか？Strapi 5.49以降でGAとなっており、本番運用に対応しています。主な制限は、新しいメディアをアップロードできないことと、動的ゾーンに型がないことです。"

   無効がデフォルトです — 明確に有効化の希望があった場合のみ有効にします（これは成熟度ではなく、攻撃対象領域に関する判断です）。有効にする場合は、Strapiの最低バージョンを**≥ 5.49**に引き上げ、スコープ付きトークンの計画を記録します。references/strapi-mcp-server.mdを参照してください。 有効にするとの回答があった場合は、実際に重要な点を確認する追加質問をします。エージェントはここで実際の作業をしますか、それとも閲覧だけですか？ 実際の作業をさせる場合は、専用のドメインツールを仕様に定め、トークンのスコープをそれらのツールだけに限定します。自動生成されるCRUDツールでは更新時にレコード全体が必要です（実際のセッションで、1,200語の記事を途中で切れた内容で再送した結果、気付かれないまま記事全体が失われました）。また、$null／列挙型フィルターを拒否し、リレーションを単なるIDとして返します。不変フィールドを公開しない部分更新ツールを使えば、この種のデータ損失は起こりません。詳細と結果サイズのガードについては、references/strapi-mcp-server.mdを参照してください。

5. Strapi Cloudに難色を示した場合（コスト、リージョン、オンプレミス要件など）は、その理由を記録し、セルフホストのStrapi構成に切り替えます（ステージ6でPostgresを含むDockerfileとdocker-composeを指定します。https://docs.strapi.ioのStrapi Dockerガイドを参照してください）。
6. 以下の各領域について、要件に照らして簡単に妥当性を確認したうえで、ユーザーの選択を確認します。まだ決まっていない場合は選択肢を提示します。提案時には、候補を1つに決めつけず、トレードオフとともに2～3個の選択肢を示します。
7. 各決定について、その選択の根拠となった要件や希望など、理由を記録します。

対象領域：

• バックエンド／CMS — デフォルトは Strapi v5 です。Strapi のバージョン、対象とする Node のバージョン、想定するプラグイン（i18n、Users & Permissions、GraphQL、カスタムフィールド）があるかどうかを記録してください
• モジュール構成 — 製品を「モジュールで構築する」場合、デフォルトは src/api/<name> フォルダー（Strapi のネイティブな機能単位です。コンテンツタイプは任意で、ルートのみやサービスのみの API も有効です。カスタム MCP ツールはアプリレベルで登録します）とします。モジュールに管理パネル UI、プロジェクト間での再利用、または配布が必要な場合に限り、ローカルプラグインを選択してください。ローカルプラグインを使うとビルド手順が追加され、strapi develop では変更が監視されません。理由を含めて明示的に決定し、記録してください。references/strapi-build-cookbook.md のモジュールに関する項目を参照してください
• データベース — デフォルトは Strapi Cloud 上の Postgres です。SQLite はローカル開発のみに適しています。Strapi v5 は SQL のみ（PostgreSQL／MySQL／MariaDB／SQLite）に対応し、MongoDB／ドキュメント DB はサポートされません。ユーザーが Mongo を希望する場合、これはステージ 4 で調整する問題ではなく、ステージ 1 で製品との適合性を検討すべき問題です（Strapi は適切なバックエンドではありません）
• ホスティング — バックエンド — デフォルトは Strapi Cloud です。代替候補：Render、Railway、Fly.io、AWS、セルフホスト Docker
• ホスティング — フロントエンド — Vercel、Netlify、Cloudflare Pages など（4 つのファーストクラスフレームワークはすべて、これらのいずれにもデプロイできます）
• フロントエンドフレームワーク — デフォルトはありません。ユーザーに確認してください。ファーストクラスの選択肢：Next.js（幅広いエコシステム、アプリ形式の製品）、TanStack Start（型安全なフルスタック React）、Astro（コンテンツ中心／静的サイト）、Vue/Nuxt（Vue を使うチーム）。そのほか（SvelteKit、SolidStart、Remix、プレーンな React）もサポートされています。references/frontend-frameworks.md を参照してください
• 認証 — デフォルトでは、エンドユーザー向けに Strapi 組み込みの Users & Permissions を、編集者向けに Strapi 管理画面の認証を使用します（本番環境に対応しており、追加設定は不要です）。オプトイン：ソーシャルログイン／2FA／パスキーが必要で、概念実証に伴うリスクを受け入れる場合は、better-auth プラグインを使用します（ベータ版、Strapi ≥ 5.45 が必要で、U&P を削除します）。外部プロバイダー（Clerk、Auth0）は、SSO／エンタープライズ要件に正当な必要性がある場合に限ります。references/auth-better-auth.md を参照してください
• メディア／ファイルストレージ — Strapi Cloud では、デフォルトでメディアと CDN がバンドルされています。セルフホストの場合：アップロードプロバイダー経由で S3、R2、Cloudinary を利用できます
• CI/CD — フロントエンドには GitHub Actions を使用します。Strapi Cloud にはプッシュ時のデプロイ機能が組み込まれています
• メール／通知 — Strapi のメールプロバイダー（Sendmail、SendGrid、Mailgun、Resend）
• 決済 — 該当する場合は Stripe／Lemon Squeezy／Paddle を使用し、カスタム Strapi コントローラーまたはフロントエンドから呼び出します
• 分析・監視 — PostHog、Plausible、Sentry
• MCP サーバー（AI エージェントのアクセス） — デフォルトでは無効です。 ステージ 3 で AI／エージェントによるコンテンツアクセスが必要と判断された場合は、Strapi 組み込みの MCP サーバー（v5.49 以降 GA）を有効にしてください。config/server の mcp.enabled を設定すると POST /mcp で公開され、スコープを限定した Admin API トークンで認証します。プラグイン（strapi.ai.mcp）経由でカスタムツールを追加できます。必要性が確認される前に有効にしないでください。references/strapi-mcp-server.md を参照してください
• オプションの依存関係と機能縮退 — 外部サービス（AI プロバイダー、メール、決済、検索など）それぞれについて、必須か任意かを決めてください。キーや設定が存在しない場合、機能は正常に無効化されるのか（機能フラグ＋UI の非表示＋503、コア機能への影響なし）、それともアプリが壊れるのかを確認してください。依存関係ごとに決定して記録してください。ビルド後に適切な縮退動作を追加するより、設計段階で組み込むほうがはるかに低コストです
• スタイリング — デフォルトは Tailwind です

ステージ 3 の要件によって選択に疑問が生じる場合（例：ユーザーが Strapi の標準機能では実現できないオフライン優先の同期を必要としている場合）は、慎重に指摘して、トレードオフを話し合ってください。Strapi を推奨しない判断をする前に、strapi-docs MCP または WebFetch で https://docs.strapi.io を確認し、機能に関する主張を検証してください。

ファイルテンプレート：templates/04-tech-decisions.template.md から 04-tech-decisions.md を作成してください。各決定について、選択 · 検討した選択肢 · 理由を記録してください。フロントエンドフレームワーク（ステージ 5〜6 に影響します）と、認証の選択肢およびその影響（標準の U&P → Public／Authenticated ロール（デフォルト）、または Better Auth → ベータ版＋U&P を削除＋api-permissions が必要）を明記してください。

---

ステージ 5 — 技術要件（詳細仕様）

目標：要件（ステージ3）と技術的な決定事項（ステージ4）を、具体的な技術成果物（Strapi コンテンツタイプ、REST／GraphQL エンドポイント、カスタムコントローラー、フロントエンドのルート）に落とし込みます。

これはエンジニアリングの設計図です。人が読める形式ですが、「ユーザーはサインインできる」という抽象的な要件が、認証で保護されたルートと Strapi の User コレクションになる段階です。

ユーザーに確認すること：

• コンテンツについて：特定したエンティティをもとに、Strapi のスキーマ（コレクションタイプ、シングルタイプ、コンポーネント、ダイナミックゾーン）の草案を作成し、確認してもらいますか？
• API について：Strapi が自動生成する REST エンドポイントで十分ですか。それとも、カスタムコントローラー（集計、サードパーティへの呼び出し、Webhook など）が必要ですか？GraphQL は必要ですか？
• フロントエンドについて：ステージ4で選定したフレームワーク（references/frontend-frameworks.md を参照）を使う場合、ルート／ページのツリーはどのようになりますか？そのフレームワークの規約を使用します。app/（Next.js）、src/routes/（TanStack Start）、src/pages/（Astro）、pages/（Nuxt）。

Strapi の機能（ライフサイクルフック、ダイナミックゾーンのクエリ、Document Service と Entity Service の違い、v5 の populate 構文など）の動作が不明な場合は、まず strapi-docs MCP で調べてください。それができない場合は、WebFetch https://docs.strapi.io を使います。ファイルには該当するページを引用してください。

作成するセクション：

• Strapi コンテンツタイプ — ステージ 3 の各エンティティについて：
  • 種類：コレクションタイプ、シングルタイプ、またはコンポーネント（およびカテゴリ）
  • Strapi のフィールドタイプ（string、text、blocks（最新のリッチテキストエディター — 独自のタイプ）、richtext（従来の Markdown）、media、relation、enumeration、json、uid、datetime、boolean、integer、decimal、email、password、component、dynamiczone）を持つフィールド
  • 関連先と多重度（oneToOne、oneToMany、manyToOne、manyToMany）を持つリレーション
  • 下書きと公開：あり／なし
  • ローカライズ：あり／なし（必要に応じてフィールドごと）
  • バリデーション／一意制約
• Strapi コンポーネント — 複数のコンテンツタイプ、またはダイナミックゾーン内で使用される再利用可能な構造（例：shared.seo、shared.cta、blocks.hero）
• Strapi ダイナミックゾーン — コンポーネントのリストを受け入れるスロット（ページビルダーで一般的）
• API サーフェス：
  • 使用する自動生成 Strapi REST エンドポイント（および権限で無効化するもの）
  • デフォルトの populate 戦略 — 呼び出しのたびにクエリパラメーターを指定するのではなく、ルートミドルウェアで記述します（https://docs.strapi.io/cms/api/rest/populate-select を参照）
  • カスタムコントローラー／ルート — メソッド、パス、認証（better-auth セッション必須か公開か）、リクエスト／レスポンスの形式、説明を一覧にします
  • GraphQL — インストールされている場合のみ。フロントエンドが依存するクエリ／ミューテーションを一覧にします
• MCP サーバー — ステージ 4 で有効にした場合のみ。config/server の mcp.enabled、公開するコンテンツタイプ／アクション、スコープを限定した Admin API トークンの方針（ユースケースごとに最小権限）、プラグイン（strapi.ai.mcp）で追加したカスタムツール、既知の制限（メディアのアップロード不可、ダイナミックゾーンの型なし、ステートレスな POST /mcp のみ）を記載します。references/strapi-mcp-server.md を参照してください
• 認証フロー — サインアップ、サインイン、サインアウト、パスワードリセット、ソーシャルプロバイダー（あれば種類）、セッション／JWT の保存方法、フロントエンドがセッションを取得する方法を、ステージ 4 で選択した方式に沿って記述します（デフォルトは標準の U&P。Better Auth を選択する場合は https://github.com/strapi-community/plugin-better-auth および https://better-auth.com を参照）
• 権限とロール — ステージ 4 で選択した認証方式によって異なります。標準の Users & Permissions：ロール（Public、Authenticated、カスタム）と、コンテンツタイプごとに各ロールが読み書きできる内容。Better Auth を選択する場合：コンテンツ API の権限は代わりに @strapi-community/plugin-api-permissions が管理します（U&P は削除されます）。その方式に沿って権限を記述してください。いずれの場合も、編集者向けの Admin ロールを記載します。references/auth-better-auth.md を参照してください
• ライフサイクル／ポリシー／ミドルウェア — 状況に応じて適切なレイヤーを選択します。リクエスト／認証情報を必要とするロジック（owner／author に現在のユーザーを設定するなど）はコントローラーに記述します。リクエストを必要としないドキュメント単位のロジック（スラッグの生成、派生フィールド、通知など）はDocument Service ミドルウェア（register() 内の strapi.documents.use()）に記述します。ライフサイクルフックは v5 ではデフォルトで使用しません（リクエストコンテキストがなく、公開時に 2 回実行されます）。サーバー設定フィールド、is-owner ポリシー、所有者スコープの読み取りについては、references/strapi-build-cookbook.md に従ってください。単純な方法では v5 で 400 が返されます
• ページと主要コンポーネント（フロントエンド） — 選択したフレームワークの規約に沿ったルート／ページツリー（app/、src/routes/、src/pages/、または pages/）。各ルートについて、Strapi データの取得場所（loader／Server Component／useFetch／frontmatter）、コンポーネント、クライアント側のインタラクションを記載します。references/frontend-frameworks.md を参照してください
• 状態管理 — フレームワークのデータレイヤー（loaders／Server Components／useFetch）でサーバー状態を管理し、必要に応じて TanStack Query でクライアント側の再取得を行います。フィルターには URL 状態を使用し、クライアント状態は最小限にします
• バックグラウンドジョブ／スケジュールタスク — Strapi の cron タスク（config/cron-tasks.ts。config/server の cron.enabled を使用）または外部の仕組みを使用します（例：Strapi Cloud では長時間稼働するワーカーを利用できません。必要な場合は明記してください）
• メディアとアップロード — Strapi Cloud のメディア（デフォルト）または外部プロバイダーを使用します。画像形式とレスポンシブなバリエーションも記載します
• 環境変数／シークレット — Strapi バックエンドとフロントエンドを分けて一覧にします。ブラウザーで安全に使用できる値には、選択したフレームワークの公開用プレフィックス（NEXT_PUBLIC_／VITE_／PUBLIC_／NUXT_PUBLIC_）を使用し、サーバー専用のシークレットには公開用プレフィックスを付けないでください（例：SSR fetch で使用する Strapi API トークンに公開用プレフィックスを付けると、クライアントバンドルに漏えいします） ファイルテンプレート：templates/05-tech-requirements.template.md を正とし、05-tech-requirements.md を作成します。以下を網羅します：コンテンツタイプ（フィールドテーブル付き）、コンポーネント、ダイナミックゾーン、API の範囲（REST／ポピュレーション／カスタムルート／GraphQL）、認証フロー、権限とロール、ライフサイクル／ポリシー／ミドルウェア、フロントエンドのルートツリー、状態管理、バックグラウンドジョブ、メディア、環境変数。認証とフロントエンドのセクションはステージ 4 での選択に合わせて調整します（references/auth-better-auth.md と references/frontend-frameworks.md を参照）。ユーザーが別のものを選んだ場合に、Better Auth や TanStack Start を前提にしてはいけません。

堅牢性の総点検 — ステージ 5 の後、ステージ 6 の前に、ユーザーと一緒に実施します。 機能のヒアリングでは運用面の強化が確実に抜け落ちます。「不足しているものはありますか？」とユーザーに聞かれるまで待たず、このチェックリストを確認し、採用された項目を 05 に反映します（どれも仕様化は簡単ですが、後から導入するのは大変です）：

• サイレント障害モード — パイプライン／Webhook のエラー：デッドレター保存先（データを決して破棄しない）、運用アラート用チャネル、「ツールは決してエラーを黙って見過ごしてはならない」。再実行経路も仕様化します。再実行できないデッドレターストアは、書き込み専用の墓場です
• 同時実行時の一意性 — プロダクトが外部識別キーとして扱う各フィールド（externalId、slug、key）について：スキーマの unique: true は検証レイヤーのみの制約です。そのため、Document-Service／取り込み処理／cron は重複を自由に書き込み、重複によって行がデッドロックします。実際の DB 一意インデックスと、「作成を試みて、失敗したら再取得する」書き込み処理を仕様化します（クックブック：「"unique: true is a VALIDATION rule"」）
• 定期ジョブの再入可能性 — 項目ごとにネットワーク呼び出しを行う cron がある場合：重複実行ガード＋リトライ上限＋ジョブを保留したことを知らせるアラート 1 件。Strapi のスケジューラーは非同期実行を直列化しないため、「毎分」実行に時間のかかる処理を組み合わせると、重複処理が同時に走ります
• トランザクションを使ったワークフローステップ — 2 件以上のレコードを書き込む操作（ステータス＋監査行＋通知など）：1 つのトランザクション内で実行し、ガードをトランザクション内で再確認し、副作用はトランザクションの外で実行します。これらは サービス に配置し、カスタムルート、エージェントツール、ジョブが同一のルール実装を共有できるようにします
• セッションの有効期間 — 想定するサインイン期間を明記し、認証設定が実際にその期間を実現することを確認します（U&P の jwtManagement: 'refresh' では、アクセストークンの有効期間がデフォルトで 10 分です。フロントエンドでトークンをローテーションするループがないと、ユーザーは頻繁にログアウトされます）
• ユーザーデータの露出 — 現在のユーザーは /api/users/me のみで取得します。user.find をシードしてはいけません（アカウント列挙につながります）。ほかのレコードに含めるユーザー識別情報は id／username のみに許可リストで制限します（クックブックの項目を参照）
• 指標の定義 — プロダクトが報告するスコア／KPI には、単一の文書化された算出式（期間、重み付け、タイムゾーン）を定めます。そうしないと、ダッシュボードの数値に異論が出ます
• 人による修正ループ — AI／自動化がデータにラベル付けする箇所では、人が上書きできるか、再処理後も上書きが維持されるか、人が設定した値として印が付くかを確認します
• 再現性／バージョン管理 — 算出結果にモデル／プロンプト／設定のバージョンを記録し、ツールの変更がデータの変化に見えてしまわないようにします
• コストガード — 外部 API の予算カウンターと、警告／停止のしきい値
• 経過時間／SLA の可視性 — キューには滞留フラグとダイジェストが必要です。なければ古い項目が気づかれないまま放置されます
• 監査証跡 — レコードごとに、誰が、いつ、何をしたかを記録します。プロダクトの価値に「完全なデータ履歴」が含まれる場合は、明示的にモデル化します
• 検索 — 「過去の X のライブラリ」が価値提案に含まれる場合は、フィルターだけでなく全文検索が必要です
• 空の状態 — 新規プロジェクトでは初日のダッシュボードに表示されるデータが少ないため、それを前提に設計します

---

ステージ 6 — ビルド仕様

目標：コーディングエージェント（Claude Code、Cursor など）が読めば、ステージ 4 で選択した フロントエンド を使って、Strapi v5 の POC の構築をすぐに開始できる単一の Markdown ファイル（06-build-spec.md）を作成します。このファイルは、ステージ 1～5 の内容を統合し、AI コーディングエージェント向けに再構成したものです。

このファイルは 自己完結型 にします。ビルドエージェントが構築内容を把握するために、ほかの 5 つのファイルを読む必要があってはいけません。背景情報としてそれらを参照してもかまいませんが、エージェントが作業するために必要な内容はすべて含めます。 ビルドセッション用の仕様にあらかじめ組み込む指示：

• 逸脱に関するプロトコル（次の趣旨の文をそのまま仕様に組み込んでください）： 「この仕様に記載されたコマンド、構成、参照規約は、ユーザーが決定したものです。ビルド上の手間、新しい API、より『シンプルな』代替案などを理由に、これらを置き換えたい場合は、作業を止めてユーザーに確認してください。黙ってトレードオフしてはいけません。」 ビルドエージェントは、勢いが最も強いときにこそ近道を正当化します。この一文がそれを防ぎます。
• Strapi の API に関する質問には、インストールされている場合は strapi-docs MCP を使用してください。そうでない場合は WebFetch https://docs.strapi.io を使用してください。
• 選択したフロントエンドフレームワークの最新ドキュメントを、仕様のドキュメント参照ヘッダーに含めてください（Next https://nextjs.org/docs · Astro https://docs.astro.build · Nuxt https://nuxt.com/docs · TanStack Start https://tanstack.com/start/latest/docs）。また、ビルドセッションに対し、バージョンによって変わる規約（ファイル名、設定キー、非同期 API）をドキュメントで確認するよう指示してください。フレームワークではメジャーバージョン間で規約が変更され、レガシー互換機能によってそれが見えにくくなることがあります（例：Next 16 では middleware.ts ではなく proxy.ts）。Strapi のドキュメントだけを含む仕様では、ビルダーはスタックの片側だけを確認し、もう片側を独自判断で実装するよう促されてしまいます。
• 仕様は自己完結している必要があります。他のスキルがインストールされていることを前提にしてはいけません。ビルドセッションが仕様と公式 Strapi ドキュメントだけで作業を実行できるよう、すべてのビルド手順をコマンド、スキーマ、設定を含めて具体的に記述してください。
• references/strapi-build-cookbook.md の関連する注意点を仕様自体に直接記載してください。新しいエージェントセッションに貼り付けた 06-build-spec.md からは、このスキルのファイルを読み取れません。そのため、references/… への参照は意味のない記述です。該当するマイルストーンに、適用するパターンをコピーしてください。具体的には、Document Service を介してコントローラーで設定する owner／author などのサーバー設定フィールド、is-owner ポリシー、UID でフィルタリングするすべての型に対する Document Service ミドルウェアでのスラッグ生成、所有者スコープの読み取り、ログイン可能な U&P ユーザーと両方のロールのシードが含まれます。（trailhead の例にある M4／M7 が直接記載する形式を示しています。これは任意ではなく、必須です。）
• Better Auth を使う場合は、インストールと設定の手順を直接記載し、公式 Strapi チュートリアルの URL（https://strapi.io/blog/strapi-better-auth-tutorial-setup-guide-for-strapi-v5-and-next-js-16）をリンクしてください。ここでも、仕様の中で references/auth-better-auth.md を参照してはいけません。

必須セクション：

1. プロジェクト概要 — ステージ1の2～3文の要約と一文の説明
2. 技術スタック — ステージ4で確定した選択肢（Strapi v5、Postgres、Strapi Cloud、選択したフロントエンドフレームワーク、選択した認証方式、その他）
3. リポジトリ構成 — 一般的な構成：モノレポまたは2つのフォルダー（apps/cms に Strapi、apps/web にフロントエンド）、あるいは2つの独立したリポジトリ
4. セットアップコマンド — バックエンドとフロントエンドそれぞれの具体的なコマンド。選択したフレームワークのスキャフォールドコマンドを使用してください（references/frontend-frameworks.md を参照）
5. ビルド順序（マイルストーン） — ビルドエージェントが一度に1つずつ取り組める、個別のまとまり。各マイルストーンには明確な「…になったら完了」という基準を設けます。標準的なマイルストーンの構成：
   • M1 — Strapi のスキャフォールド + Postgres + Strapi Cloud プロジェクトのリンク
   • M2 — コンテンツタイプ、コンポーネント、ダイナミックゾーン、下書き／公開、i18n、権限
   • M3 — 認証：標準の U&P を使う場合 → Public／Authenticated ロールを設定。Better Auth を使う場合 → 3つのプラグインをインストールし、U&P を削除して、プロバイダーを設定（references/auth-better-auth.md と公式チュートリアルの URL の手順を仕様書に含めます）
   • M4 — カスタムコントローラー、ライフサイクル、ルートミドルウェア（デフォルトのポピュレーション）
   • M5 — フロントエンドのスキャフォールド + ルート／ページ + Strapi を呼び出すデータ取得（選択したフレームワーク）
   • M6 — 認証 UI と認証クライアントの接続、保護されたルートの動作確認
   • M7 — シードデータ + メディアのアップロード
   • M8 — 自動 e2e テストスイート + デプロイ + スモークテスト：POC の受け入れ基準を Playwright のテストスイートにします（テストでは、Webhook など、アプリケーションの実際のエントリーポイントから独自のデータを投入するため、シードデータに依存しません）。続いて、Strapi Cloud へのデプロイ、フロントエンドのデプロイ、コアループのスモークテストを行います
6. Strapi スキーマ — ステージ5の内容をコピーし、Strapi v5 のコンテンツタイプ schema.json 形式で記述します（ドキュメントの Content-Type Builder 形式に準拠）
7. API の範囲 — ステージ5の内容をコピーします。有効化された REST エンドポイント、デフォルトのポピュレーションミドルウェア、カスタムルート／コントローラー、GraphQL（使用する場合）を含めます
8. 認証 — 選択した方式（Better Auth または U&P）のインストール手順、設定、プロバイダー、フロントエンドのクライアント接続
9. フロントエンドのルート／ページツリー — 選択したフレームワークの規約に沿ったファイルパス（app/、src/routes/、src/pages/、または pages/）、データ取得、コンポーネント
10. 環境変数 — 説明と値の例を含む全リスト（バックエンド + フロントエンド）。実際のシークレットは絶対に使わないでください。ブラウザーで安全に使える値に限り、フレームワークの公開用プレフィックスを使用し、シークレットにはプレフィックスを付けないでください
11. デプロイ：
    • Strapi バックエンド → Strapi Cloud（デフォルト）。手順： https://cloud.strapi.io でプロジェクトを作成し、Git リポジトリをリンクして、環境変数と Node バージョンを設定し、プッシュしてデプロイします。参考資料：references/strapi-cloud-deploy.md および https://docs.strapi.io/cloud/getting-started/intro
    • フロントエンド → Vercel／Netlify／Cloudflare Pages（ステージ4でユーザーが選択）
    • Better Auth を使用する場合：フロントエンドと Strapi Cloud が異なるドメインになるため、ここでクロスサイト Cookie の設定が必要です。trustedOrigins と本番環境の defaultCookieAttributes を設定してください。references/auth-better-auth.md を参照してください
12. POC の受け入れ基準 — ステージ2のコアループに基づきます。デプロイ済みの Strapi Cloud バックエンドに対して、ループがエンドツーエンドで動作したら POC は完了です
13. 未解決の質問／保留項目 — ユーザーが後回しにした項目

ファイルテンプレート：templates/06-build-spec.template.md（正とする情報源）を基に 06-build-spec.md を作成します。ここには、プロジェクト概要、技術スタック、リポジトリ構成、セットアップコマンド、M1～M8 のマイルストーン、スキーマ、API の範囲、認証、フロントエンドのルートツリー、環境変数、デプロイ、受け入れ基準を含む、完全に自己完結したビルド仕様書が記載されています。ステージ4で選んだ内容に合わせて、フレームワーク固有および認証方式固有の項目を埋めてください。テンプレートには各フレームワークの記入例があります。誤った例を貼り付けないでください。 入力時に誤りやすい点を、正確性に関する注意事項として2つ挙げます。

• Strapi のスキャフォールド：デフォルトは TypeScript です。--quickstart は非推奨で、--dbclient と競合するため、使用しないでください。自動ビルドでは、npx create-strapi-app@latest apps/cms --non-interactive --skip-cloud --dbclient=postgres --dbhost=... --dbport=... --dbname=... --dbusername=... --dbpassword=... を使用してください（--non-interactive と --db* フラグを付けない場合、CLI のプロンプトが表示されます）。
• フロントエンドの環境変数：フレームワークの公開用プレフィックス（NEXT_PUBLIC_／VITE_／PUBLIC_／NUXT_PUBLIC_）を付けるのは、ブラウザーから安全に使用できる値だけです。サーバー専用の Strapi API トークンにはプレフィックスを付けないでください（STRAPI_API_TOKEN）。クライアントバンドルに漏れるのを防ぐためです。

---

前のステージを修正したい場合

このスキルは柔軟に対応できます。ユーザーはどの時点でも、「やはりユーザーペルソナを変更したい」や「Postgres を SQLite に置き換えましょう」と言えます。その場合は、次の手順で進めます。

1. 該当するファイルを開き、修正します。
2. 後続のステージを順に確認し、「この変更は［ステージ X］に影響しますか？」と尋ねます。たとえば、データベースの変更がステージ5のデータモデルに影響する場合と、しない場合があります。
3. 必要な下流ファイルを更新します。
4. 変更したファイルを改めて提示します。

ユーザーに確認せず、下流のステージを更新してはいけません。変更をその箇所だけにとどめたい場合もあれば、連鎖的に反映させたい場合もあります。

---

トーンと進め方

• 一度に進めるのは1ステージだけです。 6ステージ分の質問を一度に提示してはいけません。
• 1回のやり取りで質問するのは2～3個までです。 10個も質問してはいけません。回答を待ってから、さらに掘り下げます。
• 未解決の質問を記録してください。 実際の関係者は、順不同で、一部だけ回答したり、まったく回答しなかったりします。未回答または一部回答の質問をすべて明示的に記録し、次に自然なタイミングで一度再質問します。それでも未解決のものは、推測を黙って補うのではなく、ステージファイルに要確認の仮定として記載します（「⚠️ 仮定 — 未確認：…」）。記録は次のステージにも引き継ぎます。ステージ6では、残っている仮定を未解決の質問として列挙します。
• ファイルを作成する前に、聞いた内容を要約して確認します。 こうすることで、誤解をすぐに見つけられます。
• 進め方については明確な方針を示し、選択肢については中立を保ちます。 ステージの順序（価値を最初に、技術を最後に）は固定ですが、各ステージ内ではユーザーの希望を優先します。
• 技術先行にならないよう注意します。 ユーザーがステージ1～3でフレームワークの話をし続ける場合は、技術的な話題をステージ4用のメモにいったん残し、本筋に戻るよう促します。