plan-tasks

承認済みの要件と設計、およびスキルセットの templates/tasks.md（存在する最初のパス：この SKILL.md と同じ場所の templates/、${CLAUDE_PLUGIN_ROOT}/templates、それ以外の場合は ../../../templates）から、docs/specs/<YYYY-MM-DD>-<feature>/tasks.md を作成します。すべてのタスクブロックの項目（Files、Interfaces、Depends-on、Steps、_Requirements:_）は必須です。タスクごとのリスクラベル、判断範囲フラグ、Human-review-order は不要です（その理由は Step 3 のゲート表を参照）。このコードベースの予備知識がなく、自分のタスクと Global Constraints だけを参照する熟練実装者向けに記述してください。推測してはならない名前、パス、型、コマンドは、文章として Steps に書かず、Files / Interfaces / Reuse / フッターに記載します（簡潔なステップを参照）。ステップごとに todo を作成します（1～4。トラッカーがある場合は 5 も）。このスキル独自のリストを使い、design-solution のものや execute ファミリーのものとは分けます。各 todo は、対応する Done when: を満たしたときにのみ完了にします。

Step 1: ヘッダーと Global Constraints

Goal（1 文）、Architecture（2～3 文）、Tech Stack、Execution-mode: <unset|continuous|story-unit>（unset のままにします。サイズ、バンド、慣例から推測して設定してはいけません。モードの書き戻しは Exit で行います）。次に Global Constraints を記載します。プロジェクト全体に適用されるルールの正規ソースパスとハッシュを示し、各タスクから参照します（コピーはしません）。## Team にメンバー一覧／バンドの上書きがある場合は、それだけを根拠にバンドとパッケージングを決めます（Solo：複数担当者がいるかのように装わないこと。Small／Multi：自由記述の補足は任意で、新たな必須フィールドを設けないこと）。Team がない場合は、機能着手前のデフォルトを適用します。docs/architecture/ に設計の骨格がある場合は、そこに記載された強制力のある **ARCH-N** 不変条件も含め、すべてのタスクに適用されるようにします。以下のソースを解決します。最初に見つかったものを SSOT とし、並行する別のものを作ってはいけません。

順序	ソース	対象
1	docs/standards/ が存在する場合（INDEX.md と testing.md、errors-logging.md のようなドメイン別ファイル）	命名、i18n、プロジェクト固有ルール、テスト、エラー／ロギング
2、次に 3	docs/standards/ がない場合に限り、docs/product/guidelines.md（レガシーのフォールバックのみ。同等のルール本文がある場合に限り、ポインターのみの場合は除外）。それもなければ docs/agents/project.md	テスト／lint／型チェックのコマンド、命名／i18n のルール、禁止されている変更

Done when: Goal、Architecture、Tech Stack、Execution-mode:（通常は unset）、Global Constraints のソースパスとハッシュが記載され、制約のソースが特定されており、並行する SSOT が作られていないこと。

Step 2: ファイル構成と情報取得

計画で作成または変更するすべてのファイルを、タスクを書く前にマッピングし、それぞれの責務を 1 行で記載します。マップにないファイルには、どのタスクも変更を加えてはいけません。

ファイル構成で参照するシステムドキュメント（任意）

このステップでファイル構成や配置先を記述または見直す場合は、このファイルと同じ場所にある system-docs-consult.md を読み、その指示に正確に従います。このドキュメントでは、コードベースと規約のどちらを優先するか、競合時の扱い、および該当ドキュメントが存在しないか権威ある情報源ではない場合の何もしない処理を定めています。

マップが完成したら、タスク本文を書く前（Step 3）に、情報取得を 1 回実行します。必須サブスキル：マッピングしたパスを対象に blast_radius の load-subgraph を使い、その後、唯一の焦点として cluster(feature CODE) を実行します。Files／Reuse の作成時は取得したパッケージを保持します。根拠のある記述（帰属先は 1 か所のみ）については、skills/execution/load-subgraph/references/grounded-claims.md に従います。空または情報が薄いことはゲート条件ではありませんが、不在を主張する前に対象範囲を明示します。

