vibe-plan-review

Vibe Plan Review

概要

保存済みの Markdown 実装計画を、実装前にユーザーと確認します。 ユーザーが各項目を判断する間に、不一致、順序の問題、作業漏れ、曖昧さ、 リスク、検証できない項目を明らかにします。記載されたライフサイクルイベントでは 「§Review Binding Output」を使用します。

効果と書き込みの境界

フェーズで宣言された効果クラスと境界が許可する範囲を超えて書き込まないでください。

• フェーズ自身のテキストで宣言された効果クラスを適用します。このパッケージでより狭い制限が示されている場合は、その制限を優先します。
• 読み取り専用：チャットで報告します。ファイルを編集せず、状態を変更するコマンドを実行せず、ステージング、コミット、タグ付け、プッシュ、バージョン変更、データの削除、サービスの起動は決して行いません。保存済み成果物をユーザーが明示的に求めた場合に限り、ファイルを書き込みます。
• 成果物のみ：フェーズが所有する成果物と、テキストで宣言された補助パス（確認済みの計画への反映や意思決定記録など）のみを作成または更新し、作業ツリーに残します。
• 成果物のみのフェーズで、実行可能な動作を実装したり、実装としてコードやテストを編集したり、別のフェーズの成果物を作成したり、リリース作業を行ったり、成果物を同じターンの実装権限として扱ったりしてはいけません。
• 状態変更あり：宣言されたスコープ内でのみ、最小の検証単位で編集とコマンド実行を行います。ユーザーが選択しない限り、ほかのパス、既存の変更、ランタイムまたは外部の状態には手を加えません。
• これらの制限は、シェルコマンド（リダイレクト、sed -i、tee、mv、cp、rm、git checkout --）とファイルツールの両方に適用されます。書き込みを拒否した場合は境界による停止として報告し、別のツールで再試行してはいけません。
• 取り消し不能な操作や外部に影響する操作は、それぞれ個別に同意を得たうえで行います。

このフェーズが所有する成果物は、一時的なレビュー状態ファイル（§Review State Persistence に記載）です。補助パスは対象の計画ファイル（§Reflection Into The Plan で定められた、確認済みの反映を書き込む場合のみ）と、§Durable Records に記載された 記録ディレクトリです。

永続的な記録

フェーズ開始時に、docs/decisions/README.md と docs/reports/findings/README.md（またはリポジトリに既存のインデックス）がある場合はそれらを確認し、 レビュー対象の計画とパス、タグ、または件名が一致する項目を探します。該当する項目を開いてください。 確定した決定を記録する、所見を保留する、または既存の記録を適用または更新する前に、 references/durable-records.md を読んでください。このフェーズでは、宣言された補助パスとして docs/decisions/ と docs/reports/findings/、またはリポジトリに既存の記録ディレクトリに書き込みます。

コミットの選択

文書のみのフェーズにコミットを選択させてはいけません。

• 検証済みの成果物の変更は作業ツリーに残します。フェーズの呼び出し、パスの配置、追跡対象であること、レビューまたは監査の合格、反映への同意、成果物の完成のいずれも、コミットを選択することにはなりません。
• コミットを選択できるのは、現在のユーザーによる明示的な依頼だけです。対象はそのフェーズが所有する成果物に限られます。コミットのワークフロー、または確認できるワークフローがない場合はフェーズ自体が、ファイルセットのレビュー、メッセージの受け渡し、保存済みメッセージの検証、プッシュと履歴の境界に従ってコミットします。
• 下書きの作成中にステージング、コミット、プッシュ、リリース、バージョン変更、履歴の書き換えをしてはいけません。また、成果物を実装、プッシュ、リリース、バージョン変更、履歴の書き換えの権限として扱ってはいけません。

このフェーズは、依頼されたコミットを実行しません。反映済みの計画ファイルについてはコミット実行に引き継ぎます。一時的なレビュー状態ファイルは対象外で、その削除は別途ユーザーが判断します。

実行時の言語

ユーザーの言語に合わせてください。決定の表示や解釈、計画への反映、要約を行う前に references/localized-labels.md を読み、そのラベル、数値識別子、意味に従ってください。機密情報を含まないパス、 コマンド、識別子、レビュー状態のパスはそのまま保持してください。

