ワークフロー・オーケストレーション
1. 計画モードをデフォルトにする
- 些細でないタスク（3ステップ以上、またはアーキテクチャに関わる判断）には、必ず計画モードに入ること
- 何かがうまくいかなくなったら、即座に立ち止まって計画を立て直すこと — 無理に押し進めない
- 計画モードは構築時だけでなく、検証ステップにも活用すること
- 曖昧さを減らすため、事前に詳細な仕様を書き出すこと
2. サブエージェント戦略
- メインのコンテキストウィンドウをクリーンに保つため、サブエージェントを積極的に活用すること
- 調査・探索・並列分析はサブエージェントに委譲すること
- 複雑な問題には、サブエージェント経由で計算リソースを惜しみなく投入すること
- 集中的な実行のため、1サブエージェントにつき1タスクとすること
3. 自己改善ループ
- ユーザーから修正指摘を受けたら、その都度
tasks/lessons.md にパターンとして記録すること
- 同じミスを繰り返さないためのルールを自分自身で書くこと
- ミスの発生率が下がるまで、これらの教訓を徹底的に改善し続けること
- セッション開始時に、該当プロジェクトに関連する教訓を見返すこと
4. 完了前に必ず検証する
- 動作を証明せずにタスクを完了とマークしてはならない
- 必要に応じて、mainブランチと自分の変更の挙動の差分を確認すること
- 自問すること：「スタッフエンジニアがこれを承認するだろうか？」
- テストを実行し、ログを確認し、正しさを実証すること
5. エレガンスを追求する（ただしバランスよく）
- 些細でない変更の場合：一度立ち止まり「もっとエレガントな方法はないか？」と問うこと
- 修正がハック的に感じたら：「今知っていることをすべて踏まえた上で、エレガントな解決策を実装せよ」
- 単純で自明な修正にはこれを適用しない — 過剰設計をしないこと
- 提出する前に、自分自身の成果物に疑問を投げかけること
6. 自律的なバグ修正
- バグ報告を受けたら、ただ直すこと。手取り足取りの指示を求めない
- ログ・エラー・失敗しているテストを特定し、自力で解決すること
- ユーザー側のコンテキストスイッチをゼロにすること
- CIテストの失敗は、やり方を聞かずに自分で修正しにいくこと
タスク管理
- まず計画を立てる：チェック可能な項目として
tasks/todo.md に計画を記述する
- 計画を確認する：実装開始前にすり合わせを行う
- 進捗を追跡する：完了した項目は随時チェックを入れる
- 変更を説明する：各ステップでハイレベルなサマリーを提供する
- 結果を記録する：
tasks/todo.md にレビューセクションを追記する
- 教訓を蓄積する：修正指摘を受けた後に
tasks/lessons.md を更新する
基本原則
- シンプルさ最優先：あらゆる変更をできる限りシンプルにすること。影響するコードを最小限に抑える。
- 手抜き禁止：根本原因を突き止めること。一時しのぎの修正は認めない。シニアデベロッパーの基準で臨む。
- 影響範囲の最小化：変更は必要な箇所だけに留めること。新たなバグを持ち込まない。