mcpField
U
ultra-review

ultra-review

github.com/dobroslavradosavljevicテスト・品質340 回インストール1 日前に更新
リポジトリ

ultra-review について

詳細で根拠に基づくコードレビューを行うスキルです。既定では読み取り専用で、現在の Git 変更または指定されたコード範囲を対象に、準備手順と構造化された指摘を求めます。

主な機能

  1. 01既定で現在の Git 変更をレビュー
  2. 02指定した対象や懸念点に切り替え
  3. 03関連する利用可能なスキルを確認・適用
  4. 04必要に応じて API や慣行を調査
  5. 05重大度別に根拠のある指摘を報告

活用シーン

  1. 01ステージ済み・未ステージの変更をレビュー
  2. 02指定したモジュールや機能を評価
  3. 03関連スキルとプロジェクト指針に沿って確認
  4. 04根拠のある実行可能な指摘をまとめる

インストール

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

$npx skills add https://github.com/dobroslavradosavljevic/skills --skill ultra-review

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
external-research.md
review-dimensions.md
skill-loading.md

詳細

Ultra Review

証拠に基づく、非常に詳細なコードレビューを実施します。デフォルトの対象は現在の Git 変更です。ユーザーがパス、モジュール、機能、パッケージ、または懸念事項を指定した場合は、その対象をレビューします。

ユーザーから修正の適用を明示的に求められない限り、このスキルは読み取り専用です。

必須のセットアップ

指摘事項を書く前に、以下をすべて完了してください。省略した場合、レビューは失敗です。

1. スコープを確定する

ユーザーが対象を指定していない場合は、デフォルトでGit 差分モードを使用します。

  1. ステータス、ステージ済みの差分、未ステージの差分を確認し、必要に応じて追跡対象のベースブランチより先にあるコミットも確認します。
  2. 依頼に関連する未コミットのワークツリー全体をレビューすることを優先します。ステージ済みのみ、または未ステージのみが対象なのか不明な場合は、前提を明記して作業を進めます。
  3. 無関係な変更済みファイルを除外するのは、ユーザーが対象外としている場合、または明らかにノイズ(生成されたロックファイルの変更、ローカル環境など)である場合に限ります。除外した場合は、その旨を記載します。

ユーザーがコードを指定した場合は、対象限定モードを使用します。

  1. 指定されたパス、モジュール、機能、またはパッケージを徹底的にレビューします。
  2. 正確性を判断するために必要な範囲でのみ、インポート元、呼び出し元、テスト、設定、コントラクトを追跡します。求められていないリポジトリ全体のレビューに範囲を広げないでください。

詳細なレビューに入る前に、確定したスコープを短い段落で示します。

2. 利用可能な関連スキルをすべて読み込む

コードを評価する前に、次の作業を行います。

  1. このセッションまたはハーネスで利用できるエージェントスキルを洗い出します(スキル一覧、スキルフォルダー、またはハーネスが提供する同等の検出手段を使います)。
  2. その一覧から、レビュー対象に関連する分野のスキルを説明や適用範囲に基づいてすべて読み込み、従います。対象分野には、言語、フレームワーク、ライブラリ、UI システム、データ/バリデーション、認証、テスト、ビルドツール、スタイリング、メール、キュー、オブザーバビリティ、アーキテクチャ上の制約などが含まれます。
  3. 対象範囲内のファイルや懸念事項に少しでも関係する可能性がある場合は、スキルを広めに読み込むことを優先します。
  4. 利用できないスキルを捏造しないでください。存在しないスキルに言及したり、依存したりしないでください。
  5. 読み込み後は、該当するコードのレビュー基準として、そのスキルの基準を適用します。

ハーネスがスキルを一覧表示または読み込みできない場合は、その旨を一度だけ伝え、その後はリポジトリのガイダンスや調査を続けます。

詳細:skill-loading.md。

3. 必要に応じて調査する

現在の一次資料にアクセスできる場合、ライブラリ、API、プロトコル、セキュリティ、または「適切な実装方法」に関する疑問を、記憶だけに頼ってレビューしないでください。

以下のいずれかに当てはまる場合は、調査が必須です。

  • コードがライブラリ、フレームワーク、SDK、API、CLI、またはクラウドサービスを使用または設定している。
  • 正確性が、バージョン固有の挙動、デフォルト値、または移行に関する情報に依存している。
  • セキュリティ、プライバシー、認証、暗号技術、決済、またはコンプライアンスのパターンが含まれている。
  • 変更が、確立された実践、RFC、アクセシビリティ標準、またはベンダーガイドに従うと主張している。
  • API、オプション、またはパターンが現行のもの、あるいは推奨されているものか確信が持てない。

