multi-cli-review-action

Multi-CLI レビューアクション

バージョン履歴

• v2.4: ペアでのレポート受け入れに関する表現を、コーディネーターが割り当てる文字ベースの reviewer-id スロットに合わせ、CLI の識別情報は source-cli に別途記録するようにしました
• v2.3: このスキルをワークフローに依存しないアクション側のペア契約として位置付け直し、レビュー担当者数の既定値をコア契約から分離しました
• v2.2: 新たな問題が生じていないことを明示的な採用条件として追加し、ワークフローに関する表現を回帰を防ぐ修正に合わせました
• v2.1: レポートの受け入れルール、安全性のゲート、共有ペア契約に対するスキル仕様の整合性を強化しました

目的

multi-cli-review-action は、multi-cli-review と対になるアクション側のスキルです。

現在の CLI は、このスキルを使って、対になるスキルが生成したレビュー担当者のレポートを取り込みます。これは意図的にワークフローに依存しない設計です。レビュー担当者のレポートがペア契約に従っている限り、どのワークフロー、コマンドパック、手動のコーディネーターでも使用できます。

このスキルが安全に行うのは、次の 1 つの作業です。

1. レビュー担当者のレポートを収集します
2. 指摘を重複排除し、分類します
3. 各候補をローカルコードとプロジェクトのルールに照らして再確認します
4. 編集前に確認を求めます
5. 確認済みで、対象範囲内の修正のみを適用します
6. 判断と検証結果を記録します

使用する場合

次のいずれかに当てはまる場合は、このスキルを使用してください。

• 他の CLI インスタンスが、すでに 1 つ以上の multi-cli-review レポートを書き出している
• ユーザーが「这些审查报告をまとめて」と依頼している
• ユーザーが「multi-cli-review の出力を処理して」と依頼している
• ユーザーが「reviewer の提案に沿って修正を実行して」と依頼している
• ファイルを変更する前に、現在の CLI で複数のレビュー担当者の意見を調整する必要がある

使用しない場合

• 修正を適用するのではなく、レビュー担当者の指摘を生成するだけの場合：multi-cli-review を使用してください
• 複数のレビュー担当者への引き継ぎを伴わない通常の実装タスクを行う場合
• レポートがまだ未確認の仮説であり、ユーザーが修正計画に同意していない場合

コア規則

1. 修正担当は 1 つ：レビュー担当者の CLI はレポートを作成するだけです。このスキルがレビュー担当者に編集を委任することはありません。
2. レポートは根拠であり、真実ではありません：採用する前に、すべての指摘をローカルのコードベース、タスクの範囲、プロジェクトのルールに照らして再確認する必要があります。
3. 予期しない編集は禁止：概要と判断をまとめた後、具体的なファイル変更を行う前に、現在の CLI はユーザーの確認を得る必要があります。
4. 対象範囲を広げない：現在のタスクに関係する問題だけを修正します。リファクタリング、新機能、広範な整理に便乗してはいけません。
5. 競合を自動解決しない：相互に両立しない提案やリスクの高い提案には、人間の判断が必要です。
6. オーケストレーションはコーディネーターが担当：レビュー担当者数の既定値、ラウンドの計画、レビュー担当者向けコマンドのパッケージ化は、上流のコーディネーター、ワークフロー、またはコマンドパックが担います。このスキルは、そこから得られたレポート一式を取り込むだけです。
7. 修正による回帰を起こさない：元の問題よりも新たな不具合、回帰、または広範なリスクが生じにくい理由を現在の CLI が説明できない修正は、採用してはいけません。
8. 検証は必須：編集後、完了を宣言する前に、関連する検証コマンドを実行します。
9. プロジェクトルート基準のパス解決：相対パスはアクティブなプロジェクトルートを基準に解決します。システムの /tmp やツールのインストールディレクトリを基準にしてはいけません。

プロトコル