Done when: 作成／変更するすべてのファイルが 1 行の責務付きでマッピングされ、blast_radius／cluster(feature CODE) が 1 回実行されている（または specs／seeds がない場合は何もしない）こと。

Step 3: 垂直スライスとしてのタスク

契約： タスクは垂直スライスです。つまり、独自のテストサイクルとレビュー判定を持つ最小単位です。分割するのは、一方のタスクを却下し、隣のタスクを承認できる場合に限ります。形状： ユーザーストーリーごとに、タスクあたりデモ可能なエンドツーエンドの成果を1つ含めます。後続のスライスを可能にするだけのプレファクタリングは、Depends-on のエッジを介した先行タスクとして独立させます（「変更を容易にしてから、容易な変更を行う」）。ストーリーのタスク内に水平レイヤーとして埋め込んではいけません。

各タスクには、次の項目を含めます。

項目	ルール
Files, Reuse, Interfaces, Depends-on	Files：Create / Modify / Test。それぞれのパスをバッククォートで確定します（例：`src/foo/bar.ts`）。パスのトークンに行番号や範囲を結合してはいけません（path:86-103 は禁止）。範囲は周囲の文章または別の注釈に記載します（新しいプランのみ。P1 の所有権抽出では、既存の tasks.md にすでに記述されたレガシー形式の結合表記も引き続き受け入れます）。Reuse：このタスクが基盤とする、具体的な既存コード／ライブラリ／パターンを、設計セクションの Reuse: 行からそのまま転記します。同じ <rung> — <concrete target> の文法を使います（例：Reuse: existing — src/util/dates:parseISO (rung 2)）。解釈し直さず、コピーしてください。Step 4 で設計の行と照合します。Interfaces：Consumes / Produces。隣接するタスク間で共有する名前と型を記載し、単独で実装する担当者が何を呼び出すべきか分かるようにします。Depends-on：このタスクが実際に必要とする先行タスク、つまり、このタスクがインターフェースを Consumes するタスク、またはそのファイルを基盤とするタスクを Depends-on: Task 2, Task 4 または Depends-on: none として記載します。並列実行のシグナル：ファイルもインターフェースも共有しない2つのタスクにはエッジを指定しません。これにより、サーフェスが分離され、ワークツリーの隔離が安全な場合、継続的な build-in-waves スケジューラーがそれらを1つの準備完了セットに配置できます。この行を省略すると、すべての先行タスクへの依存にフォールバックします（安全ですが完全に直列になります）。不必要な依存の過剰指定は直列化を招き、依存の指定漏れは、衝突が起きる前にエグゼキューターのファイル非重複チェックで検出されます。ビルドウェーブを制御するための指定です。レビュー単位を整えるだけの目的で、タスクが必要とするものを偽ることになる依存関係の並べ替えや縮小は決して行ってはいけません。
Steps（簡潔なチェックボックス、3～8個）	1つ2～5分程度の小さなチェックボックスにします（タスクあたり3～8個を推奨）。TDD サイクル：失敗するテスト（要件 ID をアプリケーション／テストのソースに埋め込まず、振る舞いを記述した完全なコード）→ 実行し、記載どおりの失敗を確認 → 実装（完全なコード）→ 実行し、合格を確認 → 変更内容を説明する慣例的な件名でコミット（Implements: / Guards: トレーラーは必須ではなく、指示も不要です）。ここに長大な解説を書いてはいけません。レビュー対象が膨らみます。1人の担当者向けの詳しい手順説明は、実行時に実行ブリーフ（.skills/<CODE>/task-N-brief.md）に記載します。一方、共有プランでは、ブリーフで API を勝手に作れないように、Files / Interfaces / Reuse に識別子（パス、型名、コマンド）を記載します。
フッター	`_Requirements: CODE-N.M, CODE-N.M_` — このタスクが実装または保護する ID です。すべてのタスクに1つ必要です。既定では、1つのストーリーの ID（ストーリー番号 N が同じ）を記載します。複数ストーリーのフッターでは、それらのストーリーを build-by-story のもとで1つのレビュー単位にまとめます（プラン品質のシグナルです。禁止ではなく、Depends-on を偽る理由にもなりません）。ID はこのフッター（および要件／設計）に記載し、本番ソースやテストのタイトルには記載しません。どの項目にもプレースホルダーを含めてはいけません。「TBD」、「適切なエラー処理を追加」、「Task 3 と同様」、またはどのタスクにも定義されていない型への参照は、いずれもプランの不備です。プランを公開する前に修正してください。

