to-tasks

タスク化

現在のコーディネーターとリポジトリの直接操作ツールを使ってドラフトを作成します。今回の作業にフルモデルプレビューや追加のワーカーは必要ありません。設計ワーカーまたはセキュリティワーカーを割り当てる前に、必要なルートについて shared/references/model-preview.md を一度使用してください。ネストされた作業では、親の不変な承認済みスナップショットを使用します。

承認済みの PRD を実行可能なキューに変換します。各スライスは、1 回の集中的な実装作業で完了できる小ささとし、検証可能な受け入れ条件を備えます。

機能の計測記録とキャプチャ API には shared/references/workflow-measurement.md を使用してください。各ステージの実行台帳と不変の計画を維持してください。ドラフト作成前に to-tasks の stage-start を記録し、実際のキュー承認待ちを記録し、昇格後に stage-end を記録してください。タスクとモデルの応答をまとめた場合は、観測された待ち時間を 1 回として扱います。必須チェックの識別情報が確定したら紐付けてください。不明な値は記録しないでください。

境界

ステータスが approved の .ai-workflow/work/<feature-slug>/prd.md を受け取ります。正規ファイル tasks/T<N>-<slug>.md はそれぞれ一度だけ作成し、ステータスを draft にします。tasks-draft.md は、承認と依存関係を簡潔に示すインデックスとして維持してください。承認時には、同じファイルを ready-for-agent に昇格させます。2 つ目の契約書コピーは作成しません。タスクの各フィールド、インデックス、承認の紐付け、旧形式のキューについては references/task-contract.md を参照してください。

ドラフトを作成する前に shared/references/workflow-stage-routing.md を読んでください。設計、セキュリティ、インターフェース、受け入れに関する共通の判断を一度評価します。タスクでこれらの判断を再利用する場合は、shared/references/planning-reuse.md に従って、参照元のリビジョンを確認し、共通の結論とタスク固有の差分から完全なゲート記録を作成してください。各スライスでは、引き続きそれぞれの設計リスクとセキュリティのトリガーを分類します。design-gate は、未解決または変更された境界にのみ適用してください。一致する確定済みの判断について、レンズによる確認を繰り返す必要はありません。公開するスライスには、shared/references/gate-result.md に定められた正規のゲート結果を含め、調査結果とレビューの重点を記載し、verdict: proceed および decision_required: none としてください。test-lens は、統合境界、モック境界、並行処理のケース、既存テストの脆弱性など、実際にテスト設計の判断が必要な場合にのみ使用してください。

個別の設計レンズ、パネル、ランナー、または models-consensus を直接呼び出さないでください。decision_required がある場合、または重要な要件に未回答のものがある場合は、タスク承認前にユーザーに確認します。ユーザーが追加の意見を明示的に希望する場合は、models-consensus を呼び出すよう案内してください。そのワークフローでは、実行前にユーザーが提案された参加枠を承認します。

計画の依頼では、タスクのみの承認をデフォルトにします。依頼に実行が含まれる場合は、具体的なプレビューを用いてタスクとモデルの一括承認を提案してください。ユーザーがタスクとモデルの一括承認を希望する場合は、implement-tasks を通じて具体的な実行プレビューを準備してから、両方の判断を含む 1 回の応答を求めてください。タスクのみの承認がモデルの承認に変わることはありません。デリバリーと協議会の権限は、それぞれ独立しています。

エントリーポイントの選択

受け入れ条件が完全な、すでに承認済みのタスクが 1 つある場合は、shared/references/workflow-stage-routing.md に記載された単独の implement-and-review パスを使用してください。このパスに PRD とキューを無理に作成してはいけません。このスキルは、承認済み PRD を分解するために使用します。どちらのエントリーポイントも、重要な未解決のプロダクト、セキュリティ、公開契約、データ、依存関係に関する判断、必須チェック、独立したレビューを回避するものではありません。

作業

1. PRD のステータスが approved であることを確認します。ドラフトまたは概要だけの計画の場合は to-prd に戻します。関連するコードを読み、各スライスを検証できるリポジトリ内のコマンドを特定します。コマンドを捏造してはいけません。

2. 垂直スライスを作成します。各スライスでは、必要なレイヤーを通る観測可能な経路を 1 つ提供します。単独で検証できるトレーサーバレットを優先します。共有のブロッカーを取り除く場合に限り、最初に動作を維持するプレファクターを置き、その特性テスト、またはテスト網となる既存のテストスイートを記録します。コードベース全体に及ぶ機械的な変更では、垂直スライスであるかのように扱わず、拡張、移行、縮小のスライスを使用します。

