start-an-app

アプリを作成する

アイデアを実際に動作するウェブアプリにしましょう。まずアイデアを正しく理解してから、構築します。最初のコミットから、できあがるのはユーザー自身のアプリです。ユーザーの名前、ページ、データモデルを備え、必要なインフラストラクチャだけを使用します。テンプレートのように感じられるものであってはなりません。

足場を組む前に、理解することが先です。 このスキルでは、ヒアリングが最も価値のある部分であり、形式的に済ませるためのものではありません。10分間、適切な質問をすればユーザーが自分のものだと実感できるアプリができあがります。ヒアリングを省くと、ユーザーが書き直さなければならない汎用的なCRUDのひな形になってしまいます。ビルドシートに合意する前に実行できるコマンドは、ステップ2aでのスキルのインストールだけです。ステップ3までは、アプリ自体には何も手を加えません。

基本ルール

• コードを書かない賢い友人に説明するように、選択肢を一つひとつ説明してください。「データベース」と言う前に、「データを保存する場所」と説明してください。技術用語はそれぞれ、最初に使うときに簡潔に説明し、その後は通常どおり使ってください。
• 明確になるまで掘り下げてください。 曖昧な回答には、推測で穴を埋めずに追加で質問してください。「クラブのサイト」はまだ仕様ではありません。会員はそこで何をするのでしょうか？
• 一度に扱う話題は一つにしてください。要件を聞き出す際は、リストを読み上げるのではなく、会話の流れに沿って進めてください。技術的な選択肢については、推奨する初期設定とともに、一度に一つずつ質問してください。そうすれば、ユーザーは「おすすめのもので」と答えるだけで済みます。
• 足りない点は、尋問するのではなく提案として示してください。「このようなアプリの多くには、投稿後に項目を編集する方法が必要です。初版に含めますか？」のほうがチェックリストより適切です。そうすることで、ユーザーは本当に望んでいるものを理解できます。
• 推奨したうえで、ユーザーの選択を尊重してください。ユーザーが推奨しない選択肢を選んだら、蒸し返さずその選択に従ってください。
• 決して drizzle-kit push を使わないでください。 スキーマの変更は必ず、最初のテーブルから毎回、db:generate の後に db:migrate を実行してください。
• IDはランダムに生成されるUUIDです。ただし、Better Authのテーブルは例外です。 定義するテーブルにはすべてUUIDを設定してください。Better AuthのCLIが生成するテーブルは生成されたままにしてください。つまり、ユーザーを参照するカラムは uuid ではなく text のままにします。references/database.md に両方のケースを記載しています。
• アプリは現在の作業ディレクトリにスキャフォールディングされます。そのフォルダーがプロジェクトのルートです。アプリ用のサブフォルダーを作ったり、その中に cd したりしないでください。ユーザーはそこにいることで、アプリの保存場所をすでに選んでいます。
• 技術スタックは固定です。Next.js、TypeScript、Tailwind、shadcn/ui、Drizzle、Better Authを使います。ヒアリングで選ぶのは、その範囲内の項目（データベース、サインイン方法、メール、アップロード、決済、AI、バックグラウンドジョブ、ドキュメント、アプリを検索で見つけられるようにするか、見た目）です。これらの構成要素を置き換えたり、別のフレームワークを追加したりすることはありません。ドキュメントはこのアプリ内のページであり、別のドキュメントプラットフォームではありません。
• ユーザーに関するあらゆる機能はBetter Authが担います。 ある連携にBetter Authのプラグインがある場合、特に決済では、プロバイダーの単体SDKを別途つなぎ込まず、プラグインを使ってください。ユーザー情報の管理元は一つ、顧客IDとWebhookの管理場所も一つにします。
• ツールは別の入口ではなく、もう一つの呼び出し元です。 アプリをAIエージェントに公開する場合、すべてのツールはボタンと同じ関数、同じ所有権チェック、同じログを通ります。また、モデルから渡された情報ではなく、トークンからユーザーを特定します。references/mcp.md を参照してください。
• デプロイ後も変わらない選択肢を優先してください。アップロードやPostgresのように、本番環境で機能の動作が変わる場合、ローカル環境とデプロイ環境で同じコードを使い、環境変数で切り替えてください。ユーザーが変更を覚えておく必要のある、別のコード経路を作ってはいけません。
• すべてのアプリに設定エリアを設けます。 これは仕上げではありません。最初のコミットから、アプリの規模に合わせて用意します。アカウントがある場合は、プロフィール、認証状態、パスワード、デバイス、退会方法が必要です。アカウントの有無にかかわらず、すべてのアプリにシステム画面を設けます。何が設定されているか、何が起きたか、何が動作中かを確認できる画面です。references/settings.md と references/ops.md を参照してください。
• アプリがユーザーに対して法的に果たすべきことは、質問するのではなく判断します。 プライバシーポリシー、利用規約、Cookieバナーが必要かどうかは、アプリの内容と読み込むものによって決まります。個人の日記にはどれも必要ありませんが、ユーザーが登録する公開プロダクトには最初の二つが必要です。バナーが必要なのは、セッションCookie以外の、必須ではないものを実際に読み込む場合だけです。必要なものを判断して、そのとおりに実装し、見落としではなく判断の結果としてユーザーに示せるよう、ビルド計画書に一行で記載してください。references/legal.md を参照してください。
• アプリの裏側で行われることは、すべてアプリ内から確認・操作できるようにします。 アプリがメールを送信する、バックグラウンドで処理を行う、またはスケジュールに従って動作する場合、ユーザーはアプリ内で実行されたことを確認し、失敗理由を読み、停止し、再試行できなければなりません。ホスティングのダッシュボードでログを読む必要があってはいけません。ユーザーが状況を確認できないものは、完成とは言えません。
• アプリを検索で見つけられるようにするか確認し、どちらの回答でも必要なものを実装します。 これは公開プロダクトやコンテンツサイトなど、検索で見つかる可能性がある場合に限ります。個人用または社内用ツールには質問せず、サイトマップも設けません。代わりに、ブラウザーのタブに適切なタイトルを表示し、検索結果から除外する設定を明示的に行います。これは省略ではなく、納品物の一つです。references/seo.md を参照してください。
• ドキュメントは、実際に存在する機能についてのみ、誰かが読む場所にだけ書きます。 ここで作るアプリのほとんどには必要ありません。見知らぬ人が登録するプロダクトにヘルプページが必要なら、内容に忠実な4ページのほうが、20ページより優れています。アプリにない機能を説明するページは、ページがないよりも悪い結果になります。存在しないボタンを探し回らせてしまうからです。references/docs.md を参照してください。
• すべてのアプリに、文書化されたデザインシステムを用意し、その後は何にも上書きさせません。 他の項目と同じようにヒアリングで見た目の希望を確認し、最初の画面を作る前にプロジェクトルートの DESIGN.md に記載します。助言ではなく、テーマトークンとして表現してください。それ以降は必ず従います。コンポーネントに色、フォントサイズ、角の丸みをハードコードするのは近道ではなくバグです。「ここではこのほうが見栄えがいい」という判断を許せば、アプリに青が5種類も生まれることになります。AGENTS.md と CLAUDE.md の両方からこのファイルを参照し、次にプロジェクトを開くエージェントにも守らせてください。references/design.md を参照してください。
• 検索する前に、メンテナー自身が提供するスキルを確認します。 shadcn、Vercel、Better Auth、Anthropicは、自社のライブラリ向けにエージェントスキルを公開しています。ステップ2aで一度だけグローバルにインストールします。それ以降は、これらのライブラリに関する情報を探す際、検索、ブログ記事、記憶よりも先に確認してください。APIに付属するファイルを読むほうが調査より速く、より正確です。
• バージョン番号は、書くことも受け入れることも禁止です。 インストールコマンドにも、package.json の記述例にも、文章にも、Dockerイメージタグにも書かないでください。このスキル内のファイルにバージョン番号を固定しているものはなく、今後も追加してはいけません。インストールでは常に現在の安定版を使い、それが何かを確定するのがステップ2です。スキルファイルに書かれたバージョン番号は、日付入りの嘘です。いつの間にか古くなり、昨年のAPIでアプリを構築することになります。
• 非推奨になったものは決して使いません。 参照ファイルで使っているものが現行リリースで非推奨になったり、名称変更や置き換えの対象になったりした場合は、「まだ動く」古い方法ではなく、置き換え後の方法を使ってください。「まだ動く」というのが、非推奨という言葉の意味です。削除までの猶予があるだけの廃止通知であり、それを使って公開すれば、ユーザーが望んでいない書き直しを押し付けることになります。
• 実行していないチェックは、実行したと主張せず、未実行だと明記します。 コードを書いたからアプリがそのとおりに動くと言うのは、検証ではなく記憶に基づく判断です。可能な限りチェックを実行してください。ブラウザー、キー、ドメインがまだないなどの理由で実行できない場合は、実行できなかったチェックと、その実行に必要なものを伝えてください。ユーザーは、何も言われなければ成功したと受け取ります。
• すべてのコマンド、パッケージ名、設定は、このファイルではなく参照ファイルに記載します。ユーザーが選んだ分岐に必要な参照ファイルだけを読み込んでください。
• ツールの変更（フラグの名称変更、初期化手順の変更など）が原因で参照コマンドが失敗した場合は、そのツールの公式ドキュメントを確認し、現行の代替手順を使って作業を完了してください。最後に、このスキルの参照ファイルを更新する必要があることをユーザーに伝えてください。

