Research first
コードを書く前に、APIがどうなっているか推測してはいけません。まず確認しましょう。
これは、簡単ではないeditやwriteを行う前に必ず実行する必要があります。
1. 調査: research/findings/<topic>.md
- まず
research/findings/を確認します。誰かがすでに調査しているなら、それを再利用します。 - 次にコードベースをgrepします。外部ドキュメントが必要ならウェブ検索します。検索時には2026年を指定して、最新のドキュメントを取得します。
- 見つけたものを引用します。ドキュメントが存在しない場合は、仮説を検証する小さな再現コードを書きます。
research/findings/<slug>.mdに保存し、次のセッションで同じ作業を繰り返さないようにします。
テンプレート:
# Findings: <topic>
Date: 2026-09-04
Sources: [url, url]
Existing code: `path:line`: 見つけた内容
## Verdict
推奨アプローチ: ...
代替案: ...
リスク: ...
2. 計画: research/plans/<task>.md
# Plan: <task>
Research: research/findings/<topic>.md
Approach: ...
Files to change: [list]
Tests: ...
Rollback: ...
3. 承認
計画をユーザーに示します。ユーザーがOKと言うまでコーディングを開始してはいけません。小さな単一ファイル編集の場合、自動承認の仕組みが通過させることがあります。
4. 実装と検証
計画を実行し、テストを実行し、harness bench --quickを実行し、次にharness memory syncを実行して、次のセッションで何がうまくいったかを記憶します。
注意事項
- 調査結果がすでに存在する場合は、再度行わないでください。
- ファイルを読んで事実を確認し、推測しないでください。見つけた内容が期待と矛盾する場合は、その旨を伝え、ファイルを信頼してください。
- 完了したら、実際にうまくいった内容で調査結果を更新してください。
やってはいけないこと
readやgrepの前にeditすること- APIシグネチャを推測すること
- 「小さな変更だから」と計画をスキップして、3つ以上のファイルに触れようとすること