mcpField
R
review-rust

review-rust

github.com/existential-birdsテスト・品質8579 回インストール11 週間前に更新
リポジトリ

review-rust について

review-rustは、エージェント向けのRustコードレビュー用スキルです。対象範囲とコンパイラを確認し、技術領域ごとのレビューと指摘の検証を段階的に進めます。

主な機能

  1. 01変更されたRustファイルの特定
  2. 02EditionとMSRVの確認
  3. 03Clippyとコンパイラの検証
  4. 04技術別のレビュー指針
  5. 05指摘の根拠確認
  6. 06並列または順次レビュー

活用シーン

  1. 01マージ前のRust変更レビュー
  2. 02コンパイラやClippyの出力との照合
  3. 03検出された技術に応じたレビュー

インストール

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

$npx skills add https://github.com/existential-birds/beagle --skill review-rust

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

詳細

Rust コードレビュー

引数

  • --parallel:エージェントがサブエージェントに対応している場合は、技術分野ごとに 1 つずつ並列に割り当てます。対応していない場合は、同じ出力になるよう順番に実行します。
  • パス:対象ディレクトリ(デフォルト:現在の作業ディレクトリ)

必須ゲート

出力の Issues を記述する前に、以下を順番に完了してください(対象範囲が空でも構いません。指摘を捏造してはいけません)。

  1. スコープゲート: レビュー対象の .rs ファイルのパスを明示的に列挙します(ステップ 1 またはユーザーが指定したパスから)。合格条件: リストを出力するか、「No Rust files in scope」と出力して終了します。その場合、Issues は記述しません。
  2. コンパイラー/リンターゲート: ステップ 3 のコマンドをクレートまたはワークスペースのルート(Cargo.toml がある場所)から実行します。実行できない場合は、その理由を 1 行で示します(例:ツールチェーンがない、Cargo.toml がない、サンドボックス環境)。合格条件: ステップ 3 の出力でエラー/警告としてすでに示された問題を報告せず、作者が先に修正すべきコンパイラーまたは Clippy の診断を重複して報告しません。
  3. プロトコルゲート: ステップ 7 の前に review-verification-protocol スキルを読み込みます。合格条件: すべての Critical/Major の指摘がステップ 8(およびプロトコル)を満たします。指摘がない場合は、Review Summary に「Protocol applied; no issues」と記載します。
  4. エビデンスゲート(Critical/Major): 各 Critical または Major の項目について、FILE:LINE の位置を周辺の全コンテキストとともに再読します(差分の該当箇所だけに限りません)。合格条件: Issue の説明が、その位置で確認できるコードと一致します。

ステップ 1:変更ファイルの特定

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.rs$'

ステップ 2:Rust のエディションと MSRV の確認

# Check Cargo.toml for edition and rust-version
grep -E 'edition|rust-version' Cargo.toml

# Check workspace members if workspace
grep -A 20 '\[workspace\]' Cargo.toml

Edition 2024 に関する注意事項(MSRV 1.85 以降が必要です):

edition = "2024" が検出された場合、レビュー全体を通じて以下の動作変更が適用されます。

  • unsafe_op_in_unsafe_fn はデフォルトで deny になります。unsafe fn 内の unsafe 操作では、明示的な unsafe {} ブロックを使用する必要があります。
  • extern "C" {} ブロックは unsafe extern "C" {} にする必要があります。
  • #[no_mangle] と #[export_name] は、それぞれ #[unsafe(no_mangle)] と #[unsafe(export_name)] にする必要があります。
  • -> impl Trait はデフォルトでスコープ内のすべてのライフタイムをキャプチャします(RPIT のライフタイムキャプチャ変更)。キャプチャ対象を明示するには + use<'a> を使用します。
  • gen は予約語です。識別子として使う場合は r#gen を使用する必要があります。
  • !(never 型)は () ではなく ! にフォールバックするため、推論された型の動作が変わる可能性があります。
  • if let 条件式および末尾式の一時値は、edition 2021 より早い段階で破棄されます。
  • Box<[T]> が IntoIterator を実装するようになりました。