Step 1a — アイデアを理解する

ここから始め、全体像がはっきりするまでここにとどまります。

「何を作ろうとしていますか？友人に説明するように話してください。」

その後、さらに質問します。名詞（アプリが記録しておくもの）と動詞（それらに対して人々が行うこと）に注目してください。それらがデータベースのテーブルとページになります。どちらも具体的になるまで掘り下げます。

• 「順を追って説明してください。初めてアプリを開いた人は何をしますか？」
• 「その次は？翌日、またアプリを使いに来る理由は何ですか？」
• 「*[their vague word]*というのは、画面上では実際にどのように見えますか？」
• 「これより優れていると思う、すでに使っている類似のものはありますか？」

**次に、データモデルをわかりやすい言葉で相手に説明し、訂正してもらいます。**スキル全体で最も価値の高い質問です。スキーマを設計できない人でも、スキーマの何が間違っているかははっきり教えてくれるからです。

つまり、このアプリではハイキングの一覧を管理します。それぞれに日付、トレイル名、距離、感想、写真が含まれます。すべてあなたのもので、ほかの人には見えません。この理解で合っていますか？それとも、ほかに記録しておく必要があるものはありますか？

Step 1b — 足りない点を見つける

ユーザーから、うまくいく場合の流れは聞けました。残りを考えるのがあなたの役目です。次の項目を頭の中で確認し、本当に当てはまるものだけを取り上げてください。クイズのように質問するのではなく、推奨案を添えて提案します。

• データの所有者は誰ですか？ ユーザーごとの非公開、チームで共有、または公開ですか？これはアプリ内のすべてのクエリに関わりますが、言い忘れられがちな点です。
• 内容を変更できますか？ 説明では作成だけが取り上げられることがほとんどです。編集や削除も必要とされることが多いのに、ほとんど言及されません。
• 特別な権限を持つ人はいますか？ 管理者、モデレーター、ほかの人より多くの情報を見られるオーナーなどです。
• 初日はどのような状態ですか？ アプリを開いたとき、データはゼロです。その画面には何を表示すべきですか？
• 日時に関わるものはありますか？ 期限、リマインダー、繰り返し項目、「今週」の表示などです。
• 誰かに通知する必要はありますか？ 登録時、招待時、何かが起きたときのメールなどです。必要であれば、Step 1c のメールに関する質問につなげ、同じことを二度尋ねずに回答を引き継ぎます。
• 時間のかかる処理はありますか？ ファイルのインポート、レポートの生成、応答の遅いサービスへの呼び出し、スケジュールに沿った処理など、誰かを待たせずに実行すべき作業です。ほとんどのアプリにはありませんが、ある場合は、うまくいく場合の流れではなく、ここで話題になることが多いです。
• スマートフォン向けですか、それともデスクトップ向けですか？ 早い段階でレイアウトの判断に影響し、簡単に尋ねられます。
• バージョン1に意図的に含めないものは何ですか？ 率直に尋ねてください。対象外のものを明確にすることで、最初のバージョンをリリース可能な状態に保てます。また、推測で機能を追加せずに済みます。

通常、重要なのはこのうち2つか3つです。9つすべてを取り上げると尋問のようになります。作るものが変わる項目を選んでください。

Step 1c — 技術的な選択肢

次に、分岐する選択肢を確認します。ひとつずつ、推奨案を添えて尋ねてください。すでに聞いたことは尋ねないでください。説明から答えが明らかな場合（「有料ニュースレター」「写真日記」など）は、確認のためにさらっと伝えます。「有料で利用する人がいるようですね。そのように設定します。」

