code-ultrareview

Code ultrareview

重大 — 敵対的検証

重大な影響を及ぼす指摘や判断は、それに基づいて行動する前に検証してください。

• 重要な根拠となる主張や意見が分かれる主張について、反例と独立した証拠を探してください。利用可能で有効な場合は、新しいレビュー担当者を起用してください。順次行う自己レビューは、独立性が低いものとして明記してください。
• 重大な指摘は、修正、証拠に基づく反証、または明示した残存リスクによって解決してください。黙って取り下げてはいけません。
• 判断を決めるのは証拠であり、レビュー担当者の人数や確信度だけではありません。再現可能な不具合が1つあれば、結論が覆ることもあります。
• 影響の大きさに応じて検証の度合いを調整してください。確定した事実はそのまま確定事項として扱い、影響が小さく取り消し可能な確認は簡潔に行ってください。

重要 — エンジニアリングの規律

コードの作成、編集、提案時には、以下のルールを適用してください。

• 受け入れられた問題を解決するために、必要十分な最小限の変更を行ってください。既存の仕組みを再利用し、無関係な作業は維持してください。外部入力と実際のエラー状態を検証してください。
• 編集の前に、影響を受ける実装、呼び出し元、共通ユーティリティを読んでください。コードに関する主張は、確認した証拠に基づかせてください。
• 汎用的な動作を実装してください。テストでは正しい動作と不具合を区別できるようにしてください。テスト用データに合わせてハードコードしたり、明らかに誤ったテストを維持したりしてはいけません。
• 引き継ぎ時には、スコープ、修正内容、既存の認可を引き継いでください。該当する必須チェックを実行し、動作を変更した場合、または未解決の失敗がある場合に限り、再実行してください。

重大 — ラベルの整理

出荷するコードや文章から、非公開の計画ラベルやプロセスの説明を取り除いてください。ドメイン上の動作を直接記述してください。

• 計画ラベル — WS-N、Phase-A、Step-3、非公開の計画名は、ドメイン用語に置き換えてください。
• プロセスの説明 — 作成の経緯や、非公開の計画コンテキストがなければ理解できない記述を削除してください。最終的な動作や制約を説明してください。

有用な課題リンク、公開チケット識別子、ユーザーが求めた追跡可能性、成果物の形式として定められたラベルは残してください。レビュアー向けの移行ドキュメントでは、削除済みの成果物に言及してもかまいません。

8軸の判断によるコードレビュー。 5段階のパイプライン：スコープ → ツール一式 → 8人の並列軸別レビュアー → 新しいコンテキストでの検証担当者 → 統合。デフォルトでは最大限の強度で実行され、すべての軸と該当するツール一式をすべて使用し、サンプリングは行いません。--axes は明示的にスコープを限定したレビューであり、リポジトリ全体に対する判定は行いません。Anthropic のリモート /ultrareview とは異なり、同じ目標をユーザーのサブスクリプションでセッション内に実現します。

重要 — 文章作成ルール

出力する文章（ドキュメント、コメント、コミットメッセージ、PR 本文、リリースノート）には、以下のルールを適用してください。

• 周囲の句読点、大文字・小文字、書式に合わせてください。
• すべての文が読み手の理解を変えるようにしてください。そうでなければ削除してください。
• 行動または結果から書き始めてください。
• 比較や順序を明確にできる場合は、具体的な表現とリストを使ってください。
• 肯定形で述べてください。否定形は実際の制約に限ってください（NEVER commit secrets など）。
• マーケティング用語は使わないでください：powerful、robust、seamlessly、leverage、unlock、comprehensive、delightful。
• AI らしい表現は使わないでください：delve、tapestry、intricate、pivotal、testament、underscore、crucial、garner、showcase、additionally、moreover、furthermore、indeed。
• 内容のある英語の文章には、既存のスコープと認可のまま、インストール済みであれば /humanize-en を使ってください。これは承認段階を追加するものではありません。短いステータス文への重複した適用は省略してください。

目的