検出したエディションを記録してください。これはステップ 3、8、および検証プロトコルにおける重大度の判定に影響します。

ステップ 3:リンターの状態を確認

重要:スタイルや正確性の問題を指摘する前に、clippy と check を実行してください。clippy またはコンパイラーがすでに検出する問題を指摘してはいけません。

cargo clippy --all-targets --all-features -- -D warnings 2>&1 | head -50
cargo clippy -- -D clippy::perf 2>&1 | head -20
cargo check --all-targets 2>&1 | head -50

Edition 2024 に関する注意: Edition 2024 では、これまで警告だった複数の lint が deny に昇格しています(特に unsafe_op_in_unsafe_fn)。clippy または cargo check がエディションに関連するエラーをすでに報告している場合、それらをレビュー指摘として重複して報告してはいけません。代わりに、作者がまずコンパイラーエラーを修正する必要があることを記載してください。

ステップ 4:テクノロジーを検出する

# Detect tokio async runtime
grep -r "tokio" --include="Cargo.toml" -l | head -3

# Detect axum web framework
grep -r "axum" --include="Cargo.toml" -l | head -3

# Detect sqlx database
grep -r "sqlx" --include="Cargo.toml" -l | head -3

# Detect serde serialization
grep -r "serde" --include="Cargo.toml" -l | head -3

# Detect thiserror / anyhow
grep -r "thiserror\|anyhow" --include="Cargo.toml" -l | head -3

# Detect tracing
grep -r "tracing" --include="Cargo.toml" -l | head -3

# Check for test files in diff
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '((^|/)(test|tests)/.*\.rs$)|(_test\.rs$)'

# Check for unsafe code in diff
git diff $(git merge-base HEAD main)..HEAD -- '*.rs' | grep -c 'unsafe'

# Detect async fn in traits (no async-trait crate needed since Rust 1.75)
grep -r "async-trait" --include="Cargo.toml" -l | head -3

# Detect LazyLock/LazyCell usage (replaces once_cell/lazy_static since 1.80)
grep -r "once_cell\|lazy_static" --include="Cargo.toml" -l | head -3

# Detect #[expect] lint attribute usage (stable since 1.81)
git diff $(git merge-base HEAD main)..HEAD -- '*.rs' | grep -c '#\[expect('

# Detect macro definitions in diff
git diff $(git merge-base HEAD main)..HEAD -- '*.rs' | grep -cE 'macro_rules!|#\[proc_macro|#\[derive\('

# Detect FFI code in diff
git diff $(git merge-base HEAD main)..HEAD -- '*.rs' | grep -cE 'extern "C"|#\[no_mangle\]|#\[repr\(C\)\]|bindgen|#\[unsafe\(no_mangle\)\]'

# Detect concurrency primitives (atomics, lock-free, hand-rolled sync)
git diff $(git merge-base HEAD main)..HEAD -- '*.rs' | grep -cE 'std::sync::atomic|Atomic(Bool|U?size|U?(8|16|32|64)|Ptr)|compare_exchange|fetch_(add|sub|or|and|xor|update)|UnsafeCell|unsafe impl (Send|Sync)|Ordering::(Relaxed|Acquire|Release|AcqRel|SeqCst)|atomic::fence'

# Detect concurrency test tooling
grep -rE 'loom|^miri$' --include='Cargo.toml' -l | head -3
git diff $(git merge-base HEAD main)..HEAD -- '*.rs' | grep -cE 'loom::|#\[cfg\(loom\)\]|cfg_attr\(miri'

# Detect concurrency crates
grep -rE '^crossbeam|^arc-swap|^parking_lot|^dashmap|^flurry|^haphazard|^seize|^atomic_wait' --include='Cargo.toml' -l | head -3

# Detect criterion benchmarks
grep -rE '^criterion' --include='Cargo.toml' -l | head -3
ls -d benches 2>/dev/null

# Detect proc-macro crate or trybuild
grep -rE 'proc-macro\s*=\s*true|^trybuild' --include='Cargo.toml' -l | head -3

