プロンプト事例集

〔やりたいこと〕を実装したい。まずは関係するファイルを読んで現状を理解し、変更が必要なファイルと手順の計画を出して。私がOKしてから実装に入って。実装後はテストを実行して、結果を見せて。

〔作りたいもの〕を作りたい。いきなり実装せず、まず私に1問ずつ質問して、仕様を一緒に詰めて。十分に固まったら、SPEC.md に「対象ファイル・やること・やらないこと・完成の確認手順」を書き出して。実装はその後、私の合図があってから始めて。

〔課題〕の解決方針を、実装に入る前に3案出して。それぞれ「変更範囲・メリット・デメリット・リスク」を表で比べて、おすすめとその理由も教えて。まだコードは書かないで。私が案を選んでから実装に進んで。

〔大きな変更：例 ライブラリAからBへ移行〕をやりたい。一度にやらず、それぞれ単独でテストが通ってコミットできる小さなステップに分割した計画を作って。各ステップには「変更ファイル・作業内容・確認方法」を書いて。影響を受けるファイルの一覧も先に出して。まだ書き換えは始めないで。

〔@path/to/file〕に〔何〕を追加して。〔@path/to/手本ファイル〕が良いお手本なので、そのパターンに倣って。新しいライブラリは増やさず、既存の作りに合わせて。できたら〔確認方法（例：npm test）〕で動作を確かめて報告して。

これはTDDで進めたい。まず〔機能〕の仕様を満たす「失敗するテスト」を書いて、実際に失敗することを見せて。次に、そのテストが通る最小限の実装を書いて、緑になるまで直して。テストを消したり骨抜きにして通すのは禁止。落ちたら実装側を直して。

〔機能〕を追加したい。一度に全部作らず、独立して動かせる小さな単位に分けて、最初の1単位だけ実装して。単位ごとにテストを書いて実行し、緑になったら分かりやすい日本語メッセージでコミットして。1単位できたら、次に進む前に私に確認させて。

実装したら「できました」で終わらせないで。〔検証コマンド（例：npm test）〕を実行して、その出力をそのまま貼り、通っていることを証拠で示して。失敗していたら、報告の前に根本原因を直して。ビルドや型チェックがあればそれも同様にして。

〔画面・コンポーネント〕を〔デザイン画像 or 指示〕のとおりに実装して。実装したら実際に画面のスクリーンショットを撮って、目標と見比べて。ずれている箇所を自分で挙げて、直してからもう一度スクショで確認して。目標に十分近づくまでこのループを繰り返して。

〔症状〕という不具合がある。〔@怪しい場所〕あたりが怪しい。まず問題を再現する失敗テストを書いて、原因を特定し、根本から直して。エラーを握りつぶさず原因に対処すること。最後にテストが通ることを実行結果で示して。

〔症状〕で行き詰まっているので、状況を全部渡す。エラー全文：〔ログを貼り付け〕。関係ファイルは〔@path〕、すでに試したのは〔試したこと〕。まず原因の仮説を3つ、それぞれの確認方法つきで挙げて。確認が取れたものから根本原因を直して、再発しないことを実行結果で示して。

〔@path〕をリファクタしたい。外から見た振る舞いは一切変えないこと。まず現状のテストが通ることを確認し、足りなければ先に今の挙動を固定するテストを足して。そのうえで小さな単位で整理し、各ステップでテストを実行して緑を保って。1つの論理変更ごとにコミットして、何を変えたか説明して。

いったん今のアプローチは忘れて。これまで分かったのは〔分かったこと〕、うまくいかなかったのは〔失敗したこと〕。この前提を踏まえて、別の方針を2つ挙げて、それぞれの長所短所を比べてから、おすすめを提案して。私が選んでから着手して。

この変更をコードレビューして。スタイルよりも、バグ、仕様漏れ、既存挙動の破壊、テスト不足を優先して見て。問題がある場合は、ファイル名と該当箇所、なぜ危ないか、どう直すべきかを具体的に教えて。問題がなければ「指摘なし」とはっきり言って。

