plan-maker

プランメーカー

不完全な入力から PlanWeave パッケージ形式の計画ドラフトを作成するには、このスキルを使用します。ユーザーが具体化を依頼した場合にのみ、パッケージファイルを書き込みます。既存のパッケージを監査するには plan-auditor を使用します。実行は別のタスクであり、実行の依頼が必要です。

必須の計画チェックリスト

計画チェックリストを使用して、計画の構造、実行オプション、受け入れ基準、パッケージの妥当性を確認します。

クイックスタート

1. ユーザーの目標、対象外事項、制約、想定される成功基準を言い換えて確認します。
2. 作業を進めるうえで妨げとなる確認事項だけ質問し、それ以外は前提を明示して続行します。
3. README、現在のコード、スキーマ、テスト、サンプル、関連ドキュメントから必要最低限の情報を集めます。
4. 中核となるオブジェクト、ライフサイクルの段階、契約、リスク、検証方法を特定します。
5. タスク、ブロック、依存関係、プロンプトの配置、レビューゲート、検証をドラフトし、PlanWeave の既存パッケージの概念に沿ってタスクをキャンバスにまとめます。
6. 未解決の前提と、推奨する次のアクション（ユーザーと内容を詰める、plan-auditor で監査する、または明示的な依頼を受けてドラフトを具体化する）を最後に示します。

コンテキストの調査

• 信頼できるソースドキュメントがあり、主な作業がそれらを Plan Package に変換することである場合は、plan-importer を使用します。
• ドキュメントがない場合は、アーキテクチャを捏造しないよう、現在のコードベースを十分に調査します。
• タスクを分割する前に、中核となるオブジェクトの候補について、生成側と利用側の両方を調べます。
• ユーザーの目標を最優先しますが、不確かな範囲、不足しているドメインルール、不明な外部依存関係には印を付けます。
• 計画を完全に見せるために、大規模な製品要件を捏造しないでください。

計画の原則

• 中核となるオブジェクトのライフサイクルを中心に設計します。作成、検証、変換、状態管理、保存、利用、副作用、最終出力、失敗、再試行、ロールバック、手動介入を考慮します。
• スキーマ、型、API、CLI フラグ、イベント、ファイル、プロンプトの入出力について、生成側と利用側の間で一貫性を保ちます。
• データフロー、契約の境界、担当範囲、リスク、または独立して検証可能な受け入れ基準に沿ってタスクを分割します。
• ノード数を増やすことだけを目的に分割しないでください。独立して主張、テスト、報告できない小さなタスクは統合します。
• キャンバスは一貫性のある成果物をまとめるもので、タスクは独立して検証可能な成果を担い、ブロックはその実行とレビューの手順を表します。設計の詳細はプロンプトに記述し、抽象化の度合いは作業の規模に見合うものにします。
• 一貫性のある成果物には、実装、テスト、受け入れをタスクまたはブロックとして表現し、デフォルトではキャンバスを1つにします。独立して提供または保守される範囲には複数のキャンバスを使い、それぞれの具体的な境界を示します。単一キャンバスの計画では、新しい project-graph.json の具体化を省略できます。複数キャンバスの計画では正式なプロジェクトグラフを使用します。
• 必須の実行順序は、プロンプトや説明文だけでなく、グラフの依存関係とゲートで表現します。
• 並列タスクは、データと契約のタイミングにおいて真に独立している必要があります。共有ファイル、設定、ビルド出力への書き込みは、分離するか調整します。
• 重複するリソースは parallel.sharedResources に記録します。これは参考情報であり、ロックではありません。共有リソースへの書き込みを調整できない場合は同時実行数を制限し、人工的な依存関係を追加するのではなく、スケジューリング設定を使用します。
• 基盤となる契約とランタイムの動作が安定する前に、広範な UI やパッケージの仕上げ作業を予定しないでください。
• 対象リポジトリの既存の規約に従います。

Plan の形

パッケージ形式の計画案と、人が読める説明を出力します。計画案では、後で具体化する際の信頼できる情報源として、PlanWeave の既存の概念であるプロジェクトグラフ、キャンバス、タスク、ブロック、依存関係、プロンプトファイル、レイアウトを使用してください。Markdown レポートは説明用のビューにすぎません。

ファイルを書き込まない場合は、新しいスキーマではなく、パッケージファイル計画として計画案を示してください。複数キャンバスのオーケストレーションで必要な場合は、プロジェクトグラフのフィールドを含めてください。

Project:
  title: ...
  projectGraph: project-graph.json

Canvases:
  - id: ...
    packageDir: ...
    manifest: .../manifest.json
    tasks: ...

Dependencies:
  canvas: ...
  crossTaskEdges: ...

Prompts:
  .../nodes/.../prompt.md

人が読める計画の説明には、次の Markdown セクションを推奨します。短いセクションは統合し、該当しないセクションは省略してください。タスクとブロックのソースプロンプトについては、「プロンプトの配置」を参照してください。

## Goal
## Assumptions And Open Questions
## Canvas Strategy
## Project Graph
## Task Graph
## Prompt Placement
## Review Strategy
## Verification Strategy
## Risks And Recovery
## Handoff

各タスクには、次の情報を含めてください。

