plan-to-task-list-with-dag

このスキルでは、単なる計画文ではなく、スケジュール可能な計画成果物を作成します。

譲れないルール：

1. AskUserQuestion を使い、スコープの見直しとモード選択から始めます。
2. 分解する前に既存コードを調査します。ファイルパスを決してでっち上げてはいけません。
3. 正規の計画オブジェクトを 1 つ作成し、そこから Markdown と JSON の両方を出力します。
4. 各タスクには、明示的な担当者、検証方法、依存関係の処理、および Agent フィールドが必要です。
5. スキル本体はワークフローに焦点を絞ります。計画スキーマ、エージェントの割り当て、例は references から読み込みます。
6. 各タスクには、テスト可能な受け入れ基準が 2～3 個必要です。そのうち少なくとも 1 個は、失敗またはエッジケースを扱います。
7. 3 ファイルを超えて変更するタスクは作成せず、循環依存を作らず、コードベースの構造を推測しません。
8. タスクが副作用（永続化、WAL、ネットワーク I/O、登録など）を主張する場合、その機能の提供元を明記します。
9. 新しいファイルについては、エクスポート、登録、配線の担当タスクを明示的に割り当てます。
10. プレースホルダーや機能しない配線のまま「完了」できるタスクは、意味的な仕上げを明示的な後続タスクに分割します。
11. JSON を唯一の信頼できる情報源とします。同じ正規の計画オブジェクトから Markdown を生成します。
12. 担当者、動作、復旧方法を定義せずに、「内部更新」「最終的にスキップ」「グレースフルデグラデーション」のような曖昧な契約表現を使いません。
13. ローカルでの再利用と外部参照を区別します。外部ドキュメントやクローンを、ローカルコードとして提示しません。

計画を DAG 形式のタスクリストに変換

入力

• $request：任意の機能または計画リクエストのテキスト

目標

安全に実行できる、具体的なタスク DAG を作成します。

• スコープを見直し済み
• 実際のリポジトリ構造に基づいている
• 並行作業が可能な程度に細分化されている
• .ulpi/plans/<plan-name>.md と .ulpi/plans/<plan-name>.json に保存されている

ステップ 0：計画の前にスコープを見直す

分解する前に、重複がないか簡単に確認します。

• 利用可能であれば、意味検索に codemap スキルを優先します。
• それ以外の場合は、Glob、Grep、Read を使います。

次の点を特定します。

• すでに存在するもの
• 再利用できるもの
• 新規に必要なもの
• 事前に必要となりそうなもの
• 対象外となりそうなもの
• リクエストの規模が、計画を立てるより直接実行するほうが適切なほど小さいかどうか

次に AskUserQuestion を使って、以下を確認します。

• 計画モード：EXPANSION、HOLD、REDUCTION
• タスク完了後のデフォルトレビュー：claude、codex、kiro、all、none
• スコープから除外する項目、または明示的な対象外事項

スコープの枠組みが確認されるまで、先に進んではいけません。

成功基準：ユーザーがスコープを確認し、計画モードを選択し、デフォルトのレビュー方針を選んでいます。

ステップ 1：実際のコード領域を調査する

タスクを書く前に、リポジトリを調査します。

• 関連する可能性のあるモジュールとディレクトリ
• リクエストを部分的に満たす既存コード
• 共有の統合ポイント：
  • パッケージルート
  • エクスポートバレル
  • レジストリ
  • ルーター
  • マニフェスト
  • 起動フック
• 公開インターフェース：
  • API ルート
  • CLI コマンド
  • 設定ファイル
  • スキーマ
  • 永続化形式

ルール：

• 可能であれば、codemap スキルによる意味検索を優先します。
• 文字列の完全一致検証には Grep を使います。
• タスクでファイル名を挙げる前に、実際のファイルを Read で確認します。
• パス、モジュール、既存ヘルパーを決してでっち上げてはいけません。

成功基準：計画に記載されているすべてのパスが、実際のリポジトリの調査結果に基づいています。

ステップ 2：計画の契約を記録する

タスク化する前に、計画の妥当性を支える条件を記録します。

• 前提条件
• 対象外事項
• 境界をまたぐ契約
• 副作用を提供する機能の提供元
• 共有の統合ポイント
• 実行が途中で止まった場合の出荷可能な範囲

以下の点を明記します。

• 永続化の提供元
• エクスポートおよび登録の変更を担当する者
• 安定性を維持する必要がある公開インターフェース
• 保持する必要がある失敗経路または分離の不変条件

成功基準：計画に、すでに満たされている必要がある条件と、明示的に対象外とする事項が記載されています。

ステップ 3：タスクを最小単位に分割する

次の条件を満たすタスクを作成します。

• 最小単位である
• ファイル単位でスコープが定義されている
• 依存関係を考慮している
• レビュー可能である

タスクのルール：

• 1 タスクあたり 1～3 ファイルを優先します
• writeScope 内のすべてのファイルに、明示的な役割を割り当てます
• すべてのタスクに次の項目が必要です。
  • TASK-NNN の ID
  • タイトル
  • 説明
  • Type
  • Priority
  • Effort
  • Agent（references/output-format.md の Agent Selection Reference を参照）
  • 受け入れ条件
  • writeScope
  • validateCommand