デフォルトでは、8 つの軸（正確性、簡素化、テスト、ドキュメント、スタイル、意図、設計/API、パフォーマンス）を個別の LLM 軸レビューアーとして実行します。ホストで利用可能なスロットに合わせてスケジュールし、scripts/run_battery.sh による決定論的なツールの検出結果を入力します。メタデータファイルが変更された場合は、9 つ目の軸として一貫性チェックも加わります。すべての軸とツールの観察結果には、文脈に応じた検証が行われます。ホストのモデルを引き継ぎます。信頼度はローカルな報告基準であり、較正された確率でも正しさの証明でもありません。検出結果を決定論的な重複排除、軸間の優先順位付け、A2 のサイレントドロップ防止とともに 1 つのレポートにまとめ、判定（出荷可能／修正後に出荷可能／要対応）を示します。レポートの最後には「確認しなかったこと」を記載し、対象範囲の限界を明示します。--axes はアナライザーと LLM レビューの両方を意図的に絞り込み、対象範囲に限定した検出結果を出力しますが、リポジトリ全体の判定は行いません。

パラメーター

フラグ	動作
-s	レポートと JSONL を ~/.agents/output/{project}/code-ultrareview/code-ultrareview-{slug}.{md,jsonl} に保存します
-S	保存しないよう強制します（周囲の保存モードより優先されます）
-b <ref>	レビューのベースを上書きします（scripts/resolve_base.sh による自動検出をスキップします）
--repo-kind <kind>	対象範囲の分類を上書きします。値：skills、app、library、docs、monorepo、python、rust、go、unknown。リポジトリごとの永続的な上書きは .code-ultrareview.yaml に設定します（repo_kind: <kind>）。競合する場合はフラグが優先されます。無効な値を指定すると終了コード 2 で終了します
--reconcile <input>	Intent 軸の導出サブモードを有効にします。<input> には @auto、@pr、明示的なパスまたはディレクトリ、gh:pr:<N>、gh:issue:<owner>/<repo>#<N>、または GitHub の Issue URL を指定できます。検出結果は GAP / SCOPE-ADD / DECISION-OVERRIDE / CONSISTENT に分類されます
--verify-build	新しいコンテキストのバリデーターを実行する前に、リポジトリの標準テストコマンドをアトミックなゲートとして実行します。コマンドまたはランナーが見つからない場合は終了コード 3、失敗またはタイムアウトの場合は終了コード 4 で終了します。汎用的なビルド結果によって検出結果の信頼度が変わることはありません
--mutation-test	Stryker（JS/TS）、Pitest（JVM）、または mutmut（Python）を実行します。Maven と Gradle は PATH からオフラインモードで実行されます。JS/TS の実行対象は変更されたソースファイルです。プロジェクト設定に基づいて実行する Python/JVM の結果は、変更されたファイルに関する検出結果に絞り込まれます。生き残ったミュータントは、Tests 軸で 🟠 中として報告されます
--apply-safe	書き込み機能をオプトインで有効にします。低リスクな修正（マニフェストのバージョン同期、全件合意ガード付きの構造化フィールドの説明同期、確認済みのバグごとに失敗するテストを 1 件）を自動適用します。書き込み前に差分プレビューとファイルごとの確認を行います
--include-prose	Coherence 軸で README の自由記述の段落も比較します（デフォルトでは構造化フィールドのみ）
--axes <list>	実行する軸をカンマ区切りで指定します（例：correctness,tests）。対象範囲に限定した検出結果のみを出力し、リポジトリ全体の出荷可能／修正後に出荷可能／要対応の判定は行いません。デフォルト：8 つすべて、および条件を満たす場合は Coherence
--preflight	scripts/preflight_tools.sh --scope <scope.json> を実行し、適用可能なアナライザーを検証するとともに、不足しているものの正確なインストールコマンドを表示します。対象範囲の網羅が不完全な場合は終了コード 3 で終了します。インストールは行いません

小文字は有効化、大文字は無効化を表します。-f はありません。このスキルは生成側であり、消費側ではありません。

/code-ultrareview                              # full 8-axis review, print report
/code-ultrareview -s                           # save the report + JSONL for /apex -f
/code-ultrareview -b origin/main               # review HEAD against an explicit base
/code-ultrareview --verify-build               # require the canonical project test gate to pass
/code-ultrareview --mutation-test              # require configured mutation coverage on changed code
/code-ultrareview --reconcile @auto            # add Intent derivation sub-mode with auto-detect
/code-ultrareview --apply-safe                 # full review + gated low-risk fixes
/code-ultrareview --preflight                  # list tools the battery would run, no review
/code-ultrareview --axes correctness,tests     # subset of axes

