プロンプト

迷ったら、この3型。

長い「魔法の呪文」は不要です。質問、選択、検証のどれかを足すと、途中のズレを見つけやすくなります。

先に質問させる型

要件が曖昧なまま実装へ進ませず、AskUserQuestion で重要な判断だけを聞かせます。回答は SPEC.md に固定し、その後の実装で参照させます。

まだ実装しないでください。
まず現状のファイルを読み、完成形を決めるために必要な質問を
AskUserQuestionで最大3つしてください。

私の回答後に、決まったこと・未決定・完了条件をSPEC.mdへ書いてください。
SPEC.mdを私に見せ、確認を受けるまで実装しないでください。

AskUserQuestion公式 / 計画と要件の公式ベストプラクティス

候補を出させて選ぶ型

正解が1つでないときは、変更前に比較材料を出させます。候補ごとに長所・短所・変更範囲を揃えると、好みだけでなく影響も見て選べます。

まだファイルは変更しないでください。
この目的を達成する方法を3案出してください。

各案に次を付けてください。
- 何が変わるか
- 長所
- 短所
- 変更するファイル

最後に、初心者向けの推奨案を1つと、その理由を1行で示してください。

公式ベストプラクティス / 公式ワークフロー集

検証手段をセットで渡す型

「作って」で終わらせず、成功を判定するコマンドや画面条件を同じ依頼に入れます。公式ガイドも、テスト・スクリーンショット・期待出力など、Claudeが確認できる手段を渡すことを勧めています。

この変更を実装してください。

完了条件:
- `npm test` が成功する
- 幅390pxで横スクロールが出ない
- 変更前からある機能を壊さない

実装後に上の条件を実際に確認してください。
失敗した項目があれば1つずつ直して再確認し、
最後に「通った条件」と「できなかったこと」を分けて報告してください。

検証方法を渡す公式ベストプラクティス / Claude Codeの検証ループ

共通ルールは1つ

目的、触ってよい範囲、完了条件の3点を具体的にします。毎回繰り返す約束だけを CLAUDE.md へ移し、個別の依頼はプロンプトへ残します。

CLAUDE.md公式 / 機能の使い分け公式