プロンプティング

より速く望む結果に近づくプロンプトの書き方。

具体的に書く

詳細を伝えれば伝えるほど、結果が良くなります。

✗ 曖昧な例

「アプリを作って」

「ページを追加して」

「ボタンを修正して」

✓ 具体的な例

「毎日の習慣を記録し、完了マークを付けて、7日間の連続記録を確認できる習慣トラッカーを作って。」

「ユーザーの直近 7 回のチェックインをテーブルで表示するダッシュボードページを追加して。」

「ランディングページのサインアップボタンをグレーではなく青（#2563eb）にして。」

ユーザーが見るもの、操作したときに何が起きるか、明示的にスコープ外のものを含めてください。

小さく始める

まだ有用なアイデアの最小バージョンを説明しましょう。コアを構築し、動作することを確認してから拡張してください。間違った方向で大きく構築してしまったものを修正するよりも、機能を段階的に追加する方がずっと簡単です。

一度に一つの変更

フォローアップメッセージは一つのことだけを求めるべきです。一つのメッセージで複数の変更を依頼すると、予測できない結果になることが多いです。何かが壊れた場合、メッセージごとに一つの変更にしておけば原因を追跡しやすくなります。

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

アプリの大部分に影響を与える可能性があるプロンプトの前には、まずDiscuss modeに切り替えましょう。MonstarX にどのようにアプローチするかを聞いてから、構築をトリガーしてください。アプローチが合意できたらプロンプトを送信しましょう。

具体的に名前を付ける

既存のものを変更する場合は、そのまま表示されているとおりに説明してください。

曖昧な例	具体的な例
「ボタンを修正して」	「ランディングページのサインアップボタンを青（#2563eb）に変更して」
「ヘッダーを修正して」	「モバイルでナビバーがヒーローに重なっています。ナビが上に来るように z-index を修正して。」

最初のプロンプトのテンプレート

新しいプロジェクトを開始する際はこの構成を使いましょう。

Build [a short description].

Users can:
- [action 1]
- [action 2]

Requirements:
- [any services or constraints]

Out of scope:
- [what not to include in this version]

バグ報告のテンプレート

何かが壊れているときはこのフォーマットを使いましょう。

Bug: [what is broken]
Steps: [what I did, and what happened]
Expected: [what should have happened]
Do not change: [what is working correctly]

クイックリファレンス

• プロジェクトを開始する — 具体的に書き、スコープを設定し、スコープ外を列挙する
• 変更を加える — 一度に一つ、具体的に名前を付ける
• 大きな変更の前 — まず Discuss mode を使う
• 何かが壊れた — 再現手順を添えてバグを報告する
• 2〜3 回試して行き詰まった — Discuss mode を使って別のアプローチを聞く