split-into-tasks

タスクへの分割

仕様を読む

docs/specs/<slug>/spec.md が必須です。存在しない場合は、タスクを提案する前に停止してください。

仕様と現在のコードに加えて、関連するプロジェクトの決定事項、用語集の用語、承認済みのプロトタイプがあれば、それらも読みます。実装されていない箇所は、対応すべきギャップとして扱います。確定済みの情報源に矛盾がある場合は作業を一時停止し、解決すべき決定事項を正確に提示してください。承認済みの動作が一貫した1つのユーザーワークフローを構成する場合は、仕様を唯一の引き継ぎ資料として維持します。そのワークフロー内の個別の操作や状態は、タスクの境界を作るものではありません。

成果全体のマップを提案する

複数の独立して提供可能な成果がある作業では、独立して利用・検証できる成果を最小限に抑えた、全体を網羅する簡潔なマップを作成します。前提作業は、それが独立して提供可能な場合を除き、その作業が役立つようになる最初の成果にまとめます。依存する成果を実際に妨げるものだけをブロッカーとして宣言してください。

仕様に記載されたすべての成果を網羅します。提案する各タスクについて、タイトル、実現する動作、観察可能な受け入れ基準、対象を絞った決定論的な検証、タスク固有の制約、理由を添えたブロッカー、レビューのチェックポイントを示します。実装では、その時点のリポジトリに基づいて、アクティブな成果の技術的な進め方を適宜決定するため、予測されるファイル、関数、コード構造、技術レイヤーごとの手順、コンテキストの境界、内部的な手順は記載しないでください。タスクの制約には、そのタスクに適用される参照情報だけを記載します。つまり、そのタスクで提供する承認済みプロトタイプの画面と状態、およびそのタスクが依存する決定事項の契約です。それぞれが何を規定するかを示し、規則や画面構成は元の情報源に記載したままにしてください。

重大な誤りが多くの依存作業に波及するおそれがある場合、またはセキュリティ、データ、権限、移行、復旧、外部との契約など、決定論的なチェックでは重大なリスクを十分に解消できない場合に限り、中間レビューのチェックポイントを追加します。その対象となる累積範囲と具体的なリスクを明記してください。チェックポイントで実施するレビューは、その範囲に対する1回のみであり、問題がなくなるまで繰り返すラウンドではありません。実装フェーズでは、差分全体に対する最終レビューを1回行います。

提案全体を提示し、ユーザーが承認するまで調整を続けてください。承認前にタスクファイルを作成してはいけません。

承認済みの引き継ぎ資料を作成する

承認後、確定済みの共通制約は仕様に、タスク固有の制約のみをタスクファイルに記録します。未確定の動作を作り出してはいけません。

承認済みの各タスクは、templates/task.md を使用して docs/specs/<slug>/tasks/<NN>-<slug>.md に記録します。ブロッカーを依存タスクより先に記載してください。承認済みの改訂では、完了が一度も記録されていない置き換え対象のタスクを削除します。後に in-progress または blocked に戻った場合でも、完了履歴が記録されたタスクは保持してください。引き続き必要な義務とブロッカー参照を承認済みの置き換え先に移した後、そのタスクを superseded に設定し、置き換え先と理由を示す改訂の根拠を追記します。superseded のタスクは、その承認済みのタスク分解において終端であり、現在の成果マップには含まれない、復旧用の履歴です。アーカイブは作成しないでください。現在のタスク引き継ぎ資料を書き終えた時点で終了し、実装には進まないでください。