1. 「誰が使いますか？今のところ自分だけですか、それともほかの人や一般の人も使いますか？」 → 自分だけ／アイデアを試している段階：SQLiteを推奨します（「データはプロジェクト内のシンプルなファイルに保存されます。追加でインストールしたり、実行したりするものはありません」）。 → ほかの人も使う／本番運用を目指している：Postgresを推奨します（「多くの実際のアプリで使われているデータベースです。お使いのマシン上でDockerを使って動くので、起動は1つのコマンドだけで、恒久的にインストールするものはありません。本番環境でも同じデータベースを使えます」）。 → PostgresにはDocker Desktopがインストールされ、起動している必要があります。勧める前に確認してください。インストールされておらず、使う意思もない場合は、SQLiteまたは無料のホスト型Postgresを提案します。

2. 「サインインは必要ですか？」 → アカウントが不要なら、認証は完全に省略します。 → 必要な場合は、デフォルトとしてメールアドレス＋パスワードをおすすめします（「すぐに使えて、設定は不要です」）。 → 「Google でサインイン」を希望する場合は、対応できることを伝え、事前に期待値を調整します。無料の Google Cloud の設定が必要で、コピー＆ペーストを数回行います。一緒に設定するか、後から追加するかを提案します。

3. 「アドレスの確認、パスワードのリセット、何かが起きたことの通知など、アプリからメールを送る必要はありますか？」 → 不要なら、メール機能は完全に省略します。サインインは引き続き使えますが、追加するまではアドレスの確認やパスワードのリセットはできません。 → 必要な場合は、Resendをおすすめします。相手が持っていない可能性のあるものが必要になる唯一のコンポーネントなので、早い段階で正直に期待値を調整します。「自分宛ての送信ならすぐに使えます。それ以外の人にメールを送るには、ドメイン名といくつかの DNS レコードが必要です。所要時間は約10分で、無料です。」ドメインを持っていない場合も、そのまま進め、送信の手順はドメインを用意するまで保留になると伝えます。その間もほかの機能は使え、メールはターミナルに出力されます。 → サインインは不要と回答し、メールは必要と回答した場合も問題ありません。お問い合わせフォームや通知にアカウントは必要ありません。

4. 「写真、ドキュメント、プロフィール写真など、ユーザーが何かをアップロードしますか？」 → しない場合は、ファイルストレージを完全に省略します。 → する場合は、選択肢を提示する必要はないので、提示しません。どうなるかを説明します。「開発中は、アップロードしたファイルはプロジェクト内のフォルダーに保存されます。デプロイすると、自動的に適切なクラウドストレージに保存されます。同じコードのまま、ストレージを接続するだけです。」ユーザーから尋ねられた場合に限り、Vercel Blob の名前を出します。

5. 「サブスクリプションや一回限りの購入など、ユーザーが何かに支払うことはありますか？」 → ない場合は、決済機能を完全に省略します。 → ある場合は、Polarをおすすめします（「通常は厄介になりがちな世界各国の消費税や VAT を代わりに処理してくれます」）。すでに Stripe を使っている場合や、Stripe が必要な場合は、Stripeを選択肢として案内します。 → 決済にはアカウントが必要です。サインインは不要と回答した場合は、そのことを率直に伝えて追加します。「どのサブスクリプションが誰のものかをアプリが把握できるように、アカウントも必要です。」 → 期待値を調整します。すべてテストモードで設定されるため、実際のお金は動きません。本番環境への切り替えは、後でキーを交換するだけです。

6. 「チャットやテキスト・コンテンツの生成など、アプリに AI 機能は必要ですか？」 → AI 関連の仕組みを含めるのは、必要な場合だけです。必要な場合は、OpenRouter API キーが必要になること（無料で作成できます）と、取得場所を案内することを伝えます。1つのキーで多くのモデルを利用できます。

7. 「タブを閉じた後も続く作業や、スケジュールに沿って実行される作業など、自動で実行し続ける必要があるものはありますか？」 → デフォルトはいいえで、ほとんどのアプリはそのままにするべきです。レコードの保存、メール1通の送信、画像1枚のサイズ変更なら、サーバーアクションで十分に処理できます。ダッシュボード付きのジョブシステムを追加すると、そのためだけに余計な仕組みが増えます。 → 再起動後も作業を継続する必要がある場合、失敗後に自動で再試行する必要がある場合、スケジュールに沿った実行、複数項目への処理の振り分け、または数分から数日間の待機が必要な場合は、必要です。たとえば、スプレッドシートのインポート、レポートの生成、応答の遅い外部サービスの呼び出し、夜間のダイジェストなどです。 → 必要な場合は、Inngestをおすすめします（「アプリの外で作業を実行し、クラッシュした場合は中断したところから再開し、自動で再試行します。開発中は各ステップの進行状況を確認できます」）。無料で始められ、開発中はアカウントも不要です。

8. 「ほかのソフトウェアが、あなたに代わってこれを使えるようにしますか？ たとえば、自分でアプリを開かずに、Claude にエントリーの追加や要約の取得を頼めるようにしますか？」 → 本当にどちらかを選ぶ質問なので、そのまま尋ね、どちらかに誘導しないでください。「はい」の場合、アプリの主な操作も AI エージェントが呼び出せるツールになります。同じサインインと同じ権限が適用されます。Claude Code からはすぐに使え、アプリを公開された場所にデプロイすれば、Claude.ai や ChatGPT からも使えます。「いいえ」の場合は、ブラウザーで人がアプリを使います。それもまったく問題のない回答で、これまでに構築したものを何も変更せず、後から追加できます。 → 迷っている場合は、ツールは結局、アプリがすでに行える少数の操作と同じものになるため、主なコストはサインインの仕組みだと伝える価値があります。また、アクセス権を持つエージェントをすべて一覧表示し、アクセスを取り消すボタンがあるページも用意されます。 → 支払い機能と同様に、アカウントが必要です。サインインを「いいえ」と答えた場合は、障害として扱うのではなく、「エージェントはあなたとしてサインインする必要があります。そうすれば、アプリは誰のデータを扱っているのか把握できます」と一文で伝えてください。

9. 「サインアウトした状態でアプリを開いたとき、何を表示しますか？」 → 最初に表示する画面を決めます。他の人が登録するサービスなら正式なランディングページ、個人用ツールならアプリを直接表示します。マーケティングページが必要だと決めつけないでください。判断については references/pages.md を参照してください。

