- 3ステップ以上 or アーキテクチャに関わるタスクは必ずPlanモードで開始する
- 途中でうまくいかなくなったら、無理に進めずすぐに立ち止まって再計画する
- 構築だけでなく、検証ステップにもPlanモードを使う
- 曖昧さを減らすため、実装前に詳細な仕様を書く
- メインのコンテキストウィンドウをクリーンに保つためにサブエージェントを積極的に活用する
- リサーチ・調査・並列分析はサブエージェントに任せる
- 複雑な問題には、サブエージェントを使ってより多くの計算リソースを投入する
- 集中して実行するために、サブエージェント1つにつき1タスクを割り当てる
- ユーザーから修正を受けたら必ず
tasks/lessons.mdにそのパターンを記録する - 同じミスを繰り返さないように、自分へのルールを書く
- ミス率が下がるまで、ルールを徹底的に改善し続ける
- セッション開始時に、そのプロジェクトに関連するlessonsをレビューする
- 動作を証明できるまで、タスクを完了とマークしない
- 必要に応じてmainブランチと自分の変更の差分を確認する
- 「スタッフエンジニアはこれを承認するか？」と自問する
- テストを実行し、ログを確認し、正しく動作することを示す
- 重要な変更をする前に「もっとエレガントな方法はないか？」と一度立ち止まる
- ハック的な修正に感じたら「今知っていることをすべて踏まえて、エレガントな解決策を実装する」
- シンプルで明白な修正にはこのプロセスをスキップする（過剰設計しない）
- 提示する前に自分の作業に自問自答する
- バグレポートを受けたら、手取り足取り教えてもらわずにそのまま修正する
- ログ・エラー・失敗しているテストを見て、自分で解決する
- ユーザーのコンテキスト切り替えをゼロにする
- 言われなくても、失敗しているCIテストを修正しに行く
- まず計画を立てる：チェック可能な項目として
tasks/todo.mdに計画を書く - 計画を確認する：実装を開始する前に確認する
- 進捗を記録する：完了した項目を随時マークしていく
- 変更を説明する：各ステップで高レベルのサマリーを提供する
- 結果をドキュメント化する：
tasks/todo.mdにレビューセクションを追加する - 学びを記録する：修正を受けた後に
tasks/lessons.mdを更新する
- シンプル第一：すべての変更をできる限りシンプルにする。影響するコードを最小限にする。
- 手を抜かない：根本原因を見つける。一時的な修正は避ける。シニアエンジニアの水準を保つ。
- 影響を最小化する：変更は必要な箇所のみにとどめる。バグを新たに引き込まない。