bmad-review

BMad Review

レンズ（それぞれ異なる手法と立場）を通してコンテンツをレビューし、所見を標準形式で報告します。実際に存在することだけを報告し、徹底的に見せるために水増ししてはいけません。各レンズは、コンテンツと所見がゼロの場合に対して独自の立場を取ります。ほとんどのレンズでは結果が空でも問題ありませんが、敵対的レンズでは具体的な所見が少なくとも10件必要で、リストが空なら再確認すべきサインとみなします。編集レンズではコンテンツそのものには手を加えず、構成と表現のみを批評します。

レンズのセットは固定リストではなく、{workflow.lenses} が解決した内容に従います。オーバーライドでレンズを追加したり、同梱のレンズを置き換えたりできます。このファイルに記載された能力を決めつけてはいけません。解決されたレンズを読み、その内容に従って作業してください。

入力

• content — レビュー対象：差分、ブランチ、未コミットの変更、ファイル、チケット（イニシアチブ、エピック、ストーリー、スパイク、バグ）、または任意のドキュメント。引数：[path]。
• lenses（任意） — 1つ以上のレンズコードまたは名前。呼び出し元による表現方法は問いません。口頭での依頼、またはskill:bmad-review lenses=<code>[,<code>...]の形式の指示（bmmのdoc_standardsで使われる形式）などがあります。既定値：該当するすべてのレンズ（包括的なレビュー）。
• also_consider（任意） — 各レンズの通常の分析に加えて考慮する領域。
• claims（任意） — 変更についての独自の説明。対象となるコミットメッセージ、または呼び出し元から渡された説明などです。エッジケースレンズだけに渡されます。
• pre-resolved customization（任意） — 転送元の呼び出し元から渡される[workflow]フィールドの値。「実行手順」ステップ1を参照してください。

規約

• references/lens-edge-case-hunter.mdなどの相対パスは{skill-root}（このスキルのインストール先ディレクトリで、customize.tomlが配置されています）を起点に解決されます。{project-root}は、プロジェクトの作業ディレクトリから親ディレクトリを順にたどり、_bmad/を含む最も近いフォルダーです。
• {workflow.<name>}は、customize.tomlの[workflow]テーブル内のフィールドに解決されます（BMadのマージ規則に従い、オーバーライドが優先されます）。
• style_guide、review_guidance、persistent_factsでは、file:で始まる値はパスまたはグロブです。そのファイルの内容を読み込んでください。file:の値を読み込めない場合は、出力ヘッダーで読み込めなかったファイル名を示して続行してください。style_guideでは同梱のベースラインを使い、それ以外では残りのエントリーを使います。

実行

1. カスタマイズを解決する： uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow。
   • スクリプトが見つからない場合：ここではBMadがセットアップされていません。bmadスキルのセットアップを実行するよう提案してください。bmadがインストールされていない場合は、まずインストールします（npx skills add bmad-code-org/BMAD-METHOD --skill bmad）。その後、コマンドを再実行してください。
   • それ以外のエラーの場合：{skill-root}/customize.tomlを直接読み込み、既定値を使用してください。 転送された起動： 呼び出し元が解決済みのカスタマイズ項目（例：bmad-editorial-review shim）を指定して起動した場合、それらの指定項目にはユーザーの上書きがすでに反映されているため、そのまま適用し、残りの項目のみ自身の customize.toml から解決してください。次に、各 {workflow.activation_steps_prepend} の項目を順に実行し、{workflow.persistent_facts} をセッション全体の常時コンテキストとして保持し、{workflow.review_guidance} の項目をすべての観点に対する常時レビュー指示として扱ってください。