プロトコル	ステータス	使用する場合
action-v2	現行	--task-dir を明示した、タスク単位の複数レビュー担当者フロー
action-v1	互換性のみ	レガシーな単一レポートのフロー

プロトコルの選択

1. --task-dir が指定されている場合は、action-v2 を使用します。
2. 単一のレガシーレポートのパスが指定されている場合は、action-v1 を使用します。
3. 新しい作業では、action-v2 を優先してください。

入力

action-v2

パラメーター	必須	意味
--task-dir	はい	タスクディレクトリ。例：tmp/multi-cli-review/<task-id>
--round	いいえ	取り込むレビューラウンド。デフォルトでは、利用可能な最新のラウンドです
--force	いいえ	.processed.json に記載済みのレポートも再度取り込みます
--dry-run	いいえ	判定のみを生成します。ファイルの編集や、レポートの取り込み済みとしての記録は行いません

action-v1 との互換性

パラメーター	必須	意味
<report-path>	はい	従来の cur_defect.md のパス、または同等の単一レポート
<plan-path>	いいえ	省略可能な既存の最適化／アクションの草案

パスのルール

相対パスは、アクティブなプロジェクトルートを基準に解決する必要があります。

相対パスを次の場所を基準に解釈しないでください。

• スキルリポジトリのルート
• ユーザーのホームディレクトリ
• システムの /tmp
• CLI のインストールディレクトリ

プロジェクトルートを明確に特定できない場合は、推測せずに処理を中止し、絶対パスを求めてください。

レポート取り込みの契約

action-v2 では、次のすべてを満たすファイルのみを取り込んでください。

1. ファイルが {task-dir}/review-round-{N}/ の配下にある
2. ベース名が <reviewer-id>.md と完全に一致する
3. フロントマターに次の項目が含まれている
   • task-id
   • round
   • reviewer-id
   • source-cli
   • protocol: task-level
4. フロントマターの値がディレクトリおよびファイル名と一致する
5. 次のいずれでもない
   • summary-*.md
   • action.md
   • アドホックなメモ、作業用ドキュメント、人間による判定メモ

ファイルの内容が曖昧、不正、または契約と一致しない場合は、安易に取り込まず、クリーンアップを求めて処理を中止してください。

レポートセットのルール

• このスキルは、選択したラウンドに存在する有効な multi-cli-review レポートを取り込みます。デフォルトで起動すべきレビュアーの数は定めません。
• 有効なレポートが 0 件の場合はエラーです。
• コーディネーター、ワークフロー、またはコマンドパックがレビュアー数のデフォルトや上限を定めている場合、ここで再定義せず、上流のポリシーとして扱ってください。
• 現在のタスクレベルのラウンドでは、reviewer-id はコーディネーターが割り当てたレビュアースロット ID（a／b／c／d）として解釈し、実際のレビュアー CLI は source-cli で識別してください。

判定状態

各候補指摘は、次のいずれか1つの状態にしてください。

• adopted：コード／仕様／タスクの範囲に照らして確認済みで、実行が承認されている
• ignored：具体的な理由に基づいて却下されている
• manual-decision：競合、曖昧さ、またはリスクがあり、人間による判断が必要
• blocked：実行または検証を進められなかった

ワークフロー

ステップ 1：モードと入力の解決

1. action-v2 と従来の互換モードのどちらかを判定します。
2. すべての相対パスをアクティブなプロジェクトルートを基準に解決します。
3. .processed.json が存在する場合は読み込みます。

ステップ 2：候補レポートの収集

action-v2 の場合：

1. 対象の review-round-{N} ディレクトリのみを読み込みます。
2. レポート取り込みの契約に基づいてファイルを絞り込みます。
3. 不正なファイルや一致しないファイルは除外します。
4. --force が指定されていない場合、取り込み済みのレポートはスキップします。

停止条件：

• 有効なレポートファイルがない
• 有効なレポートがすべて取り込み済みで、--force が指定されていない

ステップ 3：レポートを候補指摘に変換

