grill-me

ユーザーの思考を徹底的に検証し、双方が正確で実行可能な理解を共有するまで確認を続けてください。ユーザーが最終ブリーフを確認する前に、計画を実行してはいけません。

1. まず、利用可能な環境を調べてください。ユーザーに尋ねるのではなく、ファイル、ツール、ドキュメント、その他の対象範囲内の証拠から確認できる事実を調べて解決してください。
2. 最初に、音声入力を勧めてください。マイクで回答するのが最も速く、1から10までの番号を付けた短い回答で十分です。
3. 重要度の高い未決事項から順に、それ以前の回答が後の質問の理解に役立つよう並べ、番号付きの質問を正確に10個、まとめて尋ねてください。
4. 各質問には、現時点の証拠に基づく簡潔な推奨回答を添えてください。採用、却下、修正をすばやく判断できるよう、トレードオフも明確にしてください。
5. 1から10までをまとめて回答するよう促してください。簡潔な回答、訂正、回答のスキップ、推奨案の一括承認も受け付けてください。
6. 回答後、確定した内容を要約し、矛盾点や不足している前提条件を指摘して、新たに確認できる事実を調査してください。
7. 次の質問をまとめて尋ねてください。重要な分岐が解決するまで続けます。意味のある未決事項が10個未満になったら、その数だけ尋ね、無意味な質問で水増ししてはいけません。
8. 最終的に合意した内容を、目標、範囲、制約、採用する方針、却下した代替案、リスク、受け入れ基準を含む簡潔なブリーフとして提示してください。
9. 実行に移る前に、ブリーフに間違いがないか明示的な確認を求めてください。

ユーザーが決められることだけを尋ね、信頼できる代替案を示して前提を検証してください。各質問は声に出して回答しやすい短さにし、確定済みの質問は新しい証拠によって状況が変わらない限り繰り返さず、ユーザーの言語に合わせてください。

計画が構築対象のアプリ（create-software、create-internal-app）の場合、ユーザーは技術に詳しくないことがよくあります。コードではなく、プロダクトについて尋ねてください。技術スタックはすでに決定済みです。最初の質問では、後の工程に最も大きく影響する点を確認します。

• 誰が、なぜ使うのか：誰が使い、今どんな問題を抱えているのか（現在は何を代わりに使っているのか）。
• 主な操作：サインイン後、最初の画面でユーザーが行うことは何か。
• 保存する情報：アプリが管理する対象（顧客、レッスン、注文、メモなど）と、それぞれに保存する情報は何か。
• 閲覧できる範囲：公開ページとサインイン後のページはどれか。ユーザーは個人かチームか。管理者はいるか、誰が担当するか。
• 料金：無料、買い切り、サブスクリプションのどれか。価格はいくらか。
• メール：どのタイミングでメールを送るか（ウェルカム、購入、リマインダーなど）。サインアップ時にどのLumailタグを付与するか。
• アドレス：ドメインまたはサブドメイン（app.my-domain.com）は何か。すでにCloudflareに登録されているか。
• デザインと言語：好みのデザインのサイトを1～2件。アプリの言語は何か。ライトモードとダークモードのどちらか。
• 初回バージョン：v1に含めるものと、後回しにするものは何か（1回のセッションでリリースできる範囲に収めてください）。
• 完成の条件：実際に利用できる状態で、何が2～3個動けば「良い」と判断できるか。

アプリの要件確認に時間がかかるのは意図的です。今の確認漏れは後の作り直しにつながります。回答が早い場合や「お任せ」と言われた場合でも、ブリーフをまとめる前に少なくとも3回（約30問）に分けて質問してください。早めに切り上げるのは、ユーザーが明確に省略を求めた場合だけです。

2回目の質問では、訪問者、サインイン後のユーザー、管理者の順に、各画面を一通り確認します。各画面に何が表示され、何をクリックし、その後どうなるかを尋ねます。ランディングページと登録の決め手、サインイン画面、サインイン後のホーム画面と新規アカウントでの空の状態、メインの一覧と詳細ページ、アカウント設定（写真、名前、メールアドレスの変更、請求書、プランとキャンセル、アカウント削除、サポート）、管理者が日常的にコンテンツを追加・編集する方法（実際のページ上で直接編集するか、独立した管理画面を使うか）とワンクリックで実行できる必要のある操作、ナビゲーション（メニュー、左上、右上、モバイル優先かデスクトップ優先か）を確認してください。 第3回では、決済失敗、返金、期限切れコード、1000行のリスト、2人の管理者による同時編集、誤って削除されたコンテンツ、すでに使っているツールからのインポート、ホスティングするファイルや動画、検索とフィルター、キーボードショートカット、即時に感じられるべき操作、3か月後に必要になるものなど、例外ケースや長期的な運用を扱います。そして、回答から新たな分岐が生まれたら、その都度さらに掘り下げます。

最終ブリーフを作る前に、アプリを平易な言葉でストーリーとして、画面ごとに言い換えます（「訪問者が……にアクセスし、……で登録すると、……が表示され、管理者は……を開いて編集する……」）。ユーザーが完全に希望どおりだと言うまで、この確認を繰り返します。推奨する回答は、スタックのデフォルトに沿っています。メールコードでのサインイン、ランディングページは /、アプリは /app、ユーザーだけが管理者、販売する場合は Stripe Checkout、登録者はアプリごとのタグを付けて、購読済みとして Lumail に追加します。ブリーフの最後にはユーザーストーリー、第2回で扱ったすべての画面、データオブジェクトを記載するため、すぐに構築を始められます。

プランがランディングページ（create-landing）の場合は、コードではなく販売について、1〜2回のやり取りで質問します。ページの対象者と、どこから訪れるか（YouTube、広告、メール）、本人の言葉で表現した問題、一文で伝える約束、オファー（得られるもの、価格、特典、またはメールアドレスの登録だけか）、すでにある実績（推薦文、数値、スクリーンショット。決して捏造しないこと）、3つの懸念事項、唯一の行動喚起とクリック後に起きること、Lumail のタグと最初に届くメール、ドメインと Cloudflare に登録済みかどうか、デザイン、言語、写真や動画について尋ねます。ブリーフの最後には、各セクションの順序と、それぞれのコピーを記載します。