plan-founder-review

このスキルは、読み込みを中心とする計画監査ワークフローです。以下のルールは必ず守ってください。 1. 計画書の Markdown 全文と、存在する場合は対応する JSON を読みます。 2. 計画書の記述を鵜呑みにせず、実際のコードベースと照合して内容を検証します。 3. 依存関係の欠落、実在しないパス、根拠のない再利用の主張、意味上の不備を指摘します。 4. 必須のレビューセクションをすべて完了してから、判定を提示します。 5. 呼び出し本文はレビューの反復に焦点を絞り、詳細な確認事項と判定ルールは参照資料から読み込みます。

創業者レビュー

入力

• $request：任意の計画名、計画書への直接パス、またはモード指定（auth-system、.ulpi/plans/foo.md、--quick、foo --full など）。

目標

エージェントが実行する前に、計画の不備を見つけます。実在しないファイルパス、Markdown と JSON の不整合、隠れた前提条件、不適切なタスクの分け方、危険な書き換え、テストの欠落、過度に楽観的な実行グラフなどが対象です。

ステップ 0：対象の計画書とレビュー方式を決定する

レビュー対象の計画書を特定します。

• $request に計画名が指定されている場合は、.ulpi/plans/<name>.md を解決します
• $request に直接パスが指定されている場合は、そのパスを使用します
• 対象が指定されていない場合は、.ulpi/plans/ 配下で最も最近変更された .md 計画書を選択します

次に、以下を行います。

• Markdown の計画書全文を読む
• 対応する JSON ファイルがあれば読む
• タイトル、モード、タスク数、タスク ID、ファイルパス、依存関係の概要を抽出する
• レビューモードが FULL か QUICK かを判断する

以下については、references/review-rubric.md を読み込みます。

• モードの選択ルール
• モードごとに必要なセクション
• 判定基準

以下の場合は、早期に終了します。

• 計画書が存在しない
• Markdown の計画書を読み込めない
• 対象が創業者による正式レビューを行うには小規模すぎ、直接実行すべきである

成功基準：詳細なレビューを開始する前に、対象の計画書とレビュー方式が明確になっていること。

ステップ 1：コードベースの実態を確認する

実際のリポジトリと照合して計画を検証します。

• すべての filesToModify パスが存在する
• すべての filesToCreate パスに有効な親パスがあるか、それを作成する先行タスクがある
• Markdown と JSON でタスク ID、ファイルパス、実行上の意味が一致している
• 再利用すると主張しているものが、実際にローカルに存在する
• 計画で、すでに存在する機能を再構築していない
• 計画で公開 SQL、API、または CLI のインターフェースを導入する場合、曖昧な説明で済ませず、実際のシグネチャまたは使用例を明記している

references/review-checklist.md を読み込み、セクション 1 をすべて完了します。

成功基準：計画のファイルパス、再利用の主張、成果物の整合性が、リポジトリの実態と照合されていること。

ステップ 2：スコープと戦略を精査する

以下をレビューします。

• 計画のモードが実際のスコープに合っているか
• すべてのタスクが明示された目標に寄与するか
• 非目標に妥当性があるか
• リリース対象の範囲が実現可能か
• 隠れた前提条件やスコープの拡大がないか

references/review-checklist.md を読み込み、セクション 2 を完了します。

成功基準：スコープ、モード、最低限リリース可能な範囲に妥当性があること。

ステップ 3：アーキテクチャ、契約、依存関係を監査する

以下をレビューします。

• アーキテクチャ図に必要な情報がすべて含まれているか
• タスクの内容が図と一致しているか
• 生成側と利用側の契約が明確か
• 依存関係 JSON が現実的か
• 実行概要に矛盾がないか
• ルーター、レジストリ、マニフェスト、起動フック、エクスポート用バレルなど、共有の接続箇所に担当者が割り当てられているか
• 書き換え、プランナー、オプティマイザー、フィルター、クエリ合成における意味上の安全性が確保されているか

references/review-checklist.md を読み込み、セクション 3 を完了します。

レビューモードが QUICK の場合は、このステップの後、ステップ 6 に進みます。

成功基準：計画のアーキテクチャと依存関係が一貫しており、実行可能であること。

ステップ 4：リスク、復旧、縮退モードの安全性を監査する

FULL レビューの場合のみ、以下を精査します。

• 障害モードが網羅されているか
• 軽減策が有効か
• ロールバックまたは影響封じ込めの戦略があるか
• 縮退モードの動作が明確か
• 不正な出力や上流障害への対処があるか

references/review-checklist.md を読み込み、セクション 4 を完了します。

成功基準：重大なリスクに対し、曖昧な警告ではなく、実行可能な軽減策が示されていること。

ステップ 5：テストカバレッジと実行可能性を監査する

FULL レビューのみ、次の点を検証します。

• テストカバレッジマップの完全性
• テストの種類の適切さ
• 受け入れ基準におけるエッジケースのカバレッジ
• セキュリティ上重要な経路のカバレッジ
• DAG の効率性
• エージェントのマッチング
• 工数の見積もり
• P0 基盤の妥当性
• 書き込み範囲の競合や、隠れた重複

references/review-checklist.md を読み込み、セクション 5 と 6 を完了してください。

成功基準：計画がテスト可能かつ実行可能で、明らかに制約が過剰でも、仕様が不十分でもないこと。

ステップ 6：セクションを採点し、判定を出す

references/review-rubric.md を使用して、次の作業を行います。

• レビューした各セクションを PASS、WARN、FAIL のいずれかで採点する
• 指摘事項を BLOCK、CONCERN、OBSERVATION に分類する
• APPROVE、REVISE、REJECT を判定する

続いて、次の項目を含む簡潔な創業者向けレビュー報告書を作成してください。

• 計画のタイトルとモード
• 判定
• セクションの概要表
• ブロッキングする問題
• 懸念事項
• 所見
• 修正が必要な場合の推奨される計画変更

レビューの最後に、手順に関する質問をユーザーにしないでください。監査結果を提示し、その後の対応はメインスレッドに委ねてください。

成功基準：根拠に基づく指摘事項とルーブリックから、判定が明確に導き出されていること。

ガードレール

• このスキルの一部として、計画ファイルを変更しないでください。
• 内容のある計画を、吟味せずに承認しないでください。
• 指摘事項を捏造しないでください。問題のないセクションは、そのまま合格として構いません。
• disable-model-invocation を追加しないでください。このスキルは、ユーザーが計画のレビューを依頼したときに呼び出せる状態を維持してください。
• paths: を追加しないでください。これは汎用的なレビューワークフローです。
• 巨大な例、品質スコアカード、ゲート表を SKILL.md 内に残さないでください。
• 判定の代わりに AskUserQuestion を使用しないでください。
• このスキルは、別の推論予算を割り当てたフォーク型レビューワークフローとして実行するのが最適であることを忘れないでください。

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

• references/personality.md
  レビューのペルソナ、特性、コミュニケーションスタイルを確認するため、セッション開始時に使用します。

• references/review-checklist.md
  セクションごとの監査項目と根拠要件に使用します。

• references/review-rubric.md
  モードの選択、判定ルール、セクションの採点、指摘事項の分類（BLOCK／CONCERN／OBSERVATION のゲート表）に使用します。

出力要件

次の項目を報告してください。

1. レビューした計画と選択したモード
2. 判定
3. セクションのステータス概要
4. ブロッキングする問題
5. 懸念事項
6. 所見
7. 該当する場合、必須の計画変更