write-plan

承認済みの要件と設計から docs/specs/<YYYY-MM-DD>-<feature>/tasks.md を作成します。スキルセットの templates/tasks.md を起点にします。プラグインとしてインストールされている場合は ${CLAUDE_PLUGIN_ROOT}/templates、それ以外の場合はこの SKILL.md からの相対パス ../../../templates として templates/ を解決してください。タスクブロックのすべての項目（Files、Interfaces、Depends-on、Steps、_Requirements:_）は必須です。タスクごとのリスクラベル、判断面フラグ、または Human-review-order セクションは作成しないでください。リスクは実際の差分に対する allocate-attention のリスクグロブで測定されます。レビュー単位は、Execution-mode: story-unit の場合、execute-story の実行時にユーザーストーリーから導出されます（このスキルを参照）。

作業を始める前に、各ステップ（1～4。リポジトリで課題管理システムを使用している場合は5も）の TODO を作成し、順番に完了してください。このスキルは、上流の write-design と下流の execute ファミリーそれぞれのリストとは別に、独自のリストを管理します。各項目は、その Done when: が満たされた場合にのみ完了にしてください。

コードベースや問題領域について何も知らず、自分のタスクと Global Constraints だけを確認する、スキルは高い実装者に向けて記述してください。必要な名前、パス、コマンド、型をすべてタスクに記載してください。

ステップ 1：ヘッダーと Global Constraints

Goal（1文）、Architecture（2～3文）、Tech Stack を記載します。ヘッダーには次の必須フィールドも含めます。

Execution-mode: <unset | continuous | story-unit>

ルートは提示されます。モードは記入必須のフィールドです。 Exit まで値を unset のままにしてください。計画の規模、バンド、または慣例から continuous/story-unit を推測して設定してはいけません。このフィールドにプロジェクトレベルのデフォルトはありません。

続いて Global Constraints を記載します。設計と docs/agents/project.md から、プロジェクト全体に適用されるルールを一字一句そのまま転記してください。対象には、テスト／lint／型チェックのコマンド、命名規則と i18n ルール、禁止されている変更を含めます。すべてのタスクの要件には、このセクションが暗黙的に含まれます。セクションの内容は各タスクのブリーフにも引き継がれます。## Team が存在し、roster が空でない場合、またはバンドのオーバーライドがある場合に限り、そのセクションから band を導出し、packaging を適用します。Solo タスクでは複数担当者がいるように装わず、Small／Multi では任意の自由形式の担当者／レビューに関するメモを追加できます（新たな必須タスク項目は追加しません）。Team がない場合は、機能着手前のデフォルトを使用します。

docs/architecture/ の骨格が存在する場合は、ARCH-N のハード制約も Global Constraints に含め、すべてのタスクに適用します。骨格がなければ、追加する制約はありません。また、利用者向けのエンジニアリングルール（命名規則、i18n、プロジェクト内ルール）は、docs/product/guidelines.md が存在する場合はそこから取得し、存在しない場合は前述のとおり docs/agents/project.md から取得します。ガイドライン文書が存在する場合、これらのルールはそこに記載されています。

Done when: Goal、Architecture、Tech Stack、Execution-mode:（unset のままでもかまいません）、および Global Constraints が記載され、同セクション内のすべてのコマンド、命名規則／i18n ルール、ARCH-N 制約が、言い換えではなく、それぞれのソースファイルから一字一句そのまま転記されています。

ステップ 2：最初にファイル構成を整理する

タスクを書く前に、計画で作成または変更するすべてのファイルを一覧にし、それぞれの役割を1行で記載します。一覧にないファイルには、どのタスクでも変更を加えてはいけません。

Done when: 計画で作成または変更するすべてのファイルが、1行の役割説明とともに一覧に記載されています。

ステップ 3：垂直スライスとしてのタスク

契約 — タスクは垂直スライスです： 独自のテストサイクルを備え、独自のレビュー判定に値する最小単位です。レビュー担当者が、あるタスクを却下しながら隣のタスクを承認できる場合に限って分割します。

形状： 1つのユーザーストーリーに取り組む場合、各タスクにつき、デモ可能なエンドツーエンドの成果を1つにします。後続のスライスを可能にするだけの事前リファクタリングは、Depends-on のエッジを付けた独立した先行タスク（「変更を容易にしてから、容易になった変更を行う」）にします。ストーリーのタスクに水平レイヤーを埋め込む理由にはなりません。

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