ワークフロー

レビューを統括する前に references/pipeline.md を読み、対象範囲、アナライザーのディスパッチ、アトミックな失敗処理、信頼境界、カバレッジの制限を確認してください。正確な Phase 3–5 のコマンドとスキーマについては references/orchestration.md を読み、その後 references/axes/ から選択した軸の概要のみを読み込んでください。

1. scripts/scope.py を実行して、差分、変更行の範囲、リポジトリの種類、言語、Coherence の有効化状態、および有効な指示チェーンを解決します。共有ルールは、有効な AGENTS エントリーポイントでそのファイルまたはディレクトリが明示的に参照されている場合にのみ読み込まれます。
2. scripts/run_battery.sh を実行します。Knip は適用範囲内の package.json がある場合にのみ実行されます。該当するものがない場合は適用外として記録され、適用範囲が一部に限られる場合はブロックされます。リポジトリルートにある JavaScript の宣言、またはツール関連のすべての入力を対象とする 1 つのワークスペースの宣言が、信頼できる唯一の宣言となります。そのプロジェクトのバイナリを使用してください。オフラインの Yarn Plug'n'Play 実行も含まれます。利用できない場合はブロックされます。宣言が複数ある場合、または宣言済みと未宣言のパッケージスコープが混在する場合は、アナライザーがリポジトリルートで 1 回宣言されるまでブロックされます。未宣言のアナライザーには、インストール済みの PATH コマンドを使用できます。Python およびネイティブのアナライザーには PATH を使用します。スキルの実行中にパッケージを解決するアナライザーは使用できません。
3. scripts/axis_dispatch.py を使って選択したすべての軸を準備し、ホストで利用可能なスロット内でレビュー担当者を割り当てます。分離されたエージェントを実行する機能がない場合は、同じ取り込み契約を使用して、共有コンテキストで順次レビューを実施し、独立性が低くなることを明示してください。
4. ツールによる観察結果や信頼度の高い作成者の主張を含め、すべての指摘についてコンテキストバリデーターを準備して実行します。ツールによる観察結果は、評価されるまで信頼度 0 として扱います。記録された判定なしに指摘が消えることはありません。
5. 要求されたツール、軸、バリデーター、ビルド、ミューテーション、および突合のカバレッジがすべて完了した後にのみ scripts/synthesize.py を実行します。標準レポートと Conventional Comments JSONL を出力します。

バッテリーは、適用可能なすべてのアナライザーをアトミックに事前チェックします。呼び出しが無効な場合、または入力が安全でない場合は終了コード 2、不足している前提条件がある場合は終了コード 3、アナライザーの失敗、タイムアウト、出力の形式不備、またはカバレッジ不足の場合は終了コード 4 で終了します。すべての失敗時に、プロジェクトに応じた対処方法と正確な再実行コマンドが出力されます。部分的な指摘は公開されず、リポジトリに対するすべての判定がブロックされます。--verify-build、--mutation-test、--reconcile、および --apply-safe はオプトインです。いずれかを使用する前に references/ultra-execution.md を読んでください。

最終レポートのレイアウト

templates/code-ultrareview.md は標準のワイヤーフォーマットです。すべての ## セクションを、絵文字の接頭辞を含め、テンプレートの順序どおりにそのまま出力してください。名前の変更、統合、順序の入れ替え、独自の形式への変更はできません。ターミナルへのエコーは必須です。実行のたびに、標準レポート全体をチャットターミナルに出力します。-s は追加の出力のみを行います（同一のバイト列を ~/.agents/output/{project}/code-ultrareview/code-ultrareview-{slug}.md に書き込み、ターミナル出力とバイト単位で一致させます）。重要度マーカーの対応（🔴 High はリリースをブロック · 🟠 Medium は早めに修正 · 🟢 Low は軽微な指摘 · ⚠️ Unverified は信頼度 80 未満）は scripts/synthesize.py:SEVERITY_MARKERS に定義されています。