10. 「サインインしなくても読めるヘルプページをいくつか用意しますか？」 → 9 の回答が正式なランディングページだった場合にのみ尋ねてください。つまり、見知らぬ人が登録する製品、特に料金が発生する製品です。個人用ツールは使い方をすでに知っているユーザーが一人だけで、社内ツールのドキュメントはたいてい同僚三人へのメッセージ程度です。そこで尋ねると、誰も読まないものに「はい」と答えるよう促してしまいます。尋ねず、作らず、話題にも出さないでください。 → デフォルトはいいえです。「はい」の場合に実際に必要となる作業を伝えてください。画面が変わるたびに内容を正しく保つ必要がある、短いページを四〜六ページ作ります。希望する場合は、すでに聞いた内容をもとに作成するページを挙げてください。「はじめに、仕組み、プランと請求、Claude との接続」のように伝えれば、ドキュメントという概念ではなく、具体的なものに同意してもらえます。

11. 「検索エンジンや AI アシスタントがこれを見つけられるようにしますか？」 → アプリが公開されている場合にのみ尋ねてください。人々が登録する製品、またはコンテンツ自体が目的のサイトが該当します。個人用または社内用のツールでは尋ねないでください。その代わりに何をするのか、一文で伝えてください。「誰かに見つけてもらう必要はないので、ブラウザーのタブには適切な名前を付け、検索結果には表示されないようにします」。これが提供する内容であり、何もしないということではありません。 → 該当する場合、デフォルトははいで、対応は簡単です。サイトマップ、robots.txt、llms.txt、リンクが共有されたときに表示されるプレビューカードを用意します。上のドキュメントに関する質問が「はい」だった場合は、それらのページもインデックスに登録されると伝えてください。ほとんどの製品では、実際に検索されるのはその部分です。 → 補足の質問は一つだけで、アプリのコンテンツ自体が製品である場合（ブログやディレクトリなど）に限ります。AI クローラーによる学習を許可するかどうかです。検索や引用を行うクローラーは別物であり、許可する価値があります。そうすれば、アシスタントがリンク付きでアプリを推薦できます。二つの違いは references/seo.md で説明されています。

12. 「どのような見た目にしますか？」 → すべてのアプリに尋ねます。そして、尋ねるのは最後です。アプリが何であるかを把握してからでなければ、提案をする意味はありません。また、個人用ツールにもプロダクトと同じくらい明確な方向性が必要です。これは、すべての画面に関わる唯一の回答です。 → どの答え方が可能なのか分からない人もいるため、3つの方法をひと息で伝えます。「好きなように説明してください。『落ち着いたミニマルな感じ』『Linearのような見た目』『紙のように温かみのある感じ』など。すでにあるものを貼り付けても構いません。ブランドカラー、フォント、デザインドキュメント一式、スタイルガイドなどです。または『お任せ』と言っていただければ、こちらから案を出しますので、気に入らなければ遠慮なく却下してください。」 → 何かを貼り付けてもらった場合は、それをそのまま採用します。色、フォント、余白、トーン、コンポーネントの規約など、すべてを参考にするのではなく、提示されたとおりに使います。アプリに必要な要素が含まれていない場合（通常はダークモードや角丸など）は、その意図に沿って不足分を補い、どの部分がこちらの判断によるものかを伝えます。 → 言葉で答えてもらった場合は、形容詞ではなく具体的な決定事項として確認します。「落ち着いたミニマルな感じ」は、名前を付けたニュートラルなベースカラー、1つのアクセントカラー、大きめの角丸、具体的なフォントに置き換えます。そうすれば、雰囲気に同意するのではなく、具体的な内容を修正できます。 → 「お任せ」と言われた場合は、提案しましょう。もう一度尋ねてはいけません。 アプリの本質を踏まえた、実際に違いのある2、3案を、それぞれ固有の名前と1行の説明で提示します。開発者向けツール、子ども向けの読書記録アプリ、請求書アプリは、同じ見た目にするべきではありません。1案を推奨します。選び方についてはreferences/design.mdを参照してください。 → どの方法で回答を得た場合も、Step 4でその内容をプロジェクトルートの**DESIGN.md**にまとめ、それ以降に作成するすべてのページにその基準を適用します。

Step 2 — 現状を把握する

分岐を選んだら、次は、それらを実際に構築するために今何が必要かを調べます。作業はこの順番で2段階に分けます。まず、各ライブラリのメンテナーが公開しているスキルをインストールし、その後、それらのスキルでまだ答えが得られないことだけを調査します。 順番を逆にすると、インストールひとつで済んだ情報を再発見するために、調査の時間を費やすことになります。

Step 2a — 公式スキルをインストールする

shadcn、Vercel、Better Auth、Anthropic は、それぞれ自社のライブラリ向けにエージェントスキルを公開しています。これらは、各 API を提供する開発元自身が作成し、最新の状態に保っている手順書です。まとめて使えば、このビルドを構成する要素のほとんど――コンポーネント、React と Next のパターン、サインイン、AI SDK、MCP ツール――を網羅できます。これらを使わないエージェントは、ビルド中にすでにディスク上にあるドキュメントを探し回り、古いリリースに基づいたブログ記事にたどり着いてしまいます。

以下の調査とビルドシートに取りかかる前に、スキル一式をグローバルにインストールしてください。 グローバルに、つまり -g を付けてインストールする理由は 2 つあります。ユーザーが現在いるフォルダーは、これからアプリになります。また、create-next-app . は空でないディレクトリでは実行できません。プロジェクト単位でインストールすると、そこに .claude/ と skills-lock.json が作成され、ビルドのたびに回避策が必要になります。さらに、これらは特定のアプリではなく、決まったスタックに関するドキュメントです。一度インストールすれば、次のアプリでも、以降このアプリを開くすべてのセッションでも利用できます。

6 つのインストールには少し時間がかかるため、まず何をするのかを一言で伝えてください。「計画を立てる前に、これらのツールを開発している人たちが公開している手順書を取り込みます。あとでドキュメントを推測する手間を省けます。」その後、インストールを実行してください。

npx skills add https://github.com/shadcn-ui/ui --skill shadcn -g --agent claude-code -y
npx skills add https://github.com/vercel-labs/agent-skills --skill vercel-react-best-practices -g --agent claude-code -y
npx skills add https://github.com/vercel-labs/agent-skills --skill deploy-to-vercel -g --agent claude-code -y
npx skills add https://github.com/better-auth/skills --skill better-auth-best-practices -g --agent claude-code -y
npx skills add https://github.com/vercel/ai --skill ai-sdk -g --agent claude-code -y
npx skills add https://github.com/anthropics/skills --skill mcp-builder -g --agent claude-code -y

