まとめと実践

重要なポイント

• タスクの前にコンテキストを与えよう: スタック、コンベンション、再利用すべき既存の部品を明示するか、コードが合わせるべき実際のシグネチャを貼ろう。
• 境界を定義しよう: 入力、出力、エッジケース。ソフトウェアの興味深い振る舞いは縁に宿るので、そこに言葉を費やそう。
• 小さく検証可能なステップで進め、コードの前に計画を求めよう。プルリクエストより計画を直すほうがずっと安い。
• 全面書き直しではなく的を絞った差分で反復し、言葉では曖昧に残るものは具体的な例（できればテスト）で釘付けにしよう。
• コンテキストウィンドウを資源として管理し、やってはいけないことを言おう — 明示的な否定の制約が出力をタイトに保つ。

やってみよう

普段ならそのまま打ち込むような曖昧な一行の依頼（「リストに検索を追加して」）を取り、何かを送る前にエンジニアのプロンプトに書き直そう。コンテキスト（スタック、触れるファイル）、入力／出力、二、三のエッジケース、望む結果の例を一つ、そして否定の制約を一つ（触れないもの）を加えよう。書き直した版を送り、怠けた版が生み出していたであろうものと比べよう。実際の依頼三つでこれをやれば、このアップグレードは自動になる。

この章のプロンプト

Context: <言語 + フレームワーク + バージョン>、<ファイル/モジュール> で作業中。
We already <再利用すべき関連する既存パターンまたはライブラリ>.

Task: <作るべき明確なもの一つ>.

Inputs / outputs: <型と形>.
Edge cases to handle: <重要なものを列挙>.
Example: <具体的な入力一つ -> 期待される出力>.

Constraints:
- No new dependencies — use <すでに持っているもの>.
- Touch only <このファイル>; don't refactor anything else.
- Keep existing names and signatures unchanged.

Before coding, give me a 3-4 line plan and wait for my "go".