信頼モデル

このスキルは、プロジェクトの指示ファイル、PR 本文、計画資料（--reconcile）、GitHub issue の本文など、間接的なプロンプトインジェクションを含む可能性のあるサードパーティのコンテンツを取り込みます。軸レビュー担当者とバリデーターは読み取り専用です（Write / Edit / Bash による変更は行いません）。--apply-safe による書き込みを行う前に、ユーザーがレポートを確認することが信頼境界となります。--apply-safe 自体も、差分のプレビューとファイルごとの確認を経てから書き込みを行います。

Phase 2、--verify-build、および --mutation-test は、レビュー対象プロジェクトで宣言されているツールをあなたの環境で実行します。信頼できないチェックアウトはサンドボックス内でレビューしてください。

ルール

• 新たな指摘のみ。 差分によって生じた問題のみを扱います。既存の指摘は、判定を覆すことなく、参考情報として Pre-existing のティアを付けます。
• 黙って除外しない（A2）。 80未満の肯定的な指摘は、スコアと検証者の理由を添えて ### ⚠️ Unverified に表示します。検証者のスコアが 0 の場合、統合時に指摘を却下します。
• 問題は明示する。 解決できないベース、前提条件の不足、アナライザーの失敗、または無効なレポートがあれば、判定を出す前にレビューを停止します。
• 正確に引用する。 すべての指摘に file:line を記載します。指示ルールに関する指摘では、違反したルールを原文どおりに引用し、その出典ファイルを明記します。パーマリンクには https://github.com/<owner>/<repo>/blob/<full-sha>/<path>#L<n>-L<m> を使用します（完全な SHA は git rev-parse HEAD で取得します）。
• 毎回、レポート全体をチャットに出力する。 呼び出すたびに、完全なレポートをターミナルに出力します。-s を指定すると同じバイト列をディスクに書き込みます。チャットへの出力を制限したり要約したりすることはありません。
• アナライザーはユーザーが管理する。 ツールが見つからない場合は、正確なインストールコマンドをプリフライトの標準エラー出力と tool-preflight.json に表示します。ユーザーがインストールした後、レビューを再実行します。
• デフォルトは読み取り専用。 コードを変更するには --apply-safe が必要です。各書き込み処理は外科的に行い、ファイルごとに確認します。

範囲

• セキュリティレビュー、実行時のプロファイリング、不安定なテストの検出は確認対象外であることを、必ず明記します。
• 指示の連鎖がない場合、Style では隣接する箇所で繰り返し使われている慣例のみを使用できます。独自に好みを作り出してはいけません。
• リポジトリの種類が不明な場合は、unknown の軸分岐を使用します。非アクティブな Coherence もレポートのヘッダーに表示します。
• --apply-safe を明示しない限り、読み取り専用です。より広範な修正は /apex -f <saved-report> に、単一の指摘への対応は /oneshot に振り分けます。
• Anthropic のリモート /ultrareview とは別のもので、現在のエージェントセッション内で実行されます。

参考資料

• パイプライン — references/pipeline.md（範囲、バッテリー、強制停止条件、信頼性、カバレッジ）、references/orchestration.md（Phase 3、4、3.5 の準備用 CLI とバンドルのスキーマ）。
• レビュアーの基本要素 — references/anthropic-verbatim.md（評価基準、HIGH SIGNAL、誤検知の分類）、references/axes-overview.md（8 つの軸、Coherence、軸間の優先順位）、references/axes/<name>.md（軸ごとの概要）。
• オプトインのフラグ — references/ultra-execution.md で --verify-build、--mutation-test、--reconcile、--apply-safe の詳細を確認できます。
• スクリプト — scope.py（Phase 1）、run_battery.sh と battery_ingest.py（Phase 2）、axis_dispatch.py（Phase 3）、run_validators.py（Phase 4）、synthesize.py、synthesis_core.py、findings_to_jsonl.py（Phase 5）。オプトイン：run_build_verify.py、run_mutation.py、derivation/run.py、preflight_tools.sh（--preflight）、apply_safe/{version_sync,description_sync,failing_test_writer}.py。