考え方	実態
「まずプレファクタリングするのが常に正しい。変更を容易にしよう」	Depends-on を介したプレファクタリングは問題ありません。ただし、ビルド時にレビュー単位を決めるのは引き続きストーリーの参照先です
「レビュー担当者に気づいてもらうため、Risk: high を追加しよう」	そのような項目はありません。エージェントのラベルではなく、実際の差分に対するリスクの glob がその役割を果たします
「人間が最初に読むべきものが分かるように、Human review order を書こう」	これは廃止されています。ストーリーから導かれる単位がレビュー順です。利用者のいない2つ目のリストは役に立ちません
完了条件： Step 2 のマップ内のすべてのファイルが 1 つ以上のタスクに含まれており、各タスクが独自のテストサイクルを持つ垂直スライスとして記述されていること。スロット／プレースホルダーの整合性は Step 4 で確認する項目であり、ここでは確認しません。

1 つのトライアドに 1 つの計画

このルールの参照先 — Step 4 と Exit はここだけを参照します。

承認済みの設計と要件に含まれる垂直スライスをすべて、この tasks.md に記述してください。1 つの機能トライアドは 1 つの計画です。frame-change／plan-milestones が扱うのは、独立したサブシステムまたは新しい機能の形であり、このトライアドに残ったスライスではありません。スコープを削るのは、ユーザーが要件を取り下げた場合に限ります。結果が垂直スライスのままである場合に限り、統合してください（Step 3）。

考え	実態
「タスクが 28 個もある――残りを後の ROAD に分割して、これを承認できるようにしよう」	このトライアドに残ったスライスは、このファイルに含めたままにします。分割すると機能が断片化します。
「ファイルを小さく見せるために、レイヤーを 1 つの巨大タスクにまとめよう」	水平に隠しても、Step 3 の計画上の問題は解決しません。

Step 4：網羅性と一貫性の確認

確認項目	ルール
網羅性：audit-trace、動作ステップ、seam-table	必須サブスキル：audit-trace を使用してください。承認済みの要件はすべて、1 つ以上のタスクフッターで引用する必要があります（引用されていない ID は未完了です。理由を添えて取り下げてください）。ドキュメントのみを対象とし、テストソースに ID を記載してはいけません。各フッターの ID には、動作をドメインの言葉で検証する TDD ステップ（または手動／受け入れステップ）が必要です。テストソースには [CODE-N.M]、/// REQ:、@CODE-N.M を決して記載しないでください。ID とテストの対応はタスクレポート／仕様レビューに記載し、本番ツリーには含めないでください。各 ID に 1 つずつテストを用意する必要はありません。同じ境界で動作の形が同じ ID（複数の入力に適用されるルールや、複数のデフォルト値など）は、ID ごとに 1 行を設けたテーブル駆動テストを共有できます。それでもフッターではすべての ID を引用してください。design.md に「テスト対象の境界」テーブルがある場合は、各行のすべての ID に対し、その境界で計画されたテスト／受け入れステップが必要です。約束された ID がテストでカバーされていない場合は、網羅性の欠落です。番号は振り直さず、ステップを追加してください。
型／名前の一貫性＋再利用の一貫性＋再利用の見落とし	同じ関数は、それに言及するすべてのタスクで同じ名前とシグネチャを使う必要があります。Reuse: の行が設計セクションの Reuse: の行と一致しないタスクがあれば、指摘してください。また、タスクの Files Create が、スキャンダイジェストまたはすでにインストール済みの依存関係にあるものを作成している場合も指摘してください。代わりに既存のものを利用します（inspect-change の reuse-miss に相当するタスク粒度の確認であり、助言であって強制的なブロックではありません）。
仕様との整合性＋上流への反映	requirements.md をもう一度読み、各基準を、それを満たすとするタスクと照合してください。要件が単に未網羅なのではなく、記述どおりでは誤りまたは実現不可能だと判明した場合は、requirements.md を修正して、承認を得るために再提示してください。要件をそのまま残したまま、タスクに回避策を埋め込んではいけません。誤った要件を満たす計画では、誤りをそのままリリースすることになります。
独立した計画レビュー（自分でレビューせず、依頼する）	上記の確認はドキュメントのみを対象とし、ここで行います。コードベースとの比較は対象外です。計画、requirements.md、design.md、リポジトリをレビュー用サブエージェントに渡し、計画が主張するすべてのシンボル、シグネチャ、パス、インポート、ハードコードされたテスト値について、実際のコードを根拠に検証させてください。架空の期待値や推測した API は、計画でよくある不備です。file:line を引用し、判断に迷う場合は指摘するようにします。指摘事項は .skills/<CODE>/plan-review.md に記録し、実行を提案する前に修正してください（サブエージェントがいない場合は、自分で比較してください）。1 つのトライアドに 1 つの計画（参照先は 1 つ）を確認してください。

