goodreview

goodreview

汎用サブエージェントとreferences/specialists.mdの概要を使用して、未コミットの変更を複数の専門家の観点からレビューします。このスキルでは、名前付きのカスタムエージェントは使用しません。

引数

/goodreview [optional file/area to focus on]

省略可能な引数には、ファイルパス、ディレクトリ、機能領域、または短いレビュー対象の指定を使用できます。省略した場合は、未コミットの変更（ステージ済み、未ステージ、未追跡）をすべてレビューします。

フェーズ 1：範囲

次のコマンドを個別のシェル呼び出しとして実行します。

git diff HEAD --stat
git diff --staged --stat
git status --porcelain
git branch --show-current

次の場合は停止してユーザーに伝えてください。

• Git リポジトリではない、または Git コマンドが失敗する
• 作業ツリーがクリーンで、対象の指定がない
• 対象パスが指定されているが、そのパスが存在しない

それ以外の場合は、次を特定してください。

• 変更されたファイルと、それぞれがステージ済み、未ステージ、未追跡のどれに該当するか
• 言語とフレームワーク
• レイヤー：バックエンド、フロントエンド、データベース、テスト、ドキュメント、インフラ、設定
• リスク：認証、マイグレーション、公開 API、ユーザーに表示される UI、並行処理、パフォーマンス、ドキュメントのみ

対象の指定がある場合は、周辺のコンテキストが必要な場合を除き、そのパスを調査します。未追跡ファイルも対象に含めます。

独立したセカンドオピニオンのパス

Fresh Eyes（フェーズ 2）とメタ分析（フェーズ 4）では、必要な連携機能が利用できる場合、ホストとは異なるモデルを使用します。ホストは、明示的なシステムまたはランタイムの識別情報から判断してください。インストール済みのツールやコマンドだけを根拠に推測してはいけません。レビューごとにセカンドオピニオンのプロバイダーを一度選び、各パスでは新しいステートレスセッションを使用してください。

Codex ホスト：ヘッドレスの Grok

各パスを、新しい Grok CLI プロセスのシングルターン・ヘッドレスモードで実行します。

grok --cwd [repository root] --permission-mode dontAsk --sandbox strict --tools read_file,list_dir,grep --deny 'MCPTool(*)' --disable-web-search --no-subagents --output-format plain -p "[pass prompt]"

引数を安全に扱える実行方法を使って、プロンプトを 1 つの引数として渡してください。プロンプト、差分、パス、ユーザーコンテンツがシェル構文として解釈されることは絶対に避けてください。各プロンプトには、必要な情報をすべて含めます。

• Fresh Eyes：共通の指摘事項の形式、Fresh Eyes の概要、範囲パケット、関連する git diff
• メタ分析：メタ分析のプロンプトと、収集した専門家の指摘事項

ツールの許可リストにより、Grok が実際に変更されたファイルを調査できるようにしつつ、編集ツールとシェルツールへのアクセスは制限します。Grok は git diff を実行できないため、関連する差分をプロンプトに含めてください。MCP と Web へのアクセスは無効にし、Grok を厳格なサンドボックスと、ホストが提供する読み取り専用サンドボックスの両方で実行してください。パスの実行に失敗した場合でも、これらの制御を弱めてはいけません。

goodreview の一環として Grok をインストール、更新、または認証してはいけません。grok -p が失敗する、使用可能なレビュー結果が返らない、または利用できない場合は、汎用サブエージェントか、別のホストパスにフォールバックしてください。Codex セッションを代わりに使い、それを外部の Grok の意見として説明してはいけません。

Grok ホスト：MCP 経由の Codex

最初に利用可能な Codex セッションツールを使用します。

• mcp__codex__codex
• codex__codex
• codex_codex

自己完結したパスのプロンプトを指定して呼び出します。ツールが対応している場合は、sandbox を read-only に、approval-policy を never に設定してください。

Codex セッションツールが利用できない場合は、汎用サブエージェントか、別のホストパスにフォールバックしてください。Grok を代わりに使い、それを外部の Codex の意見として説明してはいけません。

その他のホスト、または不明なホスト

利用可能な Codex セッションツールを優先し、次に grok -p を使用してください。ホストだと判明しているプロバイダーを選んではいけません。どちらの外部プロバイダーも利用できない場合は、汎用サブエージェントか、別のホストパスにフォールバックしてください。

レポートには、実際に使用したプロバイダーを記載してください。フォールバックは正確に明記してください。ホストパスは役割の上では独立していますが、異なるモデルによるセカンドオピニオンではありません。

フェーズ 2：役割を選択して起動する

コードを変更する場合は、常に 3 つ以上の役割を含めてください。常に Fresh Eyes を追加してください。