• タスク ID、タイトル、所有キャンバス、目的、受け入れ条件、依存関係、想定されるファイル。
• 種類、目的、共有リソース、完了条件、検証、レポートの要件を含むブロック。
• 「レビュー戦略」で定義されている、該当するレビューゲート。
• 複雑なブロックには、アーキテクチャの境界、テストの配置場所、設定や環境変数の扱い、該当する場合は README または .env.example の更新、実際のプロバイダーとモック／ドライランに関する要件を含めてください。

複数キャンバスの計画案には、次の内容を含む Project Graph セクションを設けてください。

• キャンバス ID、タイトル、パッケージディレクトリ、および各キャンバスの目的。
• ステージ、機能、サブシステム、またはワークフローの順序を表す、キャンバスレベルの依存関係エッジ。
• 複数キャンバスの計画案では、crossTaskEdges: [] をデフォルトにしてください。
• タスク間エッジを追加する前に、密接に関連するタスクを同じキャンバスに移すか、関係がステージ、機能、サブシステム、またはワークフロー全体の順序を定める場合はキャンバス依存関係エッジを使用してください。
• 明示的な crossTaskEdges は、まとまりがあり独立して実行できるキャンバス間にある、少数で解消困難なタスク間のブロッカーに限って使用してください。
• 同じキャンバス間に高密度または繰り返し発生するタスク間エッジ、タスクエッジで表現されたステージ全体の順序、キャンバスの順序と重複するタスクエッジは、キャンバス境界の欠陥として扱ってください。タスクを再分割するか、依存関係を上位のレベルに引き上げてください。
• どのキャンバスを並行して実行できるか、またそのデータ、契約、上流のブロッカーが互いに独立している理由。 共有書き込みの分離または調整方法と、適用される並行処理の制限を明記してください。
• 手動でグラフを編集する前提があれば、その内容。

プロンプトの配置

• グローバル／プロジェクトのプロンプト：共通の目標、アーキテクチャ規則、コーディング規約、参照資料、横断的なリスク。
• タスクのプロンプト：タスク固有のコンテキスト、受け入れ条件の根拠、依存関係、想定されるファイル。
• ブロックのプロンプト：具体的な実行手順、制約、検証コマンド、レポートの要件。
• 要件は、計画レポートだけでなく、ソースプロンプトまたはタスクの受け入れ条件に記載してください。
• ブロックのプロンプトを空欄のままにしないでください。継承されたコンテキストで十分な場合は、具体的な完了条件を記載してください。

レビュー戦略

• ユーザーから依頼がない限り、単純なドキュメント、設定の微調整、文言の修正、リスクの低い局所的な修正ではレビューを省略してください。
• レイヤーをまたぐコード、スキーマ／API／CLI の契約、データベースの変更、プロバイダー連携、セキュリティ／プライバシー、アーキテクチャ、またはユーザーに見える挙動に関する高リスクの変更には、レビューを追加してください。
• レビューゲートには、設ける理由、実施担当者、合格条件、needs_changes が戻る先を明記してください。

検証戦略

• すべてのブロックに、コマンド、テスト、出力成果物、状態遷移、またはエンドツーエンドのフローなど、観測可能な完了条件が必要です。
• モック、ドライラン、ライブパス、実際の成果物を区別してください。
• 「実装済み」、「ロジックが正しい」、「使えそう」といった受け入れ条件は認めないでください。
• 機能の確実な実行に必要な場合は、失敗時の経路も検証対象に含めてください。

ルール

• このスキルが生成するのは、パッケージ形式の計画ドラフトであり、実行時の状態ではありません。
• コンテキストノードは作成せず、コンテキストはプロンプト、受け入れ条件、または参照に記載してください。
• feedback ブロックは作成しないでください。フィードバックは実行時の状態です。
• マテリアライズする際は、パッケージ形式の計画ドラフトを正本として扱ってください。PlanWeave CLI でワークスペースを解決し、宣言されたパッケージファイルを書き込み、PlanWeave CLI で検証して、残っている診断結果を報告してください。
• キャンバスの作成、パスの割り当て、ID の重複排除、アクティブなキャンバスの選択、検証、復旧トランザクション、実行時の状態や結果の変更など、機械的なワークスペース操作には CLI／ランタイムコマンドを使用してください。
• Plan Package の意味的なファイルは、CLI が返したワークスペースパス内で直接編集してください。対象は、キャンバスの意図と依存関係を記述する project-graph.json、各キャンバスのタスク／ブロック／エッジ／受け入れ条件／プロンプトパスを記述する manifest.json、およびソースのプロンプト Markdown です。
• 意味的な変更を正確に表現できる場合は、範囲を絞った CLI 編集コマンドを使用してください。それ以外の場合は、ソースパッケージファイルとプロンプトを直接更新してください。
• 計画を直接編集した後は、編集したキャンバスに対してキャンバス単位の検証を実行してください。また、project-graph.json、キャンバスエッジ、または crossTaskEdges を変更した場合は、プロジェクト検証も実行してください。
• 統合とレビューが、必要な上流の作業によってブロックされていること、および並行実行の設定が共有リソースの制約と一致していることを確認してください。Desktop が利用可能な場合は、表示されているタスク、依存関係のエッジ、読みやすいレイアウトを確認し、未検証の項目があれば報告してください。
• ドラフトが実行を目的としている場合、リスクが高ければ、インポート前に監査することを推奨してください。