--agent claude-code -y を付けることで、各コマンドを非対話形式で実行できます。両方のフラグがないと、コマンドは応答する人がいないままプロンプトで停止します。分岐で選ばなかったものも含め、6 つすべてをインストールしてください。何かに読み込まれるまでは動作せず、分岐ごとの 2 つは、ユーザーが AI やエージェントのアクセスを追加する週に必要となるものです。

以前のアプリですでにインストール済みのものがあっても、6 つすべてを実行してください。 再追加は重複ではなく更新ですし、確認するより手軽です。このスキルを以前に実行したからインストール済みだろうと決めつけるのは、認められません。前回の記憶に頼らず、ビルド中にディスクから読み込んでください。

プロジェクトには何も作成されません。インストール先はユーザー自身の ~/.claude/skills/ なので、Step 4 で足場を作るフォルダーは空のままであり、create-next-app . は問題なく動作します。

それぞれのスキルを読むタイミングは次のとおりです。

スキル	読むタイミング
shadcn	コンポーネントの追加、組み合わせ、テーマ設定を行うとき。references/stack.md、pages.md、settings.md、docs.md
vercel-react-best-practices	React または Next のコード全般。サーバーコンポーネントとクライアントコンポーネント、データ取得、フォーム、キャッシュ、Step 5 の実ページなど
better-auth-best-practices	references/auth.md と、その後 src/lib/auth.ts を拡張するあらゆる機能――決済、エージェントアクセス、設定など
ai-sdk	references/ai.md
mcp-builder	references/mcp.md — ツールの設計、命名、ツールが返す内容
deploy-to-vercel	ビルド中には読みません。Step 8 での引き継ぎと、後日アプリをデプロイする担当者のためにインストールします

スキルと参照ファイルの内容が食い違う場合の優先順位。 以下の調査でも同じように使い分けます。API の詳細と、各ライブラリ固有の作法については公式スキルを優先してください――名前、シグネチャ、インポート、オプション、使用するフックやコンポーネント、現在推奨されているパターンなどです。アプリ内で各要素をどう連携させるかについては、このスキルの参照ファイルを優先してください――各ファイルの役割、スキーマ、セッション、ログ、設定領域との連携方法などです。参照ファイルが独自に実装している機能について、公式スキルに第一級の方法が示されている場合は、スキルの方法を採用して回避策を削除し、引き継ぎ時にそのことを伝えてください。

スキルによってスコープが決まるわけではありません。 公式スキルは、機能、プロバイダー、追加パッケージを気軽に推奨します。アプリの内容は、ユーザーと合意した Step 3 に従います。スキルが強く勧めているからといって、スコープを広げる理由にはなりません。

Step 2b — 残っているものを確認する

意図的に、このスキルではバージョンを指定していません。バージョンを調べるのはこの段階です。並列サブエージェントを 1 ラウンド実行するだけで済み、API が変更されたあとも気づかずにアプリを作り続けてしまうという、コストの高い失敗を防げます。 選択した各分岐につき、1 つのサブエージェントを割り当て、すべてを 1 つのメッセージで指示して同時に実行します。 対象にするのは、インタビューで選ばれた分岐だけです。料金を受け取らないアプリについて、決済を調査する意味はありません。ここでは、基本プロジェクト、データベース、ページのステップ、見つけやすさは常に分岐に含めます。

各エージェントには、担当するパッケージを埋めた同じ概要を渡します。また、ステップ 2a の表でその分岐にスキルが指定されている場合は、そのパスも渡します。

この分岐に <skill> スキルが指定されている場合は、まずそれを読みます。~/.claude/skills/ にインストールされている、メンテナー自身によるドキュメントであり、検索で見つかる情報より優先されます。そのスキルで答えられない点だけを調査し、調査結果のうち、どれがスキルに基づくものかを明記します。次に、<packages> の現在の安定版を確認します。以下を報告してください。各パッケージの最新安定版、過去 2 つのメジャーバージョン以内に非推奨になったもの、名称変更されたもの、別のパッケージに移動したもの、削除されたもの、このリファレンスファイルで使われている <the specific things this reference file uses> の現在のインポートパスと関数シグネチャ、references/<file>.md の手書きコードを置き換える機能がその後追加されていないか、そして記載内容に影響する移行上の注意事項。ブログ記事や検索結果の要約より、パッケージ独自のドキュメントや変更履歴を優先し、ドキュメントページの記載だけに頼らず、レジストリで実際に公開されている内容を確認します。一次情報で確認したことと、推測したことを明確に分けてください。

エージェントアクセスの分岐には、パッケージ以外にも変化するものがあるため、概要に追加の文を 1 つ加えます。Model Context Protocol 仕様の現在のリビジョンを特定し、references/mcp.md の前提を、そのリビジョンの変更履歴と非推奨機能の一覧に照らして確認します。 パッケージの名称も関数シグネチャも変わっていないのに、プロトコルのリビジョンによってファイルが依存する機能が非推奨になることがあります。上記の概要だけでは、そうした変更を見逃します。ライブラリとは別にバージョン管理される仕様があるのは、ほかの分岐にはありません。

見つけやすさの分岐ではパッケージをインストールせず、慣習を調査するため、専用の概要を渡します。*sitemap、robots、opengraph-image に関する Next の現在の MetadataRoute ファイル規約を確認します。また、アプリを見つけてもらうことを想定している場合に限り、AI クローラーの現在のユーザーエージェントトークンを、トレーニング用、検索・引用用、ユーザー起動用に分けて特定し、llms.txt が提案段階を超えて、名称が明らかなクローラーに読み取りを明記されるまでに至っているか確認します。クローラーの名称は予告なく変わります。robots.ts に誤った名称を書いてもエラーにはならず、どのクローラーにも一致しないルールが何も通知せずに適用されるだけです。

各リファレンスファイルの先頭には Last verified の日付があります。調査の深さを決める際に活用してください。最近確認されたファイルは確認程度でよく、1 年前に確認されたファイルは、何かが変わっている前提で調べます。

何かをインストールする前に、調査結果を突き合わせます。