# Detect public-surface changes (interface-design.md routing)
git diff $(git merge-base HEAD main)..HEAD -- '*.rs' | grep -cE '^\+\s*pub (trait|fn|struct|enum|mod|use)|^\+\s*impl[<\s].*Drop for'

# Detect ecosystem patterns (patterns-in-the-wild.md routing)
grep -rE '^slotmap|^petgraph|^scopeguard|^indexmap' --include='Cargo.toml' -l | head -3
git diff $(git merge-base HEAD main)..HEAD -- '*.rs' | grep -cE 'mem::replace|swap_remove|prelude'

最新の Rust の検出に関する注意事項:

  • async-trait が依存関係に含まれていて、プロジェクトがエディション 2024 または MSRV >= 1.75 を使用している場合は、情報提供として指摘してください。トレイトでネイティブの async fn が利用できるため、async-trait は削除できる可能性があります。
  • once_cell または lazy_static が依存関係に含まれていて、MSRV >= 1.80 の場合は、情報提供として指摘してください。std::sync::LazyLock と std::cell::LazyCell が安定版の代替手段です。
  • #[expect(...)] のほうが適切な箇所で #[allow(...)] が使用されている場合(MSRV >= 1.81)は、軽微な問題として記載してください。抑制した lint が発生しなくなると #[expect] が警告を出すため、抑制を適切に保てます。

並行処理の検出に関する注意事項:

  • 差分にアトミック操作(std::sync::atomic、compare_exchange、fetch_*)、UnsafeCell、unsafe impl Send/Sync、または crossbeam / arc-swap / parking_lot が含まれる場合は、rust-code-review スキルを読み込み、references/concurrency-primitives.md、references/memory-ordering.md、references/lock-free-patterns.md を参照してください。
  • 差分で並行処理が導入または再構成される場合(ワーカープール、アクタースタイルのチャネル、tokio::spawn のパターン、スレッドと非同期処理の選択など)は、設計レベルのレビュー項目として references/concurrency-models.md も参照してください。
  • 手書きのアトミック操作やロックフリー型があり、loom 依存関係も CI での cargo +nightly miri test もない場合は、rust-testing-code-review スキルを読み込み、references/concurrency-testing.md を参照してください。

インターフェース設計/API サーフェスの検出:

  • 差分で pub trait、pub fn、pub struct、公開型への derive 実装、所有型に対する impl Drop、または外部型の再エクスポートが導入または変更される場合は、rust-code-review スキルを読み込み、オブジェクト安全性、使いやすい実装、失敗しうるデストラクター、隠れた契約に関するレビュー項目について references/interface-design.md を参照してください。
  • インデックスとポインターによるグラフ(Vec<Node> + usize、slotmap、petgraph)、mem::replace スタイルのドロップガード、拡張トレイトが使用されている場合、または prelude モジュールが変更される場合は、references/patterns-in-the-wild.md も参照してください。

テストの検出(criterion/trybuild/clippy の方針):

  • benches/ ディレクトリまたは criterion 依存関係がある場合は、rust-testing-code-review スキルを読み込み、criterion のベースライン、black_box、iter_batched に関するレビュー項目について references/advanced-testing.md を参照してください。
  • proc-macro クレート(proc-macro = true)または [dev-dependencies] に trybuild がある場合は、trybuild の .stderr の安定性チェックについて rust-testing-code-review スキルの references/advanced-testing.md を参照し、スパンの衛生状態と syn の機能監査について macros-code-review スキルの references/procedural-macros.md を参照してください。

ステップ 5:検証プロトコルを読み込む

review-verification-protocol スキルを読み込み、レビュー全体を通じてそのチェックリストを念頭に置いてください。

ステップ 6:スキルを読み込む

該当するスキルをそれぞれ(例:rust-code-review スキルを読み込む)SKILL.md を読んで適用してください。

必ず読み込む:

検出内容に応じて読み込む:

条件スキル
Tokio を検出tokio-async-code-review
Axum を検出axum-code-review
sqlx を検出sqlx-code-review
Serde を検出serde-code-review
テストファイルに変更ありrust-testing-code-review
diff にマクロ定義ありmacros-code-review
FFI コードを検出(extern、repr(C)、bindgen)ffi-code-review
Atomics、UnsafeCell、unsafe impl Send/Sync、compare_exchange、crossbeam、arc-swap、parking_lotrust-code-review(references/concurrency-primitives.md、references/memory-ordering.md、references/lock-free-patterns.md を読み込む)
並行処理設計に変更あり(ワーカープール、チャネル、スレッドと非同期処理の再構成)rust-code-review(references/concurrency-models.md を読み込む)
公開トレイト/pub fn/pub struct/impl Drop/再エクスポートに変更ありrust-code-review(references/interface-design.md を読み込む)
グラフ/ツリーのコード、slotmap、petgraph、mem::replace のドロップガード、拡張トレイト、prelude モジュールに変更ありrust-code-review(references/patterns-in-the-wild.md を読み込む)
criterion ベンチマーク、benches/ ディレクトリrust-testing-code-review(references/advanced-testing.md を読み込む — criterion のベースライン、black_box、iter_batched を確認)
Proc-macro クレート(proc-macro = true)または dev-deps に trybuildrust-testing-code-review と macros-code-review(references/advanced-testing.md の trybuild と references/procedural-macros.md の span hygiene を読み込む)
loom、miri、テスト対象の手書きロックフリーコードrust-testing-code-review(references/concurrency-testing.md を読み込む)

ステップ 7:レビュー

エージェントがサブエージェントに対応している場合は、技術領域ごとに 1 つずつ並行して割り当ててください。対応していない場合は、単一のコンテキスト内で各領域を順番に実行してください。どちらの場合も出力は同じです。

並行処理の手順(サブエージェントに対応している場合):

  1. すべての技術を事前に検出する
  2. 技術領域ごとにサブエージェントを 1 つ割り当てる
  3. 各サブエージェントがスキルを読み込み、担当領域をレビューする
  4. すべてのサブエージェントの完了を待つ
  5. 指摘事項をまとめる

順次処理の手順(サブエージェントに対応していない場合):

  1. 該当するスキルを読み込む
  2. Rust の基本的な品質(所有権、エラー処理、unsafe、トレイト)をレビューする
  3. 検出した技術領域を順番にレビューする
  4. 指摘事項をまとめる

ステップ 8:指摘事項の検証

問題を報告する前に、次のことを確認してください。

  1. 実際のコードを読み直す(差分の文脈だけではなく)
  2. 「未使用」と指摘する場合、ワークスペース全体で参照をすべて検索しましたか?
  3. 「不足している」と指摘する場合、トレイト定義、derive マクロ、#[cfg] でゲートされたコードを確認しましたか?
  4. 「不要なクローン」と指摘する場合、借用チェッカーが参照を許可するか確認しましたか?
  5. 「安全でない」と指摘する場合、安全性に関するコメントと周辺の不変条件を確認しましたか?
  6. 実際の問題ではなく、スタイル上の好みにすぎない指摘は削除してください

Edition 2024 の検証ルール: 7. unsafe fn 内の unsafe {} ブロックを不要と指摘しないでください — Edition 2024 では必須です 8. unsafe extern "C" を珍しい構文と指摘しないでください — Edition 2024 では必須です 9. #[unsafe(no_mangle)] または #[unsafe(export_name)] を珍しい構文と指摘しないでください — Edition 2024 では必須です 10. -> impl Trait の戻り値では、暗黙のライフタイムキャプチャが意図的かどうかを確認してください — Edition 2024 では、スコープ内のすべてのライフタイムがデフォルトでキャプチャされます。より狭いキャプチャが必要な場合に限り、+ use<'a> を提案してください 11. イテレーターの文脈で Box<[T]> を使うコードについては、Edition 2024 では IntoIterator が利用可能になったことに留意してください — .iter() が唯一の方法だと指摘しないでください 12. if let や末尾式の一時値が借用の問題を引き起こす場合、Edition 2024 で破棄のタイミングが早まったことが根本原因かどうかを検討してください