1. ファイル名だけでなく、場所と意味に基づいて指摘を統合します。
2. 統合した各指摘について、すべての元のレビュアーを保持します。
3. 修正方針の競合は、平坦化して消去せず、そのまま保持します。

ステップ 4：各候補をローカルで再確認

指摘を adopted と判定する前に、現在の CLI で次の点を確認する必要があります。

1. 問題が現在のコードにも存在すること
2. 問題がアクティブなタスクの範囲に含まれること
3. 提案された修正がプロジェクトのルールや既存の抽象化に反しないこと
4. 提案された修正による変更が、それによって防げる損害より小さいこと
5. 計画された変更が、近接する動作に新たなバグ、リグレッション、またはより高コストな副作用を引き起こす可能性が低いこと

いずれかの確認に失敗した場合は、指摘を ignored または manual-decision と判定してください。自動的に採用してはいけません。

ステップ 5：判断する

次の判断方針を使用します。

• adopted：具体的で、スコープ内にあり、ローカルで検証済みで、安全に変更できる
• ignored：古い、重複している、誤っている、価値がない、またはすでに修正済み
• manual-decision：提案が競合している、担当者が不明確、副作用のリスクがある、境界に関する疑問が未解決、または明確で回帰リスクの低い修正方法がない

採用しない項目にはすべて、次のラウンドで同じ報告が再度議論されないよう、具体的な理由を記載する必要があります。

ステップ 6：最初にサマリーを作成する

ファイルを編集する前に、summary-round-{N}.md を作成します。

サマリーには、次の内容を記録する必要があります。

• 読み込んだレビューファイル
• 重複排除前後の指摘件数
• 競合
• 判断の全リスト
• 無視した理由
• まだユーザーの入力が必要な manual-decision 項目

ステップ 7：編集前に確認を求める

サマリーを作成したら、修正計画を提示し、ユーザーの確認を待ちます。

次の場合は、まだファイルを編集しないでください。

• ユーザーが実行を確認していない
• いずれかの manual-decision 項目が安全な作業の妨げになっている
• 残りの計画によってスコープが拡大する
• 現在の CLI では、計画した修正が新たな問題や回帰を引き起こさないと説明できない

ステップ 8：確認済みの修正のみを実行する

通常モードでは：

1. adopted 項目に対してのみファイルを変更する
2. 変更を確認済みの範囲内に収める
3. 変更内容とその理由を action.md に記録する

--dry-run モードでは：

1. ソースファイルを変更しない
2. レポートを消費済みとしてマークしない
3. プレビューであることが明確に示された判断アーティファクトのみを書き込む

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

編集後、修正によって新たな問題が生じていないことを確認できる、最小限のコマンドセットを実行します。

• 該当する場合は、lint またはフォーマットチェック
• 該当する場合は、型チェック
• 該当する場合は、テストまたは対象を絞った回帰コマンド

実際の結果のみを記録します：pass、fail、または not run。

ステップ 10：状態を確定する

1. action.md を更新する
2. .processed.json は、通常実行で実際に消費したレポートについてのみ更新する
3. 保留中または手動対応が必要な項目は、次の人間による判断に備えて見える状態にしておく

出力ファイル

summary-round-{N}.md

最低限、次の内容を含めます。

• タスク ID とラウンド
• レビュー元の一覧
• 重複排除済みの指摘テーブル
• 競合テーブル
• 判断の概要
• 無視した理由
• 保留中の手動判断

action.md

最低限、次の内容を含めます。

• 実行モード：normal または dry-run
• 実際に適用した採用済みの変更
• 無視した項目とその理由
• ブロック中または手動判断が必要な項目
• 検証コマンドと結果

.processed.json

これは内部の消費状態管理専用として使用します。

ルール：

• --dry-run 中は更新しない
• 不正なレポートやスキップしたレポートを消費済みとしてマークしない
• action.md の代用として使用しない

競合への対応