• 最新の安定版のみを使用します。 リリース候補版、ベータ版、next や canary タグは使用しません。ただし、ユーザーが特定のものを求め、その理由を理解している場合は除きます。
• 新しい機能がある場合は、それを使います。 参照ファイルには、ライブラリでまだ実現できなかったため、独自に実装している処理が含まれていることがあります。現在は実現できるなら、組み込み機能を使い、回避策を削除します。該当する可能性が高い箇所は、references/mcp.md に具体的に記載されています。
• API の詳細は調査結果を優先し、各要素の連携方法はこのスキルを優先します。 名前、シグネチャ、インポートパス、オプション、フラグには調査結果を採用します。どの要素が何を担い、アプリのほかの部分とどう連携するかは、参照ファイルに従います。ほとんどの参照ファイルでは、それぞれの依存関係について冒頭でこの分担を説明しています。
• 調査結果とインストール済みのスキルが食い違う場合は、どのような食い違いかを確認します。 現時点で公開されている内容、たとえばバージョン、分割されたパッケージ、変更されたシグネチャについては、レジストリの情報が事実であり、調査結果を優先します。スキルはファイルであり、ファイルは古くなるためです。どちらも動作する複数のパターンからどれを使うかについては、公式スキルを優先します。これは、そのライブラリの作者による指針だからです。スキルが説明している機能について、レジストリがすでに存在しないと示している場合は、引き継ぎ時にその旨を伝えます。メンテナーのスキルが古くなっていることを知っておく価値があります。
• 参照ファイルの手法が非推奨になっている場合は、代替手段を採用し、それで作業を完了します。 折衷案にはしません。
• 変更があった場合にのみ、ユーザーに伝えます。 簡潔に一文で伝えます。「この文書の作成後、Better Auth の機能は別パッケージに移動しました。新しいパッケージを使用します。」のようにします。調査の結果、問題がなかったことを説明する必要はありません。余計な情報に見えるためです。
• 古くなっている情報を記録します。 調査によって矛盾が確認された事項は、最後の引き継ぎに記載し、このスキルを修正できるようにします。

ステップ 3 — ビルドシート

何かに手を付ける前に、計画を平易な言葉で言い直します。例：

これから設定する内容はこちらです：「TrailLog」 — あなただけのハイキング日記です。

記録する内容： ハイキング — 日付、トレイル、距離、どんな気分だったか、写真。 できること： ハイキングを記録する、あとで編集する、削除する、新しい順に見る。 サインイン： メールアドレスとパスワードで、あなた専用です。 見た目： 落ち着いたアウトドア風です。温かみのあるオフホワイトの背景、深いグリーンのアクセント、柔らかな角、見出しにはセリフ体を使います。すべての画面で統一されるよう、DESIGN.md に記録します。 写真： 開発中はプロジェクト内に保存し、デプロイ時にクラウドストレージへ移します。 Claude から： アプリを開かなくても、Claude 自体からハイキングを記録したり、過去のハイキングについて尋ねたりできます。また、そのアクセスをアプリ内で確認して取り消せます。 そのほか： パスワードの変更とアカウントの削除ができる設定ページと、設定内容やこれまでの動作を表示するシステムページを含みます。 法務： あなただけが使うもので、ここでは誰の追跡もしないため、プライバシーポリシーも利用規約もクッキーバナーも不要です。 検索で見つけてもらうこと： あなただけが使うものなので、インデックス登録するものはありません。ブラウザーのタブには適切な名前を付け、検索結果には表示されないようにします。 バージョン 1 には含めないもの： 友人とのハイキングの共有、地図、統計ページ — 基本機能がしっくりきたあとで簡単に追加できます。

これでよさそうですか？

データモデルと、明確なバージョン 1 には含めないもののリストを含めてください。この 2 行が、あとからの作り直しを防ぎます。法務の行はどちらの場合も入れ、質問ではなく説明にします。この例では、何も必要ない理由を述べています。一般公開するプロダクトなら、代わりにどのページを用意するかを明記します。判断の根拠は references/legal.md にあります。検索で見つけてもらうことの行も、どちらの場合も入れます。この例では、より難しいケースを示しています。意図的に検索対象から除外するアプリでも、その行は必要です。「SEO なし」だけでは、何も書かれていない状態が忘れられたように見えるためです。一般公開するプロダクトなら、代わりに用意するものを明記します。サイトマップ、robots.txt、llms.txt、共有リンク用のプレビューカードです。ヘルプページの行は、ドキュメントが必要か尋ねて、必要との回答があった場合にのみ加えます。ドキュメントを用意すると約束するのではなく、ページ名を挙げます。見た目の行はすべてのシートに含め、デザインの手直しを低コストで行うために使います。雰囲気ではなく、背景、アクセント、角、フォントといった具体的な判断を挙げてください。「すっきりしていてモダン」は誰も異論を唱えられず、つまり誰も合意したことにならないからです。デザインシステムが貼り付けられていた場合は、それを使うと伝え、自分で補う必要があった点も明記します。また、動作にあたって相手側で必要なもの（Docker の起動、API キー、メール用のドメイン、プロバイダーのアカウントなど）も伝え、ビルドの途中で予想外のことが起きないようにします。

明確な了承を得てください。異論があれば調整します。回答によって細部の修正ではなくアプリの本質が見直される場合は、ステップ 1a に戻ってください。スキーマができてからよりも、今のほうが低コストです。

ステップ 4 — スキャフォールド

以下を順番に進めます。各リファレンスには検証セクションがあります。次へ進む前に完了してください。これは作業中に行う自分自身のチェックです。コマンドを通過する必要があるのはステップ 6 です。記載されているパスはすべて、現在の作業ディレクトリからの相対パスです。

ステップ 2a でインストールしたスキルは、ビルドに失敗してからではなく、これらのファイルと並行して読みます。 どのスキルがどのステップに対応するかは、そこの表にあります。shadcn と vercel-react-best-practices はほぼすべてのステップに適用され、better-auth-best-practices はサインイン以降、ai-sdk と mcp-builder はそれぞれのステップで使います。そのファイルのコードを書く前に、関連するスキルを読んでください。このステップで避けるのは、すでにこのマシンにインストールされている答えをウェブで検索するという、まさにその無駄です。 ステップ 2 以降は、これらのステップで構築するすべての画面を DESIGN.md が規定します。設定エリア、メール、同意画面、法務ページ、ドキュメントが対象です。どの画面でもアプリの見た目を独自に決め直すことはなく、コンポーネントに色、フォントサイズ、角丸の値を書き込むこともありません。