ステップ 9:レビューの収束

1 回のレビューでの完全性

1 回のレビューですべてのカテゴリ(所有権、エラー処理、非同期処理、型、テスト、セキュリティ、パフォーマンス)にわたるすべての問題を必ず報告してください。後のラウンドに問題を持ち越さないでください。

指摘事項を提出する前に、自問してください。

  • 「推奨した修正をすべて適用した場合、修正後のコードで新たな問題が見つかるでしょうか?」
  • 「それ自体がレビューを必要とする新しいコード(テスト、型、モジュール)を求めていませんか?」

どちらかの答えが「はい」なら、作成者がすべてを一度に対処できるよう、予想される後続の問題も今回のレビューに含めてください。

スコープのルール
  • 差分内のコードと、それに直接関連する既存のコードのみをレビューしてください
  • 差分以前には存在しなかった新機能、テスト基盤、アーキテクチャ変更を要求しないでください
  • テストカバレッジが不足している場合は、「X、Y、Z のテストカバレッジ不足」という 1 件の Minor 問題として指摘してください — 実装の詳細は指定しないでください
  • ドキュメントコメントや命名の問題は、公開 API の契約に影響する場合を除き Minor です
  • 新しい依存関係(例:proptest、mockall、criterion)の追加を要求しないでください
修正の複雑さに関する予算

既存コードへの修正は、規模にかかわらず実際の重大度で指摘してください。

ただし、差分以前には存在しなかった新規コードの追加要求は Informational に分類する必要があります。

  • 新しい依存関係の追加
  • まったく新しいモジュール、ファイル、テストスイートの作成
  • 新しいトレイトや抽象化の抽出
  • ベンチマークスイートの追加

これらは、今後の作業で作成者が検討するための改善提案であり、レビューを阻止するものではありません。

反復ポリシー

修正適用後の再レビューの場合:

  • 以前指摘した問題が正しく対処されたかどうかのみを確認してください
  • 以前の指摘に関係のない新しい指摘を追加しないでください
  • 修正されていない Minor/Nice-to-Have の問題は受け入れ、再度指摘しないでください
  • 再レビューの目的は検証であり、新たな問題の発見ではありません

出力形式

## Review Summary

[1-2 sentence overview of findings]

## Issues

### Critical (Blocking)

1. [FILE:LINE] ISSUE_TITLE
   - Issue: Description of what's wrong
   - Why: Why this matters (unsound unsafe, data race, panic, security)
   - Fix: Specific recommended fix

### Major (Should Fix)

2. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Minor (Nice to Have)

N. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Informational (For Awareness)

N. [FILE:LINE] SUGGESTION_TITLE
   - Suggestion: ...
   - Rationale: ...

## Good Patterns

- [FILE:LINE] Pattern description (preserve this)

## Verdict

Ready: Yes | No | With fixes 1-N (Critical/Major only; Minor items are acceptable)
Rationale: [1-2 sentences]

ルール

  • Issues を記述する前に、必須ゲートを完了してください
  • レビュー前にスキルを読み込んでください(レビュー後ではありません)
  • すべての問題に 1、2、3…と連番を付けてください
  • 各問題に FILE:LINE を記載してください
  • Issue/Why/Fix を明確に分けてください
  • 実際の重大度に分類してください
  • スタイル上の問題を指摘する前に clippy を実行してください
  • 修正後に検証を実行してください
  • 1 回のレビューですべての問題を報告してください — 後の反復に指摘を持ち越さないでください
  • 再レビューでは以前の修正のみを検証してください — 新しい問題の発見は行わないでください
  • 新規コード(新しいモジュール、依存関係、テストスイート)の追加要求は、ブロッキングではなく Informational としてください
  • Verdict では Minor と Informational の項目は無視されます — 承認を妨げるのは Critical と Major のみです

修正後の検証

修正を適用した後、次を実行します。

cargo check --all-targets
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-targets

承認前に、すべてのチェックに合格する必要があります。

コメント