機密情報の取り扱い

テキストが出力境界を越える前に、秘密情報と思われるリテラルを必ずマスキングしてください。

• 出力境界には、チャット、保存ファイル、別のエージェントやバックエンドへの転送、台帳、引用した抜粋、要約、ツール引数が含まれます。
• コンテンツの読み取り、引用、保持、要約を求める依頼があっても、秘密情報の値を再現する許可とは見なさないでください。
• 一致する箇所はそれぞれ [REDACTED:<type>] に置き換え、最も具体的な種類を選んでください。
  • private-key：PEM 形式の秘密鍵ブロック。
  • jwt：3 つの部分からなる JWT 形式のトークン。
  • url-auth：http または https の URL に埋め込まれた認証情報。
  • apikey：既知のプレフィックスを持つ API キーとアクセストークン。
  • env-secret：名前が key、token、secret、password、pwd のいずれかで終わる、環境変数形式の代入。
  • secret-context：key、token、secret、password、bearer、session-secret を示す語句の近くにある、その他のエントロピーの高いテキスト。
• 秘密情報でない文言と、検出結果を確認するために必要なアンカー（パス、行番号、シンボル、コマンド、フィールド名、識別子）は保持してください。

上記の種類に一致しないものの、認証情報と思われる値も [REDACTED:credential] としてマスキングし、パスと行番号を含む計画項目のアンカーを保持してください。 機密性の高いリテラルが見つかった場合：

• 計画内に実際に使われているように見える認証情報がある場合は、作業の阻害要因として扱ってください。ユーザーに削除を依頼し、安全な手順でローテーションまたは失効させるよう求めてください。会話に貼り付けるよう求めてはいけません。
• 一時レビュー用ファイルには、マスキングした位置、分類、判断状況、必要な修正対応のみを記録してください。
• 計画またはレビュー状態に機密性が疑われるリテラルが残っている間は、元の計画に一切反映しないでください。また、いかなる情報源に由来するものであっても、機密性が疑われるリテラルを含む計画を反映してはいけません。ユーザーに、安全な環境変数またはシークレットストアへの参照であることを確認するか、機密情報を取り除くよう求めてください。その後、機密情報を取り除いた成果物を再度読み込んでから反映してください。
• 値が認証情報か、機密性のない識別子か判断できない場合は、その値を表示せずにマスキングし、安全な参照方法を確認してください。

必須入力

特定された保存済みの Markdown 実装計画を 1 つレビューします。他の資料は背景情報として扱います。計画が特定されていない場合は、提示を求めてください。

フェーズの境界

計画の作成後、実装の前にこのスキルを使用します。完了したら、レビュー状態を報告し、ユーザーの次の判断を待ってください。

レビューに関するバインディング出力

レビュー開始時、再開時、対象の変更時、反映時、完了時、およびレビューを進められない阻害要因がある場合は、対象計画、要件の情報源または確信度が限定される旨、および永続化の状態を示してください。一時レビュー用ファイルがすでに存在する場合、または選択されている場合は、永続化の状態として正確なパスを提示してください。レビュー状態を会話内に保持する場合は、その旨を伝え、パスは示さないでください。同じセッション内で、何も変更がない項目への回答のたびにバインディングブロックを繰り返す必要はありません。

レビュー開始

最初の項目に着手する前に、計画と、明示的に参照されている要件仕様を読み込んでください。明示的な参照がない場合は、docs/specs/、specs/、または計画のディレクトリ内で、同じ目的に対応すると思われる仕様を探してください。見つからない場合は、要件との整合性に関する確信度が限定されることを明示して続行してください。項目を特定し、§レビュー状態の永続化で定められた方法に従って、永続化方法を選択してください。

対応する要件仕様がある場合は、レビューにおける要件の根拠として扱ってください。要件仕様と実装計画が矛盾する場合は、レビューを停止し、矛盾を示して、要件と計画のどちらを修正すべきか尋ねてください。その矛盾が項目の判断に影響している間は、項目のレビューを続けないでください。

