gjalla-breakdown

Wave-Based Task Breakdown

機能を、規模と依存関係に応じたタスクのウェーブに分割します。これにより、開発中の進捗を追跡しやすくなり、ユーザーの期待に沿ったものを確実に構築できます。

Process

1. 仕様を読む：エージェントの計画または gjalla の仕様から、すべての動作要件と技術的な変更点を特定します。
2. タスクを特定する：各タスクで扱うファイルは1～2個とし、検証可能な、小規模でレビューしやすい差分を作成します。
3. 依存関係を整理する：ほかのタスクを開始する前に完了しておく必要があるタスクを確認します。
4. ウェーブにまとめる：同じウェーブ内のタスクは並行して実行でき、ウェーブは順番に進めます。

Task Format

作業のウェーブは、次のタスク群で構成されます。

• ID：W1-T1、W1-T2、W2-T1 など。
• Description：変更内容を一行でまとめます。
• Files：変更または作成する正確なファイルパス。
• Depends On：依存するタスク ID（同じウェーブ内の場合は「なし」）。
• Acceptance：タスクの完了を確認する方法。

Principles

• ウェーブを使うと、タスクを論理的・モジュール的なまとまりに整理し、直感的な順序で配置できます。たとえば、データモデルの変更を先に行い、後続のウェーブで必要な基盤を整えます。
• ウェーブとタスクには、完了時に印を付けられるようにします。これにより、実装の進捗状況を簡単に把握できます。
• ドキュメント、検証、テストなども必ずタスクの内訳に含めます。

作業が過負荷にならないよう、1つの仕様あたりのタスク総数は20未満に抑えます。大規模な機能は、複数の仕様に分割してください。

Enter the implement loop

内訳を作成したら、設計書と同じ仕様ディレクトリに保存します。そうすれば、人間や、コンテキスト圧縮後に再開したセッションが、すべてを読み直さなくても実装の進捗を正確に確認できます。変更が反映されたら、そのファイル内でウェーブにチェックを付け、各タスクの横に受け入れ確認の証跡を記録します。

最後のウェーブの検証が完了したら、変更はレビューに進みます（gjalla-code-review を参照）。