mcpField
R
review

review

github.com/camachoテスト・品質393 回インストール
リポジトリ

review について

reviewは、計画かコードかを判定し、内容に応じたレビューパネルを編成して修正ループを実行するワークフロースキルです。重大度に応じて指摘を処理し、上限ラウンド内で判定を出します。

主な機能

  1. 01計画とコードのレビューを判定
  2. 02内容に応じてレビュアーを選定
  3. 03重大度別に指摘を修正・記録
  4. 04レビューを反復して判定を出力
  5. 05ラウンド上限とモード指定に対応

活用シーン

  1. 01計画ファイルをレビューして指摘に対応
  2. 02ブランチ差分をレビューして問題を修正
  3. 03基準未満の指摘を課題として記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/camacho/ai-skills --skill review

インストール後、Claude Code で/reviewを入力して読み込まれたか確認します。

詳細

/review

計画またはコードのどちらをレビューするかを判定し、適切なパネルを編成して、レビューと修正のループを実行します。

1. モードの判定

引数またはコンテキストから判定します。

  1. 明示的な指定：/review plan または /review code — 指定されたモードを使用します。
  2. ai-workspace/plans/ に計画ファイル（.done.md 以外）が存在し、main より先のコミットがない — 計画モード。
  3. git diff main...HEAD が出力を返す — コードモード。
  4. 判定できない場合 — 次のように質問します：「計画とコードのどちらをレビューしますか？」

モード指定の後に追加できるオーバーライド：

  • ラウンド上限：デフォルトは 3。「thorough」（5）または「quick」（1）。
  • 重大度ゲート：デフォルトはモードによって異なります — 計画モード = P2、コードモード = P3（ローカルマージのフローでは、指摘として記録するより今修正するほうが軽微な問題のコストが低いと想定します）。「strict」は P1、「p2」は P2、「lenient」は P3 を強制します。

2. パネルの編成

計画モード（ステップ 4）

リード：technical-editor（常時）。 対象：計画ファイル。

コードモード（ステップ 6）

リード：code-reviewer（常時）。 対象：変更されたファイル（git diff main...HEAD）。

条件付きレビュアー（両モード）

対象をスキャンしてシグナルを確認します。一致するレビュアーを追加します。

シグナル計画モードコードモード
アーキテクチャ、新しいモジュール、DI パターンarchitect-reviewerarchitect-reviewer
AGENTS.md、config.toml、sync.sh、スキルcodex-specialistcodex-specialist
認証、認証情報、トークン、シークレットsecurity-auditorsecurity-auditor
UI、CSS、コンポーネント、アクセシビリティui-designerdesign-reviewer

シグナルが一致しない場合 — リードのみで実行します。

利用可能であれば /assemble-panel を呼び出して、RETAIN、EXPAND、CONVERGE、ESCALATE_RECURRING のガバナンスを適用します。そのポリシーの仕組みを重複して実装しないでください。

Codex/Cursor：.agents/skills/assemble-panel/SKILL.md を読み、インラインで適用します。

3. ディスパッチ

  • 計画モード：Skill ツール経由で /plan-review を呼び出します。パネルとラウンド上限を渡します。内部の P0 ループを R1 として数えます。
  • コードモード：Agent ツール経由でパネルをディスパッチします。重大度タグ付きの指摘（P0〜P3）を依頼します。

タグのない指摘は P1 として扱います。

4. ループ：修正、記録、再レビュー

各ラウンド（R1..R{cap}）で、次を行います。

a. 重大度ゲートに基づいてトリアージします。

  • 修正（P0 から P{gate} まで）：直ちに修正します。Co-Authored-By トレーラーを付けて、fix: address R{N} review findings でコミットします。
  • 記録（P{gate+1} 以上）：記録し、修正はしません。

b. ゲート未満の指摘を記録します。

  • 計画：計画ファイルに ### Deferred Findings (R{N}) を追記します。
  • コード：gh issue create --label review-finding --title "R{N}: <summary>"。上限は 1 ラウンドあたり 10 件、合計 20 件です。gh が利用できない場合は .branch-context.md に追記します。

c–f. パネルのガバナンス — /assemble-panel を呼び出して、RETAIN、EXPAND、CONVERGE、ESCALATE_RECURRING を適用します。

最終 P3 一括修正（コードモード、ゲート = P3）

P3 の軽微な指摘は増殖します。P3 を 15 件修正すると、差分が再びパネルにかけられ、新たに 15 件の P3 が見つかることがあります。これを防ぐため、コードモードの最後の修正ラウンドは最終一括修正とします。

  1. そのラウンドの P3 を修正します。
  2. fix: address R{N} review findings (P3 sweep) でコミットします。
  3. 検証（型チェックとテスト）を実行します。失敗がある場合はゲートを P2 とした新しいラウンドとして扱います。最終一括修正は無効になり、通常どおりループを続けます。
  4. さらに 1 ラウンド実行するために、パネルを再ディスパッチしないでください。
  5. サマリーを出力し、判定を APPROVE として終了します。

ゲートが P3 で、未修正の P0/P1/P2 指摘が残っておらず、そのラウンドで見つかった指摘が P3 のみの場合、最終一括修正のラウンドとします。P0〜P2 の指摘は常に通常のループに戻します（最終一括修正は軽微な指摘のみのラウンドに限られます）。

5. サマリー

Review Summary
───────────────────────────────────────
Mode:      plan | code
Target:    <file or diff summary>
Rounds:    <N of cap>
Gate:      P<N>

│ Round │ P0 │ P1 │ P2 │ P3+ │ Fixed │ Recorded │
│───────│────│────│────│─────│───────│──────────│

Verdict: APPROVE | ESCALATE
  • APPROVE — ゲート以上の指摘はすべて解決済みです。次のステップ：
    • 計画モード → Build（ステップ 5）
    • コードモード → Archive（ステップ 7）
  • ESCALATE — 上限に達してもゲート以上の指摘が未解決です。人間に提示します。

ガードレール

  • 保護対象ファイルは変更しないでください（AGENTS.md を参照）。
  • 要求された上限がこれを超えていても、最大 5 ラウンドとします。
  • 自動マージまたは自動承認は行いません。アクションではなく判定を出力します。
  • プレーンテキストのみを出力します — サーフェスをまたいで安全に使用できます。

フォールバック

  • /plan-review が利用できない → technical-editor と architect-reviewer を直接ディスパッチします。
  • /assemble-panel が利用できない → [technical-editor, code-reviewer] にフォールバックします。gate=P2、cap=3。
  • gh が認証されていない → .branch-context.md に切り替えます。
  • レビュアーが DROP を返す → 直ちに終了し、要約を出力します。

コメント

Markdown 対応