plan-tasks

準備

対象のフィーチャー名を確認し、設計仕様の存在を確認する。

• .artifacts/features/<feature>/specification.md が 存在する 場合: フェーズ 1 へ進む。
• 存在しない 場合: ユーザーへ通知し、先に design-spec を実行するか、仕様をインラインで提供するよう案内する。

フェーズ 1: 入力分析

• .artifacts/features/<feature>/requirements.md と .artifacts/features/<feature>/specification.md を読み込む。
• 受け入れ基準・前提条件・制約を特定する。
• .artifacts/project_architecture.md があれば読み込み、影響を受けるコンポーネントと再利用できるパターンを把握する。
• 不明点があれば AskUserQuestion で確認する。

フェーズ 2: タスク分解

作業をフェーズへ、フェーズをタスクへ分解する。分解の観点:

• 共有ユーティリティ / 型定義
• DB / API スキーマ変更
• バックエンドロジック実装
• フロントエンドコンポーネント実装
• テストコード

各タスクには次を定義する。

• タスク ID: task_<phase_num>_<task_num> 形式で一意に採番する（例: task_1_1、task_2_3）。 タスク番号は phase ごとに 1 から開始する。
• 概要: 何を実装するか（WHAT）と、なぜ必要か（WHY）。
• 対象ファイル（概算）: 変更が見込まれるファイル。
• 依存関係: 先行して完了している必要があるタスク ID（無ければ「なし」）。
• 想定規模: 後述のコンテキスト・コスト基準で見積もる。

フェーズ 3: 規模の見積もり（コンテキスト・コスト基準）

タスクの粒度は「時間」ではなく コンテキスト・コスト で判断する。

• 基準は「変更が必要なファイル数」と「予想されるトークン消費量」。
• 1 つのタスクに変更を詰め込みすぎると、実行する coder のコンテキストが溢れて品質が劣化する。
• 目安として 1 タスクあたり数ファイル程度に収め、溢れそうなら分割する。

フェーズ 4: 依存関係と Wave 設計

• タスク間の依存グラフを整理する。
• 互いに独立したタスク群は同じ Wave に置き、並列実行の候補とする。
• 依存先のあるタスクは後続の Wave に置く。
• 各タスクが独立して検証可能であることを確認する。
• 共通ファイル排他: 同じファイルを編集する複数タスクは同一 Wave に置かない。 並列実行する coder 同士が同じファイル（例: __init__.py の __all__ 集約、 pyproject.toml の依存リスト、共有設定ファイル）を編集すると編集衝突が発生し、 後勝ち上書きや片方の追記の消失を招くため。共通ファイルを編集するタスクは別 Wave へ分け、 順次実行する。判定が難しい場合は、plan.md の「対象ファイル」列を相互比較する。

フェーズ 5: 完了の扱い

計画が固まった時点で本スキルの責務は完了とする。成果物ファイルへの書き出し・ユーザーへの報告・ 次フェーズへの案内は本スキルでは行わない。これらは呼び出し元（コマンドまたはエージェント定義）が担う。