レビュー担当者が次のいずれかについて意見が異なる場合、指摘は競合しているものとして扱います。

• そもそも変更が必要かどうか
• 変更するファイルまたは場所
• 実装の方針
• 推奨される対応が変わるほどのリスクまたは重大度

競合への対応方針：

1. すべての選択肢が見える状態にする
2. 自動的に選択しない
3. 競合の内容を正確にユーザーに提示する

プロンプトの例：

⚠️ 需要人工介入

冲突问题：src/c.py:30
- reviewer-a：重构整个函数
- reviewer-b：仅修正返回值

请选择：
1. 采纳 reviewer-a
2. 采纳 reviewer-b
3. 自定义方案
4. 忽略该问题

必須の停止条件

次のいずれかに該当する場合は停止し、人間の入力を求めます。

• 競合する提案が未解決のまま残っている
• 指摘がタスクのスコープを超えている
• 提案された修正がプロジェクトの規約またはセキュリティ上の要件に反する
• 提案された修正を、根拠を示せる回帰リスクの低い変更に絞り込めない
• 検証に失敗した
• レポート一式に不備がある、または不完全である
• ラウンド数が合意済みの上限に達しており、未解決の項目が残っている

エラー処理

ケース	必須の動作
タスクディレクトリが存在しない	停止し、有効なパスを尋ねます
有効なレポートがない	停止し、ラウンドが空であることを報告します
すべてのレポートがすでに消費されている	--force が設定されていない限り停止します
レポートのメタデータが不正	レポートを拒否し、修正を求めます
実行に失敗	項目を blocked にし、理由を記録して、安全な場合に限り続行します
検証に失敗	失敗を正確に記録し、修正が完了したと主張しません

よくある間違い

• レビュアーの出力を絶対的な正解として扱う：採用前に、必ずローカルで再確認します。
• ラウンドディレクトリ内のすべての .md ファイルを消費する：レポートの要件を満たすファイルだけを受け入れます。
• このスキル内でレビュアーのデフォルトを再定義する：デフォルトの件数は、上流のコーディネーターまたはコマンドのインターフェースが決定します。
• スコープを超えて修正する：リファクタリングや関連する機能開発を紛れ込ませないでください。
• 別の問題を引き起こして問題を解決する：予定している修正に回帰や副作用のリスクがあり、不明確な場合は、無理に採用せず停止して manual-decision に移します。
• 確認を省略する：まず要約し、次に確認を取り、その後で編集します。
• 検証を省略する：検証せずにファイルを変更すると、既存の問題を解決する一方で、新たな問題を引き起こす可能性があります。

例

例 1：現在のプロトコル

用户：/multi-cli-review-action --task-dir tmp/multi-cli-review/skill-review --round 1

CLI：
1. 读取 round-1 下已有的 reviewer 报告
2. 校验 frontmatter 与文件名一致
3. 合并并去重
4. 对每个候选问题重新核对本地代码和任务边界
5. 排除会明显引入新问题或回归的修复方案
6. 输出 summary-round-1.md
7. 等待用户确认
8. 执行已确认修复
9. 运行验证命令
10. 写入 action.md 和 .processed.json

例 2：ドライラン

用户：/multi-cli-review-action --task-dir tmp/multi-cli-review/skill-review --round 2 --dry-run

CLI：
1. 读取 round-2 报告
2. 输出决策和冲突
3. 生成预览版 summary / action
4. 不改源码
5. 不更新 .processed.json

関連スキル

• multi-cli-review：レビュアー側でのレポート生成
• verification-before-completion：変更後の検証手順
• brainstorm：リスクのある修正を受け入れる前の境界の明確化

互換性に関する注意

• 単一レポートを使う従来の方法では、引き続き action-v1 を使用できますが、同じ安全策に従う必要があります。ローカルで再確認し、編集前に確認を求め、その後で検証してください。
• 新しいタスク単位の使用では、明示的な --task-dir を指定した action-v2 を常に優先してください。