• Files： 作成／変更（正確なパス。分かる場合は行範囲も記載）／テスト。
• Reuse： このタスクが基盤として利用する、既存の具体的なコード、ライブラリ、またはパターン。設計セクションの Reuse: 行から、同じ <rung> — <concrete target> の形式でそのまま引き継ぎます。これにより、実装者は再実装するのではなく、それを基盤として構築することが分かります（例：設計セクションの Reuse: 行からそのままコピーした Reuse: existing — src/util/dates:parseISO (rung 2)）。 ステップ 4 では設計の Reuse: 行との照合が行われるため、解釈し直さず、そのままコピーしてください。
• Interfaces： Consumes／Produces — 隣接するタスク間で共有する名前と型です。このブロックにより、個別に実装を担当する人が何を呼び出すかを把握できます。
• Depends-on： このタスクが本当に必要とする先行タスク、つまり、このタスクがインターフェースを Consumes するタスク、またはそのファイルを基盤として使うタスクを Depends-on: Task 2, Task 4 のように指定します。前提タスクがない場合は Depends-on: none とします。これは並列実行の判断材料です。ファイルもインターフェースも共有しない2つのタスクはエッジを宣言しないため、execute-plan はそれらを同じ並列ウェーブで実行できます。この行を省略すると、タスクはすべての先行タスクに依存する形になります。安全ですが、完全な直列実行になります。依存関係を過剰に宣言すると不必要に直列化され、過少に宣言すると、衝突が起きる前に実行側のファイル非重複チェックで検出されます。
• Steps： TDD サイクルに沿った、細かいチェックボックス（各 2～5 分）です。失敗するテスト（コードをすべて記載）→ 実行し、記載した失敗を確認 → 実装（コードをすべて記載）→ 実行し、成功を確認 → Implements: CODE-N.M のトレーラーを付けてコミット、の順に記述します。
• Footer： _Requirements: CODE-N.M, CODE-N.M_ — このタスクが実装または保護する ID です。各タスクに必ず1つ付けます。デフォルト：1つのストーリーの ID（ストーリー番号 N は同じ）。複数ストーリーのフッターは、execute-story のもとでそれらのストーリーを1つのレビュー単位に統合します（計画品質の判断材料です。禁止事項ではなく、Depends-on を偽る理由にもなりません）。

Depends-on はビルドのウェーブを決定します。タスクが必要とするものを偽ることになる場合、レビュー単位を整えることだけを目的として依存関係を並べ替えたり、狭めたりしてはいけません。

考え方	実際
「先に事前リファクタリングするのが常に正しい — 変更を容易にしよう」	Depends-on による事前リファクタリングは問題ありません。ただし、execute-story ではレビュー単位は引き続きストーリーの引用に従います
「レビュー担当者に気づいてもらえるよう Risk: high を追加しよう」	そのようなフィールドはありません。エージェントのラベルの代わりに、実際の差分に対するリスクのグロブを使います
「人が先に読む箇所が分かるよう、Human review order を書こう」	これは廃止されました。ストーリーから導かれる単位がレビュー順です。利用側のない追加のリストは削除されます
「PM が Approved とマークするだけでいいと言っていた — continuous は明らかだ」	明らかでも、記載されていなければ分かりません。Execution-mode が空欄なら Approved ではありません
「5分後にスタンドアップがある／計画に40分かかった — モードの質問は省略しよう」	時間や埋没コストによって変わるのは、モードをいつ尋ねるかであり、モードがフィールドであるかどうかではありません
「タスクが4つなら、デフォルトは continuous」	サイズに基づくデフォルトはありません。ユーザーが continuous か story-unit を選びます

プレースホルダーは禁止です。 「TBD」、「適切なエラー処理を追加」、「Task 3 と同様」、またはどのタスクにも定義されていない型への参照 — これらはいずれも計画上の不備です。計画をリリースする前に修正してください。

完了条件： ステップ 2 のマップに記載されたすべてのファイルが、少なくとも1つのタスクに含まれており、各タスクが独自のテストサイクルを備えた垂直スライスとして記述されていること。スロットとプレースホルダーに問題がないかの確認はステップ 4 で行います。このステップでは確認しません。

ステップ 4：カバレッジと一貫性の確認

• トレースチェックを実行します（必須サブスキル：trace を使用）。すべての Approved 要件が、少なくとも1つのタスクのフッターに記載されている必要があります。記載のない ID がある場合、計画は不完全です（または、その要件に取り消し線を引き、理由を記載する必要があります）。
• 引用だけでなく、テストカバレッジも確認します。 各要件 ID は、少なくとも1つのタスクの手順内にあるテスト注釈にも記載する必要があります（Vitest のタイトル内の [CODE-N.M]、Rust テスト上の /// REQ: CODE-N.M、Playwright タグ内の @CODE-N.M）。フッターに記載するだけでは不十分です。フッターで引用されているものの、タグ付きテストがない場合、トレースチェックでは合格となります（Approved → W1）が、機能が Implemented とマークされた時点で E2 に失敗します。ガード要件や否定的な要件は、実際のテストで検証されている場合にのみ対象となります。ある動作を単体テストで切り分けてテストできない場合は、e2e タスク、またはすでにその動作を検証している既存テストにタグを付けます。1つのテストに複数の ID を付けてもかまいません。
• 設計のシーム表と照合します。 design.md に「テスト対象のシーム」表がある場合、各行のすべての ID を、計画内のテストにタグ付けする必要があります。設計でカバーすると約束したのに、計画でタグ付けされていない ID は、カバレッジの欠落です。番号は振り直さず、テストを追加してください。
• タスク間で型と名前の一貫性を保ちます。同じ関数は、それに言及するすべてのタスクで同じ名前とシグネチャを使用する必要があります。
• コンポーネントレベルの再利用漏れ： タスクの Files Create が、スキャンダイジェストまたはすでにインストールされている依存関係で提供されているものを作成しようとしている場合は指摘します。再構築するのではなく、既存のものを活用してください。これは、機能の重複に対して code-review が指摘する reuse-miss と同じ考え方を、タスクの粒度に適用したものです。これは助言的な指摘であり、必須のブロック条件ではありません。
• 再利用の一貫性： タスクの Reuse: 行が、そのタスクで実装する設計セクションの Reuse: 行と一致しない場合は指摘します。
• 仕様との整合性：requirements.md をもう一度読み直し、各基準を、それを満たすとするタスクと照合します。
• 上流へのフィードバック：計画中に、要件が単にカバーされていないのではなく、記述どおりでは誤りまたは実現不可能だと判明した場合は、requirements.md を修正し、再度承認を求めます。要件をそのままにしてタスク内に回避策を埋め込んではいけません。誤った要件を満たす計画は、その誤りをそのままリリースしてしまいます。