2. コンテンツを読み込みます。 コンテンツは一度だけファイルとしてステージングしてください。コンテンツがブランチ、未コミットの作業、またはコミット範囲の場合は、リポジトリのバージョン管理ツールを使って統合差分をシステムの一時ディレクトリ内に一意の名前で作成したファイルへ書き込み、そのファイルの絶対パスをコンテンツとして扱ってください。ブランチとは、ベースブランチとのマージベースに対する差分を指します。未コミットの作業には未追跡ファイルも含まれます。claims も同様に専用ファイルへステージングしてください。これは1つの観点で使う入力であり、他の観点には決して見せないよう、別途ステージングします。コンテンツが空、またはテキストとしてデコードできない場合、呼び出し元が生の調査結果 JSON 配列（例：従来のエッジケース転送）を期待しているときは、lens フィールドを付けずに [{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}] を返して終了してください。それ以外の場合は、問題を伝えてレビュー可能なコンテンツを求めてください。コンテンツを分類してください。差分、ソースファイル、関数、ドキュメントのいずれかを判定し、さらに コード か ドキュメント かを判定します。スコープのルールと観点の適用可否はどちらの判定にも左右されます。動作を定義するドキュメント（チケット、計画、要件など）は、動作に関する観点を適用できる ドキュメント です。when に基づいて判断してください。
3. {workflow.lenses} から観点を選択します。instruction が空の観点は無効です。ユーザーまたは呼び出し元が観点を指定した場合は、applies_to と when で絞り込まず、指定された観点だけを正確に実行してください。それ以外の場合は、コンテンツの分類を対象とする（any は常に対象となる）applies_to を持ち、かつ when の条件に合致する、有効な観点をすべて実行してください。
4. 実行前に、 コンテンツの分類、これから実行する観点、さらに after が設定された観点がある場合は、指定された観点の調査結果を踏まえて実行することを1行で告知してください。呼び出し元が出力形式を厳密に指定している場合（生の JSON または指定された1行だけを要求する従来の転送機能）は、告知を完全に省略してください。その指定は調査結果ブロックだけではなく、出力全体に適用されます。次に、各 {workflow.activation_steps_append} の項目を順に実行してください。
5. 独立した観点を実行します — 選択されたうち、after が設定されていない観点をすべて実行してください。各観点にはコンテンツと also_consider のみを渡し、他の観点の調査結果は渡しません。各観点の instruction に従ってください。提供されている観点では、参照ファイルを必要な時点で読み込むため、実行する観点の参照ファイルだけを読み込んでください。サブエージェントを利用できる場合は、いずれかの観点の結果を扱う前に、すべての独立した観点を起動してください。同時実行を試み、観点ごとに1つずつ起動してください。観点の instruction を {skill-root} とパスを絶対パスに解決した状態で渡し、ステージング済みコンテンツファイルの絶対パス（観点のプロンプトにはパスを含め、観点はファイルを読み込みます。コンテンツのバイト列は渡しません。ファイルとしてステージングされていない場合に限り、コンテンツを直接含めます）、also_consider の対象領域、常時レビュー指示、エッジケース観点だけに渡す claims のパス（指示で読み込みを求められるまで読まないよう明記）を渡してください。さらに、次の制約も伝えてください。「調査結果のみを返してください。他の出力は不要です。スキルを呼び出したり、独自にサブエージェントを起動したりしないでください。あなたがレビュアーです。調査結果は最終メッセージのテキストとして返してください。ホストが利用できる調査結果報告ツールを介して返さないでください。」それ以外の場合は、観点を1つずつ順に実行し、各観点を完了してから次を開始してください。
6. 依存する観点を実行します — 選択されたうち after が設定された観点を、指定された観点の完了後に実行し、その観点の調査結果を渡してください。after の対象が選択されていない、または調査結果を出さなかった場合も、事前の調査結果なしで実行します。異なる対象を after に指定する依存観点は互いに独立しています。結果を扱う前に、実行可能になったすべての観点を起動してください。同時実行を試みてください。サブエージェントを利用できる場合は、独立した観点と同じ制約を付けて起動してください。「調査結果のみを返してください。他の出力は不要です。スキルを呼び出したり、独自にサブエージェントを起動したりしないでください。あなたがレビュアーです。調査結果は最終メッセージのテキストとして返してください。ホストが利用できる調査結果報告ツールを介して返さないでください。」
7. 結果をまとめて提示します。 以下の「出力」に従ってください。各観点の調査結果をすべて残してください。観点間の重複は重複排除の対象ではなく、重要な情報です。Markdown レポートでは、重複を削除せず、その旨を記載してください。設定されている場合は {workflow.on_complete} を実行してください。

出力

すべてのレンズからのすべての検出事項を保持する 1 つの JSON 配列。各検出事項は次を保持します。

• lens — それを生成したレンズのコード
• location — コンテンツ内の位置（コードの場合は file:line-range、ドキュメントの場合は section）
• trigger_condition — 問題、またはそれを露呈させる条件を 1 行で
• guard_snippet — 具体的な修正、ガード、または欠落しているチェック
• potential_consequence — そのまま出荷された場合に何がうまくいかなくなるか

各レンズファイルは、その検出事項のためにこれらのセマンティクスを洗練させ、レンズ固有のフィールド（例: 削除の検出事項における kind/confidence、検証ギャップの検出事項における gap_shape/consumer/evidence）を追加することがあります。レンズファイルは代わりに、独自の検出事項の形状とレンダリングを宣言することがあります — 編集レンズは検出事項テーブルをレンダリングします — そしてその形状はそのレンズの検出事項に対して優先されます。何も見つからない場合、[] が有効です。重大度、優先度、ランキングはどこにもありません。

{workflow.output_format} に従って提示します — "json"（フェンス付き json ブロック内の生の配列）、"markdown"、または "both" — ただし呼び出し元が特定の形状を要求した場合は除きます。レガシーフォワーダーの出力契約は常に優先され、検出事項ブロックだけでなく、あなたが出力するすべてを統制します。markdown レポートは検出事項をレンズごとにグループ化し、それぞれが宣言された形状でレンダリングされます。検出事項ごとにフィールドと注目に値する追加項目をレンダリングする短いブロック、何も見つからなかったレンズには 1 行、レビュー全体がクリーンな場合は明快な一文。レポートは {workflow.output_preferences} に従って整形します。

{workflow.report_path} が設定されている場合は、レポートをそこに書き込みます。それ以外の場合はチャットで提示します。