1. ベースプロジェクト → references/stack.md
2. デザインシステム → references/design.md（常に実行。DESIGN.md、テーマトークン、AGENTS.md、CLAUDE.md を作成します）
3. データベース（SQLite または Docker 上の Postgres 分岐）→ references/database.md
4. サインインを選択した場合（メールアドレス＋パスワード、任意で Google）→ references/auth.md
5. メールを選択した場合 → references/email.md（サインインの手順を実行した場合は、メール認証とパスワードリセットも設定します）
6. ファイルアップロードを選択した場合 → references/storage.md
7. 決済を選択した場合 → references/payments.md（サインインが必要です）
8. AI 機能を選択した場合 → references/ai.md
9. バックグラウンドジョブを選択した場合 → references/jobs.md
10. ランディングページとダッシュボード → references/pages.md
11. エージェントアクセスを選択した場合 → references/mcp.md（サインインが必要です）
12. 公開ドキュメントを選択した場合 → references/docs.md（まれです。公開プロダクトで、依頼され、希望すると回答された場合のみ）
13. 法務ページと Cookie の同意（このアプリで必要な範囲）→ references/legal.md（判断して実行し、質問はしません。多くの場合は何もありません）
14. アカウント設定 → references/settings.md（サインインが必要です。サインインがない場合のみスキップします）
15. システムの可視性 → references/ops.md（常に実行）
16. 発見されやすさ → references/seo.md（常に実行しますが、ほとんどのアプリでは、適切なタイトルを付けて検索対象から除外することを意味します）

デザインシステムをスキャフォールドの直後、2 番目に配置するのは、後続のすべての手順が参照する唯一のステップだからです。 プロジェクトが存在している必要があります。編集対象となるのは globals.css と layout.tsx だからです。また、画面を 1 つでも構築する前に整えておく必要があります。すでに作成したページに後からテーマを適用するには、すべてのページを編集しなければならないためです。ここでは AGENTS.md と CLAUDE.md も作成するので、以降のすべてのステップと、後からこのプロジェクトを開くすべてのエージェントに、同じドキュメントを遵守させられます。

それ以外の順序も重要です。決済、アップロード、エージェントアクセスは、いずれもサインインの手順で構築したものを拡張します。ページの手順には、それらがすべて揃っている必要があります。また、設定とシステムの可視性は、ページの手順で作成するナビゲーションに依存します。エージェントアクセスをページの手順の後に置くのは、同意画面をアプリのほかの画面と同じ見た目にする必要があるためです。また、各手順は実行された場合にのみセクションを追加するので、それらの後に置きます。ドキュメントは、存在する分岐についてのみ説明できるため、その次に置きます。また、法務のフッター確認時にドキュメントへのリンクがすでにあるよう、法務より前に置きます。法務は、すべての機能分岐について説明する必要があるため、その逆の理由でそれらすべての後に置きます。また、Cookie バナーを作成した場合にのみ Cookie 設定セクションが追加される設定より前に置きます。src/lib/auth.ts を変更する作業があれば、Better Auth のスキーマを再生成し、db:generate と db:migrate をもう一度実行する必要があります。どこで行うかはリファレンスファイルに記載されています。

発見されやすさを最後にするのは、すべての公開ページを把握していなければならない唯一のステップだからです。 1 つのリストからサイトマップと llms.txt を作成し、法務とドキュメントの両方がそのリストにページを追加します。そのため、先にサイトマップを作成すると、それらの手順を実行した時点で内容が間違ってしまいます。

最後の 3 つは、時間が足りないときに省略する仕上げの作業ではありません。そのうち 2 つはスキャフォールドをユーザーが操作できるものにし、残りの 1 つは誰かに見つけてもらえるかどうかを左右します。

ステップ 5 — その人のものにする

これは仕上げの工程ではありません。価値の大部分を占めます。ステップ 4 で用意した足場はインフラです。ここでアプリが、その人のものだとはっきり分かる姿になります。

• プロジェクト名は、その人のアイデアにちなんだものにします（パッケージ名、ページタイトル、画面に表示されるブランディング）。
• スキーマのテーブルには、ステップ 1a の名詞を使います。各テーブルに UUID の主キーを設定し、ステップ 1b の所有権ルールを適用します。データがプライベートな場合は、userId カラム（text、Better Auth と一致）を設け、すべてのクエリでそのユーザーにスコープを絞ります。
• 実際のページを作ります。references/pages.md にあるトップページとダッシュボード、実際のナビゲーション、そしてステップ 1a の動詞を機能として組み込みます。ギャップチェックで必要と判断された場合は、編集や削除も含めます。ここがアプリの中で最も密度の高い React コードであり、vercel-react-best-practices の導入が活きる部分です。サーバーコンポーネントとクライアントコンポーネントの使い分け、データを取得する場所、フォームの動作を考えます。shadcn コンポーネントを組み合わせて画面を作り、それらしきマークアップを手書きするのは避け、DESIGN.md に沿って構築します。デザインの決定はすでに済み、合意も取れているため、このステップでは色を選び直すのではなく、アプリ自体に判断力を注ぎます。
• 汎用的な内容は一切入れません。画面に表示される文字列はすべて、そのアプリにふさわしい内容にします。「Item」も「Welcome to Next.js」も、lorem ipsum も使いません。設定画面、メール、法的ページ、ドキュメント、そしてブラウザーのタブも対象です。アプリが一度も送信しない通知のカテゴリが並ぶ「Notifications」セクション、「My App」と署名されたメール、ほかのすべての画面では「hikes」と表示しているのに「user-generated items」について書かれたプライバシーポリシー、あるいは「Create Next App」と表示されたままのタブは、どれも lorem ipsum のページと同じ失敗です。
• このアプリにある設定セクションだけを作ります。空の「Billing」タブや、メールを送信しないアプリの「Notifications」タブを作るくらいなら、ないほうがましです。
• エージェントアクセスを選んだ場合は、ツールにも動詞を使った名前を付けます。create_item ではなく log_hike のようにします。テーブルごとに 1 つではなく、実際にユーザーが依頼するであろう、少数のツールに絞ります。
• 完了の条件：アプリを開いた人が、説明されなくても何のアプリか分かり、ユーザーがアプリの主な目的を最初から最後まで実行できることです。

ステップ 6 — 動作を確認する

アプリはできました。しかし、動作することを確かめたものは何もありません。完了したばかりの各 Verify セクションは、確認対象のコードを書いたのと同じエージェントが検証しています。記憶に頼っても証拠にはなりません。すべての確認項目を満たしていても、コンパイルに失敗するアプリはありえます。

references/verify.md には、型、スキーマの差分、ビルド、lint、本番モードでのアプリの起動、すべてのルートへの応答、2 つのアカウント間の確認、キーを取り上げた状態でのアプリの確認に使うコマンドが記載されています。それぞれの出力を読みます。コマンドが検査するコードを書いたことは、そのコマンドを実行する理由であって、省略する理由ではありません。

ここで伝えておくべき重要な注意点が 2 つあります。どちらも、間違えると問題が起きます。

• ビルドの前にスキーマを確認します。 build は最初に db:migrate を実行するため、未生成のスキーマ変更を残したまま実行すると、誰も内容を読んでいない SQL が適用されます。これは、references/database.md が決して行わないよう指示していることであり、それを検出するためのステップで実行してしまうことになります。
• プローブ用アカウントを作成する前に、ユーザー本人がサインアップします。 最初に作成されたアカウントが管理者になります。代わりにフィクスチャを作成してから削除すると、ユーザーは自分のシステムページにアクセスできなくなります。