3. 安定した ID T1、T2 以降を割り当てます。承認時に参照されるため、割り当て後に ID を変更しません。分割する場合は新しい ID を割り当て、削除する場合は欠番を残し、並べ替える場合は既存の ID を維持します。依存関係では既存の ID を指定し、そのグラフで順序を定義します。共有キューコントローラーを通じて、自己ブロッカーと循環依存を拒否します。真に残る人間の承認または判断が必要な場合に限り、スライスに HITL を指定します。それ以外のすべてのスライスには AFK を指定します。

4. 各ドラフトにスライス契約を添付します。

   1. ファイルパスを記載せず、エンドツーエンドの動作を説明します。
   2. 検証済みのコマンドと、観測可能な受け入れ動作を列挙します。状態を持つ作業では、状態機械から意味のある失敗シーケンスを導き出し、以前のスライスから関連する不具合を引き継ぎます。どのホストアダプターに、現実的な保存値の確認または統合テストが必要かを特定します。合成したハッピーパスのフィクスチャだけでは不十分です。機能スライスでは動作を明記する必要があります。機能以外のスライスでは、Test expectation: none; <reason> と記載できます。この契約に合格させるために、テストまたは受け入れチェックを削除、省略、弱化、範囲縮小したり、モックで回避したりしてはなりません。契約が誤っている場合は、承認前に差し戻します。
   3. 各設計面を、確定済みの共有判断に対応付けるか、未解決または変更された境界を design-gate で評価します。共有結論を使用する場合は、繰り返し必要となるフィールドを表示し、タスクには正規のゲート全体を保持します。承認前に必要な変更を解決します。ブロッキング所見があるレンズのみを再確認し、その ID、以前の根拠、解決内容を維持します。decision_required が空でない場合、ユーザーが解決するまで昇格を停止します。
   4. security-gate を適用し、一致したトリガーとともにセキュリティフラグを引き継ぎます。
   5. 実際のテスト設計上の選択を解決した場合に限り、test-lens の結論を記録します。
   6. ロールバック、レビューの重点、プロダクト上のブロッカー、書き込み競合を個別に記載します。各共有契約の所有者と、その利用側のブロックが解除される条件を明記します。共有するマイグレーション、契約、セキュリティ面、または想定される書き込み範囲があるスライスは、ドラフトにマージ計画を記載しない限り順次実行します。真のブロッカーを取り除く場合に限り、狭い範囲の共有インターフェースを先に確定します。並列作業を生み出すためだけに、基盤フェーズを作らないでください。

5. 新機能の実行計画では、shared/references/feature-review.md を使用して、中心となるチェック計画を定め、先送りする定型作業または重大な依存関係を分類します。各タスクでは、対象を絞った回帰チェックと依存関係の契約テストを明記します。広範な簡素化と統合レビューは、最終的な機能ゲートで行います。既存の計画と、明示的に従来タスクモードを指定した場合は、記録済みのレビュー順序を維持します。リファレンスに従って、正規のタスクファイルと簡潔なインデックスを作成します。機械的なスケジューリング入力は queue.json に保持します。依存関係と所有権はそこに記録しますが、受け入れ条件とゲートの完全なフィールドは各タスクに保持します。バージョン管理されたゲート記録を shared/scripts/gate_contract.py で検証した後、読み取り専用の共有キューコントローラーでグラフとバインドを検証してから承認を求めます。

6. 各 ID、タイトル、正規パス、依存関係、タイプ、受け入れ条件の概要、ゲートの結果、セキュリティレベル、所有権を提示します。承認を求める前に、重要な変更を解決します。まとめて承認を求める場合は、解決済みのルート、ソース共有、プライバシー、受領記録、機能、ツール、予算を、このプレビュー内で正確に示します。ユーザーがこの選択肢を求めるか、後の実行時点になるまでは、調整担当者のみのドラフトに実行プレビューは不要です。

7. 実際の応答、タイムスタンプ、承認済み入力の識別情報、決定事項を記録します。承認済みの正規タスクごとのステータスのみを ready-for-agent に昇格させます。すべてのゲートで、すでに verdict: proceed および decision_required: none になっている必要があります。インデックスを承認済みにし、その不変の承認レコードへのリンクを記載します。親 PRD は書き換えないでください。着手済み、done、または blocked のコントラクトは、決して書き換えたり削除したりしないでください。そのスコープ、受け入れ条件、ゲート、または担当を変更する場合は、新しいタスク ID と承認が必要です。既存のマニフェストと台帳に進捗を記録します。

受け入れ条件

準備完了の各タスクには、承認済みの親 PRD、安定した ID、検証済みの依存関係、確認可能な受け入れ条件、すべてのゲートおよびセキュリティ項目、ロールバックの指針、レビューの重点項目、明示された担当が必要です。インデックスには、正規タスクと実際の承認へのリンクが記載されています。次のステップは implement-tasks です。このステップでは、正確な統合承認を再利用するか、ディスパッチ前にモデルの承認を取得します。既存のレガシーキューは、着手済みのコントラクトを書き換えずに読み取り可能な状態に保ちます。