spec-kit-tasks

機能仕様と計画から、実行可能で依存関係の順に並んだタスクリストを生成します。

入力：変更名を任意で指定できます。省略した場合は、文脈から推測するか、確認してください。

手順

1. 成果物を読み込む

   必須：specs/changes/<name>/plan.md と specs/changes/<name>/spec.md。

   任意（存在する場合は読み込み）：specs/changes/<name>/checklists/。

   また、タスクに含めるべき規律と義務を確認するため、FRAMEWORK.md（存在する場合は FRAMEWORK.local.md も）を読み込みます。

   plan.md がない場合は、まず spec-kit-plan スキルを使用するよう促してください。

2. specs/changes/<name>/tasks.md を生成する

   タスクをフェーズごとに構成します。

   # Tasks: <Feature Name>
   
   ## Phase 1: Setup & Foundations
   - [ ] [T01] [FR-01] Description with exact file path
   
   ## Phase 2: Domain & Application Layer
   - [ ] [T02] [FR-01] Add a failing test for <behaviour> in <test file>
   - [ ] [T03] [FR-01, FR-02] Make it pass: implement <behaviour> in <file>
   - [ ] [T04] [P] [FR-03] Description (parallel — touches other files, depends on nothing unfinished)
   
   ## Phase 3: Infrastructure & Adapters
   - [ ] [T05] [P] [US-1] Description with exact file path
   
   ## Phase 4: Integration & Validation
   - [ ] [T06] [FR-02] Description with exact file path
   
   ## Phase 5: Documentation
   - [ ] [T07] [FR-01] Update `specs/features/<area>/spec.md` where <what the change makes untrue>
   
   ## Dependency Graph
   T01 → T02 → T03 → T05 → T06 → T07
              ↘ T04 ↗
   
   ## MVP Scope
   <Minimum set of tasks for a working, deployable slice, usually the P1 stories, with how each story is tested on its own.>
   

   タスクの形式：- [ ] [TaskID] [P?] [FR-nn, US-n] Description with exact file path

   • 並列化マーカーの後にある引用グループには、少なくとも1つの要件（FR-nn）、成功基準（SC-nn）、またはユーザーストーリー（US-n）を指定します。タスクが仕様で実現する内容を示してください。
   • [P] は、隣接するタスクとは異なるファイルを変更し、未完了のタスクに依存しないタスクを示します。
   • 各タスクは具体的で、すぐに実行できるものでなければなりません。ほかに文脈がない読者でも完了できるようにしてください。
   • 順序：セットアップ → ドメイン → アプリケーション → インフラストラクチャ → 統合 → ドキュメント。
   • 実装の前にテストを行います。 FRAMEWORK.md が TDD を標準の規律として定めている場合は、各テストタスクを、それが導く実装タスクの直前に配置し、依存関係グラフにもその順序（テスト、その後に実装）を示してください。 対となるタスクは「X の失敗するテストを追加する」／「テストを通す：X を実装する」という文言にしてください。 静的型付け言語では、対象のシンボルがまだ存在しないためテストがコンパイルできない状態は、通常の失敗段階です。実装を先に配置する理由にはなりません。
   • 制約を引用します。 計画のデータモデルで定められた各フィールド制約（必須または任意、上限・下限、許可値、検証ルール）を、実装するタスク内に原文のまま引用してください。実装者の裁量に委ねないでください。
   • 古くなったテストを明記します。 計画の調査で、変更対象を読み込んでいると判明した変更範囲外のテストには、すべて実行するタスクを設け、必要に応じて更新してください。
   • 最後のフェーズは ## Phase N: Documentation です。 計画の ## Record Search で、この変更によって内容が事実と異なると判明した現行の仕様書、決定記録、またはドキュメントごとに1つのタスクを設けます。該当するものがない場合は、(no observable behaviour change) という注記を1つだけ記載してください。 spec-kit-converge によって後から追加される収束フェーズは、このフェーズの後に配置します。
   • 各タスクを仕様の要件とユーザーストーリーに対応付けます。

3. 検証する

   完了する前に、次を確認してください。

   • すべての要件、エッジケース要件、ユーザーストーリーに少なくとも1つのタスクがあり、各タスクが実現する内容を示していること。
   • 実装可能な作業を必要とするすべての成功基準（負荷テスト、監査、測定など）にタスクがあること。リリース後に測定する成果指標には必要ありません。
   • 最後のフェーズが、タスクまたは注記を含む Documentation フェーズであること。
   • すべてのタスクに正確なファイルパスが含まれていること。
   • 曖昧または範囲が限定されていないタスクがないこと。
   • 大きなファイル内の場所を指定する場合は、行番号ではなく、関数名、特徴的な文字列、検索パターンなど、検索可能な情報で示すこと。行番号はタスクに取りかかる前に古くなるためです。 パターンの横に件数（「16件の参照」など）を記載し、検索結果がすべて見つかったことを実装者が確認できるようにしてください。
   • 変更対象のパスにプロジェクトのルールが課す義務すべてに、タスクがあること。 FRAMEWORK.md と FRAMEWORK.local.md を読み、テスト以外に対象パスの変更に伴って必要な作業（バージョン更新、変更履歴への記載、生成ファイルの再生成、成果物の再ビルドなど）を確認し、それぞれに個別のタスクを設けてください。
   • 新しいテストパスはすべて、その領域の既存テストの整理方法に従っていること。パスを新たに決める前に、既存の配置を確認してください。

出力 tasks.md の作成後：

• フェーズごと、ユーザーストーリーごとのタスク数。
• 特定した並行作業の機会。
• MVP のスコープの概要。
• 次のステップ：「実装前に整合性と要件の網羅性を検証するため、spec-kit-analyse スキルを使用してください。」

ガードレール

• 依存関係のルールに違反するタスクを生成しないでください。
• 順序として、ドメインとアプリケーションのタスクをインフラストラクチャのタスクより前に配置してください。
• プロジェクトで TDD が必須の場合、実装タスクを、それを主導するテストタスクより前に配置しないでください。
• 要件、ストーリー、または計画上の決定で求められていない作業を追加しないでください。