完了条件： すべての要件 ID にタスクフッターがあり、合意した境界で動作を検証するテストが計画されていること。audit-trace、seam-table の照合、プレースホルダースキャンに問題がないこと。

ステップ 5（任意）：課題トラッカーに公開する

リポジトリにトラッカーがない場合（docs/agents/issue-tracker.md が存在しない、または Tracker: が空／none）→このステップをスキップします（未完了ではありません）。それ以外の場合は、このファイルの隣にある publish-recipe.md を読み、記載どおりに正確に従います。Publish unit を解決し、課題本文を作成して、ID を .skills/<CODE>/ の下に記録します。 既定であり、トラッカーに表示する唯一の単位は、計画ごとに1 件の機能課題で、 機能 PR によってクローズされます。

考え	実際
「タスクが 4 つある → エージェントが並行して着手できるよう、課題も 4 件作る」	作業の波は tasks.md と Depends-on を読みます。トラッカーのノイズは並列性ではありません
「サブ課題ならノイズなしで階層を維持できる」	単位が feature の場合、タスクはトラッカーのチケットではありません
「publish-issues は常にスライスごとに 1 件の課題を意味する」	非 triad の場合のみです。このステップでは Publish unit に従います
「タスクを公開しておこう。余分な分はユーザーがクローズできる」	単位が feature の場合、余分な課題は不備です
「タスクが多い — 設定でいう単位はタスクに違いない」	規模によって Publish unit が決まることはありません。ファイル内の行、またはユーザーの明示的な指示だけで決まります

危険信号 — ステップ 5

• 単位が feature なのに、triad の課題が複数ある、または計画のタスクに似たタイトル（Task N:）の課題がある
• 計画の規模だけを根拠に Publish unit: tasks を設定、または前提とする
• 権限エラー後にタスク課題へ切り替える

完了条件： スキップ（トラッカーがない／公開できない）、または単位が feature で機能課題が正確に 1 件（ID、計画パス、ID を .skills/<CODE>/ の下に記録）、または単位が tasks で計画内のタスクごとに課題が 1 件あり、ID が記録されていること。

変更マップ — オペレーターから求められた場合

オペレーターが計画による変更を図やダイアグラム、マップで見たいと求めた場合、提示内容に変更マップを含めます。必須のサブスキル：craft-page、図の用途は before/after structure です。.skills//change-map.htmlを作成し、そのパスを伝えます。ベースラインの実行 4 回で図を求められた際、1 回は何も描かず、3 回は機能の呼び出しチェーンを ASCII で描きましたが、いずれも REFUND の Task 4 が同じinvoiceViewを書き換えることを示していませんでした。そのうち 1 回は、どちらの計画にもない統合済みのシグネチャinvoiceView(invoice, refunds, today)` を描いていました。

