mcpField
S
scout

scout

github.com/rshadeテスト・品質388 回インストール2 週間前に更新
リポジトリ

scout について

Scoutは、差分に含まれるファイルから、影響が大きくリスクの低い品質改善を見つけるコード保守向けスキルです。ファイル全体を読み、影響とリスクで評価した上位3件だけを具体案とともに提示します。

主な機能

  1. 01変更ファイルの検出またはパス指定
  2. 02差分だけでなくファイル全体を確認
  3. 03既存コードの品質改善に注目
  4. 04影響とリスクを評価
  5. 05具体案付きで上位3件を提示

活用シーン

  1. 01コミット前に変更ファイルの既存課題を整理
  2. 02保守に向けた低リスク改善の選定
  3. 03指定ブランチやパスのファイルを分析

インストール

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

$npx skills add https://github.com/rshade/agent-skills --skill scout

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

同梱ファイルevals/evals.jsonevals/fixture.py

詳細

Scout ルール

「見つけたときよりも、コードを良い状態にしておきましょう。」

差分で変更されたファイルから、影響が最も大きく、リスクが最も低い改善機会を上位 3 件特定します。変更行だけでなく、ファイル全体を読み取ります。既存のコード品質に注目します。修正すれば、次の開発者に感謝されるような点を探します。

前提条件の確認

git --version 2>/dev/null && git rev-parse --is-inside-work-tree 2>/dev/null

git がインストールされていない場合、または作業ディレクトリが git リポジトリではない場合は、停止して問題を報告してください。処理を続行しないでください。

変更されたファイルの検出

入力に応じて分析対象のファイルを決定します。

デフォルト — 作業ツリーとベースブランチの比較
# Detect base branch
BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \
  | sed 's@^refs/remotes/origin/@@' || echo "main")

# Combine committed + uncommitted + staged changes vs base
{ git diff --name-only ${BASE_BRANCH}...HEAD 2>/dev/null; \
  git diff --name-only; \
  git diff --name-only --cached; } | sort -u

すべてのソースから結果が返されない場合は、分析対象の変更ファイルがないことを報告してください。

特定のブランチ

ユーザーが分析対象のブランチを指定した場合は、デフォルトモードと同じ方法でベースブランチを検出し、その後、次のように差分を取得します。

BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \
  | sed 's@^refs/remotes/origin/@@' || echo "main")
git diff --name-only ${BASE_BRANCH}...${BRANCH}
特定のファイル

ブランチ名ではなくファイルパスの明示的なリストが指定された場合は、git diff を実行せず、それらを直接使用してください。

対象範囲

変更された各ファイルの全内容を読み取ってください。差分の該当部分だけに限定しないでください。ファイル全体から改善点を探してください。

次のことはしないでください。

  • PR の変更箇所のバグを見つける(それはコードレビュー担当者の仕事です)
  • アーキテクチャの再設計を提案する
  • コードベースで定着していないスタイル上の好みを指摘する
  • 新しい依存関係が必要な変更を提案する

カテゴリ

dead-code

使用されていない関数、変数、インポート、型。コメントアウトされたコードブロック。到達不能な分岐。完了済みの作業に言及する古い TODO/FIXME コメント。

naming

現在の動作と一致しない誤解を招く名前(コードは進化したが、名前が変わっていない)。同じファイル内で一貫していない命名パターン(例:getUserID と fetchUserId)。単純なループカウンターを超える、複雑なスコープでの 1 文字変数。読みやすさを損なう、短い単語の略語。

magic-values

名前付き定数にすべきハードコードされた数値や文字列。同じ概念を表す、繰り返し使われるリテラル値。説明なしにロジックに埋め込まれたタイムアウト値や制限値。

deprecated-patterns

同じコードベース内に新しい代替手段がある古い API。プロジェクトが採用しなくなったパターン(新しいファイルを確認して現在の方法を調べてください)。プロジェクトが別の規約を使うようになった後も残っている、古いエラー処理。

simplification

より直接的に表現できる、過度に複雑なロジック。価値を加えない不要な間接処理(何の価値も加えないラッパー関数)。不変条件がすでに保証されている場合の冗長な nil/エラーチェック。早期リターンでフラット化できる入れ子の条件分岐。

スコア付け

改善機会ごとに、次の 2 つの観点でスコアを付けてください(各 1~5 点)。

  • 影響度:修正によって次の開発者にどの程度役立ちますか?
    • 5 = 実際の混乱やバグを防ぐ
    • 3 = 読みやすさが目に見えて向上する
    • 1 = わずかな仕上げ
  • 低リスク度:この変更はどの程度安全ですか?
    • 5 = 動作が変わる可能性のない、純粋な整理
    • 3 = 安全だが、ロジック経路に手を加える
    • 1 = 慎重に行わないと動作が変わる可能性がある

総合スコア = 影響度 × 低リスク度。上位 3 件のみを返してください。

出力形式

概要の表に続けて、提案ごとの詳細を提示してください。

#File:LineCategoryDescriptionEffortScore
1locationcategorydescriptioneffortI×R=S
2locationcategorydescriptioneffortI×R=S
3locationcategorydescriptioneffortI×R=S

各提案には、次の内容を含めてください。

  • カテゴリと工数(trivial / small / medium)
  • 重要な理由 — 次の開発者にとっての価値を説明する 1 文
  • 提案する変更 — 改善を示す具体的なコードスニペットまたは差分

改善機会が見つからなかった場合は、次のように報告してください。

重要な改善機会は見つかりませんでした。変更されたファイルは良好な状態です。

アンチパターン — 提案しないでください

  • ファイルやモジュール全体のリファクタリング
  • 公開 API のシグネチャの変更
  • コードベースで確立されていないスタイル上の好み
  • 新しい依存関係やアーキテクチャ上の判断が必要なもの
  • 約20行を超える変更
  • リンターで検出できる問題

コメント