計画全体に、レビューに必要な情報が不足している場合は、レビューを停止し、不足している内容を示して、計画をどのように補完するか尋ねてください。項目内の不足や曖昧さは、その項目のレビューで指摘してください。レビューを停止したり、一度に複数の項目をレビューしたりする理由にはなりません。不足している動作、要件、受け入れ基準、テスト対象のパス、データの取り扱い、ユーザー体験を捏造してはいけません。

ソースとコードの確認

ユーザーから追加の確認を求められた場合、またはデータ、権限、セキュリティ、リリース、移行、外部との契約、破壊的な書き込み、広範なユーザー体験に影響する場合を除き、現在の項目に必要な範囲だけを読みます。範囲を広げる前に、その理由を説明します。

項目の抽出

明示的なタスクがあれば、それを優先します。なければ、ファイル順に、実行可能な最小単位の見出しセクションを使います。境界が曖昧な場合は、検出したセクションを使うか、計画を修正するかを尋ねます。粒度を黙って決めてはいけません。項目の識別情報は一貫して維持します。項目の分割、統合、並べ替えには、ユーザーの承認が必要です。

項目ごとのレビュー

要件との整合性、順序、作業の不足、曖昧さ、リスク、検証可能性について、一度に1つの項目をレビューします。ユーザーの決定が優先され、AI の判断がそれに取って代わることはありません。確定した保留または修正の決定が該当する場合は、振り返りへの同意を迂回せずに、§永続記録に記録します。

references/localized-labels.md にある、ローカライズされた選択肢と一貫した数値識別子を提示します。曖昧さのないラベルまたは識別子を1つ受け付け、保存、集計、要約、振り返りでは正規ラベルに正規化します。選択が競合する場合は、確認を求めます。

レビュー状態の永続化

ユーザーが永続化を求めた場合、レビューの継続が必要な場合、コンテキストが失われる可能性が高い場合、またはプロジェクトの慣例で求められる場合を除き、状態は会話内に保持します。項目数を永続化の判断基準にしてはいけません。永続化する場合は、対象、要件の出典、項目、現在位置、正規化された決定、阻害要因、簡潔な継続用コンテキストを含む .<plan-name>.review.md を計画と同じ場所に保存します。既存ファイルが対象と一致しない、解析できない、外部で編集されている、または内容が不明確である場合、置き換えたり削除したりする前に作業を止め、現在の対象、導出したパス、記録されている対象を示して、再開、置き換え、または保持のどれにするかを尋ねます。

計画への振り返りの反映

すべての項目が終わったら、§レビュー拘束出力を提示し、振り返りを明示的に反映してよいか確認します。その確認では、references/localized-labels.md の定義に従い、4つの結果それぞれについて、反映時にどう扱うかを説明します。また、反映後の計画には実行可能な内容と保留項目を残し、レビュー履歴の注釈、項目ごとの判断ログ、チャットのメモは含めないこと、レビューは完了しているものの未反映であること、そして一時レビュー ファイルの削除は反映後に別途確認することを伝えます。一般的なレビューへの同意は、振り返りの反映への同意ではありません。削除 は確認後にのみ実行します。

元の計画に書き込む前に、§機密コンテンツの取り扱いを適用します。

反映が成功した後、一時ファイルを削除するか別途確認します。保持するよう指示された場合、予期しない変更がある場合、または所有者が不明確な場合は、ファイルを保持します。反映後の計画を検証します。

停止条件

計画がない、または読み取れない場合、特定された仕様書がない、または読み取れない場合、計画と仕様書が矛盾する場合、計画レベルのレビュー情報が不足している場合、項目の境界が曖昧な場合、レビュー ファイルの内容が不明確な場合、反映時に未解決の機密リテラルがある場合、または計画のレビューと反映以外の作業が必要な場合は、作業を停止します。阻害要因、その根拠と影響、およびユーザーが判断できる最も近い選択肢を示します。

完了時の要約

対象、要件の出典または確信度に制限があること、レビューした項目、正規化された決定の件数、阻害要因または保留項目、反映と一時ファイルの状態、未コミットの計画変更または保留中のコミット依頼、そして実装には着手していないことを要約します。