計画の独立レビュー — 自分でレビューせず、委任します。 上記の確認はドキュメントのみを対象とし、コードベースとの照合は含みません。計画、requirements.md、design.md、リポジトリをレビュー用サブエージェントに渡し、計画に記載されたすべてのシンボル、シグネチャ、パス、インポート、ハードコードされたテスト値を実際のコードと照合するよう依頼します。捏造された期待値や推測による API は、計画の典型的な欠陥です。file:line を引用し、問題があれば指摘する方針で進めます。指摘事項は .skills/<slug>-plan-review.md に記録し、実行を提示する前に修正してください。（サブエージェントが使えない場合は、コードと自分で照合してください。）

完了条件： すべての要件 ID がタスクのフッターとタグ付きテストの両方に記載され、トレースチェックに問題がなく、設計のシーム表にある ID がすべてカバーされ、プレースホルダースキャンに問題がないこと。

ステップ 5（任意）：課題追跡システムに公開する

リポジトリで課題追跡システム（docs/agents/issue-tracker.md）を使用している場合は、依存関係の順序に従って各タスクを課題として公開します。対応している場合は、ネイティブのサブ課題とブロック関係のリンクを使用します。本文では動作とインターフェースを説明し（ファイルパスは記載しません）、受け入れ基準と Requirements covered: の一覧を含めます。

これは、トレーサビリティを重視した本格的な公開方法です。各課題に、その要件 ID が記載されます。仕様の三点セットを経由しなかった作業（生の会話やアイデアなど）を記録する場合は、代わりにユーザーが file-issues を実行します。これらのタスクをそちらに重複して登録しないでください。

完了条件： tasks.md のすべてのタスクに課題があり、各課題に Requirements covered: の一覧が記載され、ブロック関係のリンクが計画の依存関係の順序と一致していること。課題追跡システムが設定されていない場合、このステップは保留ではなくスキップします。

終了

FILE をユーザーに提示し、承認を求めて停止します。会話上の合意は承認ではありません。承認されるのは書面の計画であり、execute ファミリーは承認済みの tasks.md に対してのみ実行されます。

Execution-mode は経路ではなく、承認の一部です。 Status: Approved を設定する前に、ユーザーが Execution-mode: continuous または Execution-mode: story-unit を選択し、その値をヘッダーに記載する必要があります。 unset、空欄、または未設定の場合は、Status: Approved を設定しないでください。フィールドが空だからといって、continuous を既定値にしてはいけません。空欄は未承認を意味します。

モード	意味
continuous	タスク間に人による一時停止を挟みません（サブエージェント経路）
story-unit	ストーリーから導かれる、人による承認を要するレビュー単位です（サブエージェント経路）

モードを記載し、ユーザーが計画を承認したら、Status: Approved を設定し、正確に3つの経路を提示します（実行方法。インライン実行ではモードと独立しています）。

1. execute-plan — Execution-mode: continuous で、サブエージェントのウェーブを使用する場合に選択します（continuous の推奨既定値）。worktrees を使った隔離ワークスペースを優先してください。
2. execute-story — Execution-mode: story-unit の場合に選択します（単位ごとのゲートが必須です。story-unit では execute-plan を提示しないでください）。worktrees を優先してください。
3. execute-inline — コントローラーが tdd を使って順番に実装し、実装担当のサブエージェントは使用しません（サブエージェントを使えない環境、または各ステップを見届けたい場合）。どちらのモードのヘッダーでも使用できますが、単位ごとのゲートは実行しません。

まず、選択したモードに対応するスキルを提示します。サブエージェントを使わない場合は execute-inline を提示します。docs/specs/INDEX.md にある機能の行の Status: が、その機能の requirements.md と一致していることを確認してください。

完了条件： ユーザーが書面の tasks.md を承認し、Execution-mode: が continuous または story-unit で、Status: が Approved となり、対応する実行スキルが提示され、INDEX.md の行も一致していること。