• タスクごとに、テスト可能な受け入れ条件を 2～3 個含めます。そのうち少なくとも 1 つは、失敗時またはエッジケースを対象にする必要があります
• 公開インターフェースについては、正確なシグネチャと例を固定し、誤った形式または誤ったルーティングを検証するチェックを追加します
• 書き換えや構成のタスクでは、既存のセマンティクスが気付かないうちに失われていないことを証明する条件を少なくとも 1 つ追加します
• 新しいファイルにエクスポートまたは登録が必要な場合、その担当を特定のタスクに割り当てます
• 構造の作成だけを行うタスクで、セマンティクスの強化がまだ必要な場合は、その後続作業を明示的に分割します
• validateCommand は必ずスライスの範囲に限定します。つまり、このタスクの writeScope と、すでに統合済みの依存タスクだけで成功し、無関係な作業に左右されず単独で実行できる必要があります。
  • コマンドの範囲はタスク自身のファイルに限定し、パッケージ全体を対象にしないでください。vitest の場合は pnpm --filter <pkg> exec vitest run <path/to/file.test.ts> を使用します。pnpm --filter <pkg> test -- <file> は使用しないでください。-- によって vitest が位置引数を無視し、パッケージ全体を実行するため、無関係な失敗や既存の失敗がこのタスクのゲートに混入し、正しいスライスが誤ってブロックされる可能性があります。
  • コマンドで実行するすべてのテストファイルは、このタスクの writeScope に含まれるか、統合済みの依存タスクによって成功が保証されている必要があります。このタスクが修正できない、別タスクの担当テストファイルを検証対象にしないでください。
  • 最終状態でしか成功しない、スイート全体または E2E のコマンドは避けます。2 つの要素をそれぞれ独立して検証できない場合は、1 つのタスクにまとめてください。

成功基準：各タスクは、隠れた前提なしで実行でき、独立してレビューできる十分小さな単位であること。

ステップ 4：依存関係を整理し、並列性を最大化する

依存関係を追加するのは、実際に必要な場合に限ります。

• ファイルの重複
• データフロー
• API 契約
• 共有される統合インターフェース
• 機能の提供元
• ライフサイクルまたはブートストラップの依存関係

過度な制約を避けます。

• 独立したタスクは並列のままにします
• 共有ファイルの編集は、隠さず明示します
• 循環依存は無効です

優先度には P0 から P3 を使用します。

• P0：ほかのタスクの開始を可能にする基盤
• P1：中核機能の作業
• P2：補助作業とエッジケース
• P3：任意の仕上げ、ドキュメント、クリーンアップ

成功基準：依存関係グラフが非循環で、最小限の依存関係で構成され、実際の並列実行レイヤーが明確であること。

ステップ 5：単一の正規プランオブジェクトから Markdown と JSON を生成する

出力を作成する前に、references/output-format.md を読み込みます。

次の 2 つのファイルを作成します。

• .ulpi/plans/<plan-name>.md
• .ulpi/plans/<plan-name>.json

要件：

• Markdown と JSON で同じタスクを記述すること
• 両方のファイルでタスク ID が完全に一致すること
• 依存関係の JSON を信頼できる唯一の情報源とすること
• 保存する Markdown に [PLAN] マーカーを含めないこと

成功基準：両方の成果物が存在し、同じ DAG を記述していること。

ステップ 6：完了前に検証する

最後に、次の項目を構造的に確認します。

• すべてのタスク ID が Markdown と JSON の両方に存在すること
• 依存関係の参照先がすべて存在すること
• 循環がないこと
• 実在しないファイルパスがないこと
• タスクの writeScope が妥当な範囲を超えていないこと
• 必要な場合、受け入れ条件にエッジケースまたは失敗時の挙動が含まれていること
• デフォルトのレビューが定義されていること

提示形式のパターンが必要な場合に限り、references/examples.md を読み込みます。

成功基準：プランがスケジュール可能で、内部に矛盾がなく、実行に着手できる状態であること。

ガードレール

• AskUserQuestion ベースのスコープ確認を省略しないでください。
• これを直接実装に切り替えないでください。
• 既存のファイル、ヘルパー、パッケージ境界を作り上げないでください。
• 巨大なサンプルや出力テンプレートを SKILL.md にインラインで記載しないでください。
• paths: を追加しないでください。これは汎用ワークフロースキルです。
• context: fork を追加しないでください。このワークフローでは、途中でユーザーとのやり取りが必要です。
• エージェント専用のヘッダーを導入しないでください。
• 3 ファイルを超えて変更するタスクを作成しないでください。
• 依存関係を過度に制約しないでください。独立したタスクは並列のままにしてください。
• 必須の共有ファイル編集を、狭い書き込みスコープの背後に隠さないでください。
• タスクで定義していない機能を必要とする副作用を、タスクが担うものとして扱わないでください。
• 外部ドキュメント、クローン、ウェブ調査を、リポジトリ内にパスが存在するかのように提示しないでください。
• P1-P4 の優先度を使わないでください。このスキルでは P0-P3 を使用します。
• 正式なプランオブジェクトから導出できる件数、レイヤーの概要、依存関係の参照を、JSON と Markdown の間で別々に手作業で管理しないでください。

参照資料を読み込むタイミング

• references/personality.md セッション開始時に、役割、専門知識、特性、コミュニケーションスタイルを確認するために使用します。
• references/knowledge.md DAG のセマンティクス、パーサーの前提、プランオブジェクトに関する知識の確認に使用します。
• references/output-format.md 最終的な Markdown と JSON の成果物を出力する前に使用します。
• references/examples.md 類似の依頼に対するサンプルの形式が必要な場合にのみ使用します。

出力要件

以下を報告してください。

1. 選択したモードとレビューのデフォルト
2. プランファイルのパス
3. タスク数とクリティカルパスの概要
4. 主な前提条件と対象外事項
5. 特筆すべきリスクやカットラインの判断