ベストプラクティス

時間を節約し、再構築の回数を減らすためのいくつかの習慣です。

明確な概要書から始める

最初のメッセージを入力する前に、少し時間を取って以下を定義してください。

• アプリが何をするか、一文で
• 誰が使うか
• ユーザーが行う必要がある最も重要な 3 つのこと
• このバージョンのスコープ外のもの

明確な概要書は、確認のための往復質問を減らし、プランをより的確にし、意図通りの構築を最初から実現します。

承認前にプランを読む

プランは構築が始まる前の唯一のチェックポイントです。おかしいと思うことがあれば、承認前に修正してください。プランの修正は数秒で済みますが、構築済みのアプリの修正はずっと時間がかかります。

フェーズに分けて構築する

アイデアの最小限の有用なバージョンから始めましょう。それが機能することを確認し、正しいことを確かめてから、次の部分を追加します。一度にすべてを構築しようとすると、プランが広くなり、予期しない事態が増え、修正も難しくなります。

大きな変更の前に Discuss mode を使う

アプリの重要な部分に触れるプロンプトの前には、まずDiscuss modeを使いましょう。再構築にコミットせずにアプローチを話し合ってください。これは身につけておくべき最も効果的な習慣の一つです。

一度に一つの変更

フォローアップメッセージは一つのことだけを行うべきです。何かが壊れた場合、メッセージごとに一つの変更にしておけば、原因を特定しやすくなります。

UI が安定してからサービスを接続する

アプリの見た目と動作が望む通りになった後に Supabase、Stripe などのサービスをセットアップしましょう。データベースを接続した後にフロントエンドを変更すると、両者が同期しなくなることがあります。

構築中はテストの認証情報を使う

開発中は（Stripe の pk_test_... のような）テスト API キーを使いましょう。本番キーへの切り替えはリリース準備ができたときだけにしてください。これにより、テスト中に実際の課金や実際のメール送信を避けられます。

推奨される構築順序

後戻りを避けるために、この順序に従ってください。

1. 概要書を書く
   ↓ 誰が使うか、何をするか、スコープ外は何か
2. プランを説明して承認する
   ↓ 承認前に修正する — 構築済みアプリの修正よりずっと速い
3. コアとなる UI を構築する
   ↓ まずレイアウトとナビゲーションを正しくする
4. Preview でテストする
   ↓ 実際のユーザーのようにすべてのフローをクリックする
5. サービスを接続する
   ↓ Supabase、Stripe、Resend — UI が安定した後のみ
6. 最終確認 → 公開する
   ↓ 下のチェックリストでライブ前に確認する

公開前チェックリスト

公開する前に、このチェックリストを確認してください。

• [ ] すべての必須サービスが接続されている
• [ ] アプリが Preview で正しく読み込まれる
• [ ] コアとなるフローがエンドツーエンドで動作する
• [ ] ログアウトしてログインし直した後でもテスト済み