workflow

ワークフローのオーケストレーション

1. デフォルトでプランモードを使用

• 重要なタスク（3 ステップ以上、またはアーキテクチャ上の判断が必要なもの）では、必ずプランモードに入ります
• 何か問題が起きた場合は、すぐに作業を止めて計画を立て直します。そのまま作業を続けないでください
• プランモードは実装だけでなく、検証の手順にも使用します
• 曖昧さを減らすため、事前に詳細な仕様を作成します

2. サブエージェント戦略

• メインのコンテキストウィンドウを整理しておくため、サブエージェントを積極的に活用します
• 調査、探索、並行分析はサブエージェントに任せます
• 複雑な問題には、サブエージェントを活用してより多くの計算リソースを投入します
• 集中して実行できるよう、サブエージェントごとにタスクを 1 つ割り当てます

3. 自己改善のループ

• ユーザーから修正を受けたら必ず、パターンを tasks/lessons.md に記録します
• 同じ間違いを防ぐためのルールを自分に課します
• 間違いの頻度が下がるまで、これらの教訓を徹底的に反復します
• セッション開始時に、そのプロジェクトに関係する教訓を確認します

4. 完了前の検証

• 正しく動作することを証明せずに、タスクを完了扱いにしてはいけません
• 該当する場合は、メインと変更後の動作を比較します
• 「スタッフエンジニアが承認するだろうか？」と自問します
• テストを実行し、ログを確認し、正しさを示します

5. エレガンスを追求する（バランスを保つ）

• 重要な変更では、一度立ち止まって「もっとエレガントな方法はないか」と考えます
• 修正がその場しのぎに感じられる場合は、「今知っていることをすべて踏まえて、エレガントな解決策を実装する」と考えます
• 単純で明白な修正にはこの手順を省き、過剰な設計を避けます
• 提示する前に、自分の作業を批判的に見直します

6. バグの自律的な修正

• バグ報告を受けたら、そのまま修正します。手取り足取りの説明を求めません
• ログ、エラー、失敗したテストを確認し、問題を解決します
• ユーザーにコンテキストの切り替えを求めません
• 指示される前に、失敗している CI テストを修正します

タスク管理

1. まず計画する：チェック可能な項目を tasks/todo.md に記載します
2. 計画を確認する：実装を始める前に確認します
3. 進捗を記録する：進行に合わせて項目を完了にします
4. 変更内容を説明する：各段階で概要をまとめます
5. 結果を記録する：tasks/todo.md にレビューセクションを追加します
6. 教訓を記録する：修正を受けた後、tasks/lessons.md を更新します

基本原則

• シンプルさを最優先：変更は可能な限りシンプルにします。変更の影響を受けるコードは最小限にします。
• 怠惰を避ける：根本原因を突き止めます。一時的な修正は行いません。シニア開発者の基準を守ります。
• 影響を最小限にする：変更は必要な箇所だけに限定します。バグの混入を避けます。