〔@対象範囲〕を公開前提でセキュリティ点検して。特に、秘密情報の直書き、入力検証の抜け、認証・権限まわり、インジェクション、依存の既知の脆弱性を重点的に見て。見つかった問題は深刻度つきで一覧にして、修正案も添えて。修正はまだせず、私が優先度を決めてから直して。

今の変更を、新しいサブエージェントに「差分だけ」を渡してレビューさせて。作った経緯や意図は伝えないこと。バグ・抜けたエラー処理・境界ケース・既存パターンとの不一致・セキュリティの観点で批判的に点検させて。好みの問題ではなく、正しさに関わる指摘だけをまとめて報告して。

そろそろ会話が長いので引き継ぎ資料を作って。HANDOFF.md に「目的／今どこまで進んだか／効いたこと／効かなかったこと／次の一手」を簡潔に書いて。次のセッションでこのファイルだけ読めば続きを始められる粒度にして。書けたら要点を3行で報告して。

今の変更を確認して、複数の論理変更が混ざっていたら、意味のある単位に分けてそれぞれコミットして。各コミットは「何を・なぜ」が分かる日本語メッセージにして。コミット前に、消し忘れのデバッグログや直書きの値が残っていないか点検して。最後にコミット一覧を見せて。

この変更のプルリクエストを作って。本文には「目的・主な変更点・テスト結果・動作確認の手順・レビューで見てほしい点」を簡潔にまとめて。関連Issueがあれば紐付けて。作成する前に本文の下書きを見せて、私がOKしてから出して。

このセッションで私が繰り返し指示したことや、あなたが間違えて直したことを振り返って。次回から毎回伝えなくて済むように、CLAUDE.md へ追記すべきルールを提案して。「これを消したらClaudeが間違える」と言えるものだけに絞って、短い箇条書きで。私がOKしたものだけ追記して。

〔@対象の機能やスクリプト〕の使い方をREADMEに追記して。前提・セットアップ手順・最小の使用例・よくあるエラーと対処を、初めての人にも分かる言葉で書いて。書く前に実際にコマンドを動かして、例が本当に動くことを確認してから載せて。

依存パッケージを安全に更新したい。まず古くなっている依存と、それぞれの破壊的変更の有無を一覧にして。リスクの低いパッチ更新から順に、1グループずつ更新してはテストを実行して。テストが落ちたらそのパッケージは保留にして理由をメモして。最後に「更新できたもの／保留したもの／要判断のもの」をまとめて報告して。

〔調べたいこと〕を調査して。今回はコードの変更は一切しないで、読むだけ。結論と根拠（ファイルパスと該当箇所）を箇条書きで報告して。分からなかったことは分からないと正直に書いて。修正案があれば提案だけ添えて、実行は私の指示を待って。

〔機能：例 認証〕の流れを追って説明して。フロントの入口からバックエンド、データベースまで、どのファイルでどう処理されるかを順番に。登場するファイルのパスと、各ステップ1〜2行の要約で、全体像が一目で分かる地図にして。最後に、初めて触る人がハマりそうな箇所も教えて。

〔遅い箇所：例 一覧ページの表示〕が遅い。まず計測から始めて、どこで時間を使っているかをデータで特定して。推測で直さないこと。ボトルネック上位3つを「場所・原因・改善案・見込み効果」の形で報告して。私が対象を選んでから修正に入り、修正後は同じ計測で前後比較を見せて。

〔@ファイルや概念〕を、私が理解できるように解説して。前提知識は〔自分のレベル：例 JavaScriptの基本文法は分かる〕くらい。まず全体の役割を3行で、次に処理の流れを順番に、専門用語はかみ砕いて説明して。最後に理解度チェックの質問を3つ出して、私の答えに講評をつけて。