変更の種類	役割
任意のコード	コード品質、セキュリティ、テスト
Elixir/Phoenix	Elixir、セキュリティ、テスト
フロントエンド	フロントエンド、UI/a11y、テスト
スキーマ/SQL	データベース、セキュリティ、テスト
ドキュメントのみ	テクニカルライティング、正確性
テストのみ	QA 実行、テスト、コード品質
複数レイヤーにまたがる変更	コード品質、セキュリティ、テスト、アーキテクチャ

差分がレイヤー、公開 API、インフラ、またはデータフローにまたがる場合は、アーキテクチャを追加してください。 テスト、lint、または CI を実際に実行する必要がある場合は、QA 実行を追加してください。

references/specialists.md を読んでください。選択した各役割（Fresh Eyes を除く）について、汎用サブエージェントを 1 つ並列で起動してください。Fresh Eyes は Independent pass で実行してください。各汎用サブエージェントへのプロンプトには、次の順序で含めてください。

1. Shared finding contract
2. その役割の概要
3. スコープパケット：

Role: [name]
Branch: [branch]
Focus: [optional focus or none]
Changed files:
- [path]
Read the actual files, not only the git diff.
Return findings using the shared finding contract.

名前付きのカスタムエージェントを調べないでください。エージェントのディレクトリを使用しないでください。

ランタイムがサブエージェントを起動できない場合は、このセッションで概要を順番に実行し、各出力に役割名を付けてください。

各スペシャリストは次のことを行う必要があります。

• 差分だけでなく、変更されたファイルを読む
• 自分の担当領域に集中する
• file:line（またはリポジトリ全体に関する問題の場合は関連ファイル）を示す
• 重要度を評価する：Critical、High、Medium、Low
• 具体的な修正案を提示するか、No findings と記載する

フェーズ 3：統合

スペシャリストの報告を集めた後、次の内容を統合してください。

• 重複する指摘をまとめる
• 矛盾や未解決の意見の相違を明示する
• 複数の領域にまたがる問題を特定する
• 元の役割名を維持する

サブエージェントの起動が可能な場合は汎用サブエージェントを使用し、それ以外の場合はホスト上でこの作業を行ってください。

フェーズ 4：メタ分析

統合した指摘に対して、2 回目の独立した分析を実行してください。プロンプト：

Review this multi-specialist analysis. What patterns do you see differently? What risks were not considered? How would you re-prioritize these findings? Challenge the assumptions. Identify findings that are over-prioritized, under-prioritized, unsupported, or missing.

この分析は Independent pass で実行してください。プロンプトには、収集したスペシャリストの指摘を含めてください。

フェーズ 5：報告

チャット内にのみ報告を出力してください。ファイルには書き込まないでください。Issue の作成、コミット、ファイルの編集は行わないでください。

スペシャリストの重要度を、報告の分類に対応付けてください。

• Critical → Critical（必ず修正）。Critical の指摘が 1 つでもある場合、コミット準備状況は Not ready
• High または Medium → 警告（修正を推奨）
• Low → 提案（検討）

=== GOODREVIEW: [Target] ===
Branch: [branch] | Files: [N] changed | Roles: [list]

SPECIALIST FINDINGS
[Role]: [key findings with file:line]

FRESH EYES — [Grok CLI | Codex via MCP | generic subagent | host fallback]
[Independent findings]

SECOND-OPINION META-ANALYSIS — [provider]
[Independent analysis and re-prioritization]

CROSS-SPECIALIST INSIGHTS
[Systemic issues, conflicts, overlapping patterns]

PRIORITIZED ISSUES

Critical (must fix):
- [Issue] - [file:line] - Found by: [Role]
  Fix: [specific example]

Warnings (should fix):
- [Issue] - [file:line] - Found by: [Role]
  Fix: [specific example]

Suggestions (consider):
- [Issue] - [file:line] - Found by: [Role]
  Fix: [specific example]

COMMIT READINESS: Ready | Not ready - N critical issues remain

指摘がない場合は、その旨を伝え、残るリスクやテストの不足を列挙してください。

ドライラン時の選択

スキルの実行中（作成中ではありません）に、次のチェックを使用してください。

• Elixir のみの差分 → Elixir、セキュリティ、テスト、Fresh Eyes
• ドキュメントのみの差分 → テクニカルライティング、正確性、Fresh Eyes

ルール

• ランタイムが対応している場合は汎用サブエージェントを並列で使用し、それ以外の場合は役割名を付けた概要を順番に実行する
• Codex では grok -p を通じて Grok を使用し、Grok では Codex MCP を使用する。それ以外の場合は、ホストとは異なる外部プロバイダーを使用する
• Fresh Eyes とメタ分析には、新しいステートレスな外部セッションを使用し、実際に使用したプロバイダーを明記する
• すべての指摘に file:line または関連ファイルへの参照と、修正案を含める
• 各 git コマンドは、それぞれ別のシェル呼び出しで実行する
• Issue の作成、コミット、ファイルの編集は行わない
• 名前付きのカスタムエージェントを調べない
• 修正の適用は後続のユーザー依頼で行うものであり、/goodreview の一部ではない

$ARGUMENTS