計画と協働Claude Code and other supported coding agents
Jesse Vincent (obra) / writing-plans
すぐ始められるのに、なぜ計画を書くのか
文脈が失われたとき、生き残る唯一の部分が計画だからです。
押さえておく点
- 計画は文脈が失われたときの復旧手段です。長い作業では常に起きます。
- 完了の定義がない手順は、手順ではなく願望です。
- 計画のレビューは、完成した実装のレビューよりはるかに安く済みます。
- brainstorming とサブエージェント運用をつなぐ橋になります。
01実務で何が変わるか
エージェントの長時間作業は決まった形で失敗します。会話が伸び、過去の判断が文脈から落ち、1 時間前の自分の作業と矛盾し始めます。ディスク上の計画はこれに強く、記憶ではなく再読されるからです。
反対意見も安くなります。計画への異論は数分で扱えますが、完成した実装への異論は、それを作るのに要した時間ぶんの重さがあります。
02期待に届かない点
計画は古びます。コードと合わなくなった計画は、信頼される分だけ無いより有害です。現実がずれたら更新してください。
過剰な計画も実在します。小さな作業に文書は要らず、作ること自体が手続きのための手続きになります。
導入と最初の実行
- obra/superpowers から MIT ライセンスで superpowers を導入します。
- 各手順に、対象のファイルやコンポーネントと、完了の判定方法を必ず書かせます。
- 計画をリポジトリに置きます。レビューでき、セッションより長く残ります。
実際によくある質問
- 計画はどこに置くべきですか
- リポジトリです。レビュー、版管理ができ、別セッションや別エージェントから再読できます。
- 良い手順の条件は
- 対象が明示され、完了の判定方法があることです。それがないと進捗を確認できません。
- 計画が過剰になるのはいつですか
- 作業が 1 回で終わり一文で説明できるときです。そこでは計画は形式にすぎません。
出典
このページの機械可読版