ブラウザー、プロバイダー、または人が必要な確認項目は、references/verify.md に記載されています。実行できなかった項目を明記します。

ステップ 7 — 新たな視点

ゲートで確認できるのは、アプリがビルドされ、配信され、応答することです。アプリが実際に何かをするかどうかは確認できません。空のプロジェクトでも、漏れるものがなければすべてのコマンドを通過するからです。そこで最後に、ビルダー自身にはできない確認を行います。

批評担当エージェントには、ステップ 2 と同じように、一度のメッセージですべてに指示を出して同時に実行させます。 約束の遵守と見た目の一致は常に確認し、サインインがある場合は所有権を確認し、実行可能性は実行された分岐に応じて調整します。依頼内容は references/verify.md にあります。

確認するのは、ステップ 3 のビルドシートに対するアプリの適合性だけです。 このシートだけが基準です。ユーザーが実際に承認した唯一のものだからです。ユーザーは、渡されたコードを読めないまま、アプリの説明を承認しています。その隔たりを埋めることが、この作業のすべてです。批評担当エージェントは、アプリがシートから逸脱している箇所を報告します。別のシートを提案することはありません。アプリの本質を変えるものは、ステップ 3 のときと同様に、引き渡し時にユーザーに確認します。

実行中のアプリではなく、証拠を確認します。4 つのエージェントがポートやブラウザーを共有することはできないため、ステップ 6 の間にすべてを一度だけ記録して、エージェントに渡します。指摘事項は broken、missing、worth knowing として返されます。今すぐ修正するのは最初の 2 つだけで、ゲートを広げたり、スコープを変更したりする修正は行いません。

2 ラウンドで終了し、残ったことを報告します。 3 ラウンド目になると、エージェントは報告を消すために理解していないコードを編集し始めます。このステップを実行中であることを、ユーザーに一行で伝えてください。そうしないと、ユーザーは何も起きていないターミナルを眺めることになります。

ステップ 8 — 引き継ぎ

• 実行できなかったチェックはすべて、必要なもの（ブラウザー、ドメイン、決済キーなど）とともに、アプリを開いてから1分で確認できる短いリストとして示します。ステップ 7 の後も未修正の指摘事項や、異議を唱えた指摘事項も、理由とともに1行ずつここに記載します。
• ステップ 2 の調査結果と矛盾していた内容や、その場で変更する必要があった参照コマンドは、最後に、該当ファイルと問題点を明記します。そうすることで、このスキルを修正できます。ユーザーには1行で伝えてください。修正するのがユーザー本人かもしれません。
• 法務関連の分岐：プライバシーと利用規約のページは、法的助言ではなく、アプリの実際の動作をもとにまとめた初稿であることを、簡潔に一度伝えます。そのうえで、src/lib/legal.ts にある、ユーザー自身でしか入力できない項目（通常は連絡先住所と利用規約に適用される法律）を、1分で確認できる短いリストにします。Cookie バナーがない場合は、その理由と、どのような場合に追加が必要になるかを一行で伝えます。「このアプリでは誰の行動も追跡しないため、同意を得る必要もありません。後からアナリティクスを追加する場合は、バナーが必要になります。」
• 検索対象外にする場合の検索可能性：切り替え箇所が2つあることを示します。src/app/layout.tsx の robots: { index: false } と src/app/robots.ts です。アプリを公開することになったら、ここを変更します。公開した製品で設定をそのままにしておくと、期待していた訪問者をすべて逃すことになり、しかもそのことに気づけません。
• 公開する場合の検索可能性：サイトマップは検索順位を保証するものではなく、クローラーへの案内にすぎないこと、llms.txt は主要な AI クローラーが読み取りを約束していない提案段階の規約であること、そしてクローラーに実際に許可されている内容は robots.txt だけで決まることを、はっきり伝えます。プレビューカードも一度案内してください。共有リンクがどのように表示されるかを示すもので、アプリが最初に評価されるポイントです。
• ドキュメント関連の分岐：ページ数と、内容が現時点で正確であることを伝えます。そのため、ドキュメントは最初に古くなるものです。フローの説明が必要で、いずれかのページを書くのが難しかった場合は、そのページを伝えます。それはページではなく、アプリに関する指摘事項です。
• このビルドでは、メンテナー自身のスキル（shadcn、Vercel、Better Auth、AI SDK、MCP のスキル）を参照したことを、一度だけ一行で伝えます。これらはステップ 2a で一度インストールされ、このマシン上のすべてのプロジェクトで利用でき、npx skills update -g で更新されます。アプリのフォルダーには何も追加されていません。まだ使用していないものとして deploy-to-vercel を挙げます。準備ができたときにアプリをオンラインにするためのスキルです。
• 最後に、わかりやすくまとめます。アプリの起動方法（Postgres が Docker 上にある場合の pnpm db:up も含む）、.env の各項目の用途、そして妥当な次のステップを2、3個示します。
• DESIGN.md も一行で案内します。アプリの見た目を記したファイルであり、AGENTS.md と CLAUDE.md はエージェントをここへ誘導します。ここで色を変更し、globals.css でも同じ色を変更すると、すべてのページのスタイルが一度に変わります。どの部分をユーザーが提供し、どの部分をこちらが提案したのかも伝えます。変更したくなる可能性が最も高いのは、提案した部分です。
• システムページを示し、その用途を説明します。「なぜメールが届かなかったのか」「まだ稼働しているのか」という疑問に答えるページですが、ユーザーが自分で見つけることはありません。
• ローカル環境と本番環境で異なる箇所がある場合は、一度だけ行う切り替えを具体的に説明します。アップロード用に Blob ストアを接続し、POSTGRES_URL をホストされたデータベースに向け、決済キーをテストモードから切り替え、ドメインの確認が済んだら Resend キーを追加し、Inngest のキーを追加してアプリを同期し、エージェントトークンが実ドメイン向けに発行されるよう BETTER_AUTH_URL を実ドメインに設定し、サイトマップ、正規リンク、プレビューカードに localhost が残らないよう APP_URL も同じ実ドメインに設定します。どれもコードの変更ではなく、ホスト側での設定です。ここが難しいと思われがちな点なので、そのことも伝えてください。ホスト側以外の操作も必要なものは2つです。DNS でメールドメインを確認することと、初回デプロイ後にアプリを Inngest と同期することを、名前を挙げて説明してください。