repo-scan

repo-scan スキルの概要

repo-scan ができること

repo-scan は、リポジトリ内のコードのうち、どこまでが自前実装で、どこからがサードパーティ製コードか、あるいはビルド由来のノイズかを素早く把握するための、クロススタック対応のソース監査スキルです。Code Review 用の repo-scan や、移行計画、リファクタリング判断のために、何千ものファイルを手で流し読みする前に全体像をつかみたいときに特に役立ちます。

どんな人にインストール向きか

レガシーコードベース、モノレポ、あるいは所有関係が不明瞭な複数言語混在リポジトリを扱うなら、repo-scan スキルを使う価値があります。特に、C++、Android、iOS、Web のコードを一度で構造的に把握したいレビュアー、プラットフォームエンジニア、アーキテクトに向いています。

何が違うのか

repo-scan の主な価値は、単に依存関係を並べることではありません。ファイルを分類し、何を残すか、何を切り出すか、何を統合するか、何を削除するかの判断に直結する実行可能な評価を出せる点にあります。そのため、一般的なプロンプトよりも意思決定に寄っており、エコシステム別の依存ツールよりも実務上の判断材料として使いやすいです。

repo-scan スキルの使い方

repo-scan をインストールする

スキルファイルにある repo-scan のインストール手順に従い、再現性のために pinned commit の方式を維持してください。Claude の skills ディレクトリにインストールしたら、機密性の高いコードに使う前に、意図したソースを参照していることを確認します。

適切な入力から始める

repo-scan をうまく使うには、リポジトリのパス、監査の目的、そして対象範囲の境界をスキルに渡してください。たとえば、次のようなプロンプトが有効です: “Scan this monorepo and identify core assets, embedded third-party code, and likely dead weight before refactoring the payments service.”
これは “analyze this repo” より優れています。なぜなら、スキルが出すべき有益な評価が何を支えるべきかを具体的に示せるからです。

先に読むべきファイル

まず SKILL.md を開き、その後に、規約や例外を説明しているリポジトリレベルのドキュメントを確認してください。存在する場合は、README.md、AGENTS.md、metadata.json、および rules/、resources/、references/、scripts/ などの補助フォルダも、スキャン結果を鵜呑みにする前に読んでおくべきです。このリポジトリでは公開されているソースファイルは SKILL.md のみなので、インストール判断は主にその記載されたワークフローと、pinned source を自分で確認するかどうかにかかっています。

スキャンをレビューの流れに組み込む

repo-scan は、最初のふるい分けとして使い、その後で重要度の高い指摘を code review や targeted grep で確認するのが有効です。最適な流れは、リポジトリをスキャンする → フラグが立ったモジュールを調べる → 所有関係と埋め込みライブラリを検証する → その結果を refactor か cleanup の計画に落とし込む、という順番です。

repo-scan スキル FAQ

repo-scan は大規模リポジトリ専用ですか？

いいえ。大規模または複数言語混在のリポジトリで最も効果を発揮しますが、vendor 由来のコード、生成物、あるいはモジュール境界が不明瞭な小さめのコードベースでも役立ちます。すでに整理され、よく文書化されたリポジトリでは、効果は相対的に小さくなります。

repo-scan は通常のプロンプトとどう違いますか？

通常のプロンプトでもリポジトリの要約はできますが、repo-scan はファイル分類と評価を伴う、繰り返し使える監査ワークフローを回すことを目的にしています。そのため、Code Review 用の repo-scan は、一度きりの要約ではなく、安定した確認基準が必要な場面でより強力です。

repo-scan は初心者向けですか？

はい。明確な目的を伝え、出力を批判的に読めるなら使えます。このスキルはソース管理の基礎を教えるというより、判断を下すための材料を整理するものです。そのため初心者は、広く “analyze everything” と投げるのではなく、“what can be safely removed?” のような具体的な質問で使うべきです。

どんなときに repo-scan を使わないほうがいいですか？

高レベルの製品説明、パッケージ依存関係の一覧、ランタイムのデバッグだけが必要な場合は使わないでください。リポジトリが非常に小さい場合や、重要な論点がコード所有権ではなく動作テストにある場合も、repo-scan には向きません。

repo-scan スキルを改善する方法

監査範囲をもっと絞る

repo-scan の結果を改善する最善策は、リポジトリのどの切り出しを見たいのか、そしてどの判断に使うのかを明確にすることです。リポジトリ全体を見たいのか、単一サービスだけなのか、サードパーティコードや dead code になりそうなファイルだけなのかを指定してください。範囲を狭めるほどノイズの多い評価が減り、レポートを実際の行動に移しやすくなります。

使う出力を先に指定する

cleanup plan が必要なら、リスク順や工数順にモジュールを並べるよう求めてください。Code Review の補助が欲しいなら、埋め込みライブラリや生成アセットが所有関係の問題を隠していそうな箇所を挙げるよう依頼してください。repo-scan は、単にリポジトリ名を挙げるだけでなく、その先で何を決めたいのかをプロンプトに書いたときに最も効果を発揮します。

例外ケースは手動で検証する

よくある失敗は、生成ファイル、vendored code、言語固有のビルド出力に対する一次分類を過信してしまうことです。スキャン後は、最上位でフラグが立ったパスを確認し、リポジトリの規約と照らし合わせてください。そうしないと、見た目だけ冗長なコードを消してしまうおそれがあります。

指摘を次のアクションにつなげる

最初の repo-scan 出力を得たら、もっとも曖昧なモジュールを狙う追加質問を重ねてください。たとえば、“Which of these flagged directories are safe to archive?” や “Which third-party libraries appear embedded rather than declared?” のように聞くとよいです。そうすることで repo-scan を具体的な次の手順に結びつけたままにでき、最終的な監査の有用性も高まります。