ファイルには、計画の **Files:** 行に記載されたすべてのパス（ドキュメントを含む）が該当します。初期の俳句風マップでは、計画が変更する docs/api.md が抜け落ち、その担当者も記載されていませんでした。それぞれについて grep -ln '<path>' docs/specs/*/tasks.md を実行します。ページには次を示します。

1. 該当するファイルすべて。新規か変更済みかを明記し、docs/agents/project.md の Ownership notes に記載された担当者も示します。
2. それらの間で計画が追加または変更する呼び出しとインポート。
3. 変更されたインターフェースを利用する外部の利用者すべて（設計の Surface: 行）。
4. 図そのものに、grep で見つかった他の計画のうち requirements.md が Shipped ではないものを、そのファイルでの衝突として示します。各計画が記述するシグネチャまたは変更内容も記載します。

返信内に図を直接描いても、たとえ「同じ範囲を網羅」していてもマップとは見なされません。ベースラインの図 3 枚はすべて返信内に直接描かれ、どれにも衝突は示されていませんでした。

完了条件：ページが存在し、4 項目すべてを含み、すべての衝突が図に示されていること。

終了

手順	ルール
1–2. 提示	FILE を提示して停止します — 会話上の合意は承認ではありません。承認されるのは書面の計画であり、execute ファミリーが実行されるのは承認済みの tasks.md に対してのみです。1つのトライアド、1つの計画（1つの置き場所）に従います。
3. 承認後	Status: Approved に設定します。Execution-mode: は unset のままにします（または変更しません）。自分で continuous や story-unit を記入してはいけません。
4. 3つのルートを提示	質問は1つで、選択肢は必ず3つです — 先に continuous と story-unit のどちらかを尋ねてはいけません（その聞き取りは廃止されています）。モードの書き戻しは、選択されたスキルが担当します。build-by-story：サブエージェントのルート。ストーリーから導出された、人間の承認を挟むレビュー単位を使います（story-unit を記入）。build-in-waves：サブエージェントによるウェーブで、タスク間に人間の確認による中断はありません（continuous を記入）。build-inline：コントローラーが test-first で順次実装し、実装担当のサブエージェントは使いません（記録のため continuous を記入しますが、単位ごとのゲートは実行しません）。推奨（ラベルのみ。モードを勝手に作らない）： ユーザー向け UI/UX、Team Solo/Small、または requirements.md に振る舞いに関するストーリーが2つ以上ある場合は、**build-by-story（推奨）**を先頭に付けます — その場合も3つすべて提示し、選択を待ちます。該当する条件がない場合は、ラベルを付けません（モードを勝手に作らず、規模を基準に既定値を決めません — 下記のゲート表を参照）。
5–6. 選択後、INDEX を更新	スキル名を挙げて引き継ぎます — 必須サブスキル：選択された build-in-waves、build-by-story、または build-inline を使用します（サブエージェントを使う2つのルートでは、まだ存在しない場合は先に必須サブスキルとして isolate-workspace を使用することを推奨します）。次に、docs/specs/INDEX.md 内の機能の行で、Status: が requirements.md と同じになっていることを確認します。

考え	実際
「PM が Approved にするだけと言った — continuous に決まっている」	3つのスキルを提示します。モードを勝手に作ってはいけません。
「先に continuous と story-unit のどちらかを尋ねてから、ルートを提示しよう」	質問は1つです。3つのスキルのどれを選ぶかを尋ねます。
「計画を完成形に見せるため、今 Execution-mode を記入しよう」	モードは実行スキルが記入します。

危険信号 — 終了

• 3つのスキルを提示する前に、continuous と story-unit のどちらかを尋ねる
• Execution-mode: を勝手に作りながら Status: Approved に設定する
• タスク数を理由に、このトライアドの残りの作業を新しい ROAD に分割する
• ルートを1つだけ提示する、または「LGTM、作って」を build-in-waves とみなす
• 推奨条件を満たしているときに、build-by-story に「（推奨）」を付けない

完了条件： 1つのトライアド、1つの計画が守られ、Status: Approved に設定され、 3つの実行スキルのうち1つが明示され（選択後に引き継がれ）、 Execution-mode: がここで勝手に作られておらず、INDEX.md の行が一致していること。