調査方法:

  1. 利用可能な場合は、設定済みのドキュメント/調査ツールを優先します(ライブラリ用のドキュメント解決ツール、一般的な実践に関するウェブ/調査ツールなど)。
  2. ブログや記憶よりも、公式ドキュメント、変更履歴、RFC、一次規格を優先します。
  3. 指摘の根拠となったバージョンと参照元のリンク/パスを記録します。
  4. 調査が妨げられた場合は、該当する指摘の確度を低く示し、何を検証できなかったかを明記します。

詳細:external-research.md。

4. ローカルの確かな情報を読む

該当する場合は、以下も読み込みます。

  • リポジトリのエージェント向け指示と担当範囲に関するドキュメント
  • 近接するテスト、型、スキーマ、設定、公開エクスポート
  • 兄弟モジュールにおける既存のパターン(一貫性の基準)

レビューの深さ

review-dimensions.md に記載された該当するすべての観点をレビューしてください。スコープに該当する各観点について、次のいずれかを行ってください。

  • 根拠を示して具体的な指摘を挙げる、または
  • その観点を確認しなかったと誤解されるおそれがある場合に限り、「確認済み、問題なし」と明記する

推測に基づく細かな指摘で水増ししないでください。コメントの数よりも、重要度の高い指摘を少数挙げることを優先してください。それでも、すべての観点を網羅してください。「網羅的」とは、対象範囲を漏れなく確認することであり、問題を無理に見つけ出すことではありません。

指摘の基準

対応が必要な各指摘には、次の項目を含めてください。

  1. 重大度:blocker | high | medium | low | nit
  2. 場所:利用可能な場合は、パスとシンボル、行、または差分の参照
  3. 根拠:コードがどのように動作するか(簡潔な引用または言い換え)
  4. 重要性:具体的な不具合、リスク、または保守性への影響
  5. 推奨事項:具体的な修正方針
  6. 根拠の出典:読み込んだスキルのルール、ローカルの規約、テスト/契約、または外部ソース(外部の場合はリンク/バージョンを記載)

次の項目を分けてください。

  • 不具合(誤り、安全でない動作、破損した契約)
  • リスク(起こり得る障害、ガードの不足)
  • 設計(API/所有権/抽象化の問題)
  • 質問(プロダクトまたは担当者の判断が必要な事項)

質問を不具合として提示しないでください。

ワークフロー

- [ ] Resolve scope (git diff vs target)
- [ ] Inventory and load all relevant available skills
- [ ] Map stack, libraries, and risk areas in scope
- [ ] Run external research for triggered topics
- [ ] Read local instructions, tests, and sibling patterns
- [ ] Deep-read the code under review (not only the diff hunk)
- [ ] Score every applicable review dimension
- [ ] Cross-check findings against skills + sources
- [ ] Produce the review report

ハーネスが対応していて、スコープが大規模または複数の懸念事項にまたがる場合は、並列レビューエージェントを使用してください。最終レビューの統合には、引き続き1人のオーケストレーターが責任を持ちます。利用できない場合は、チャットで同じ確認を順番に行ってください。

レポート形式

## Scope
[diff | path] — files/areas included; exclusions

## Preparation
- Skills loaded: [names of skills actually loaded from this harness]
- Research: [sources/versions consulted, or none with reason]
- Local context: [key docs/tests/patterns read]

## Verdict
[ship | revise | blocked] — one sentence

## Findings
### Blockers
…

### High
…

### Medium
…

### Low / Nits
…

## Questions / Assumptions
…

## What looked solid
[short; only real strengths worth preserving]

## Residual risk
[what was out of scope, unverified, or research-blocked]

ブロッカーと重大度の高い指摘から記載してください。「問題なく見えた点」は、レビューを薄めないよう簡潔にしてください。

完了ルール

  • スキルの読み込みや必須の調査を省略した場合は、そのことを明らかにせずにレビューに問題がなかったと主張しないでください。
  • ユーザーが修正を依頼していない限り、レビュー中に修正しないでください。
  • 無関係なユーザー作業を尊重し、スコープ外のついでのクリーンアップを要求しないでください。
  • 指摘がない場合は、何を確認し、なぜ確信度が高いのかを述べてください。

コメント