Agent Sort（エビデンスベースECC選別）
このスキルは、リポジトリにデフォルトのフルインストールではなく、プロジェクト固有のECC環境が必要な場合に使用します。
目標は「便利そう」と推測することではありません。目標は、実際のコードベースからのエビデンスを用いてECCコンポーネントを分類することです。
使用するタイミング
- プロジェクトがECCのサブセットのみを必要としており、フルインストールではノイズが多すぎる場合
- リポジトリのスタックは明確だが、誰もスキルを一つずつ手動で厳選したくない場合
- チームが意見ではなく、grepによるエビデンスに裏付けられた繰り返し可能なインストール判断を望む場合
- 常時読み込むDAILYワークフローのインターフェースと、検索可能なライブラリ/参照用インターフェースを分離したい場合
- リポジトリが間違った言語、ルール、フックセットに漂流しており、クリーンアップが必要な場合
絶対的なルール
- 常に現在のリポジトリを事実の出典とし、汎用的な設定を優先しない
- DAILYの判断には、具体的なリポジトリのエビデンスを必ず引用する
- LIBRARYは「削除」を意味せず、「デフォルトでは読み込まないがアクセス可能に保つ」ことを意味する
- 現在のリポジトリが使用できないフック、ルール、スクリプトをインストールしない
- ECCネイティブのインターフェースを優先し、別のインストールシステムを導入しない
出力成果物
以下のアーティファクトをこの順序で生成します：
- DAILY インベントリ
- LIBRARY インベントリ
- インストール計画
- 検証レポート
- オプションの
skill-libraryルーター（プロジェクトが必要とする場合）
分類モデル
2つのバケットのみを使用します：
DAILY- このリポジトリのすべてのセッションで読み込むべき
- リポジトリの言語、フレームワーク、ワークフロー、またはオペレーターインターフェースに強くマッチしている
LIBRARY- 保持しておくと便利だが、デフォルトで読み込む価値はない
- 検索、ルータースキル、または選択的な手動使用で到達可能にすべき
エビデンスソース
分類を行う前に、リポジトリローカルのエビデンスを使用します：
- ファイル拡張子
- パッケージマネージャとロックファイル
- フレームワーク設定
- CIおよびフック設定
- ビルド/テストスクリプト
- インポートと依存関係マニフェスト
- スタックを明示的に説明するリポジトリドキュメント
有用なコマンドには以下が含まれます：
rg --files
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
cat package.json
cat pyproject.toml
cat Cargo.toml
cat pubspec.yaml
cat go.mod
並列レビューパス
並列サブエージェントが利用可能な場合、レビューを次のパスに分割します：
- エージェント
agents/*を分類
- スキル
skills/*を分類
- コマンド
commands/*を分類
- ルール
rules/*を分類
- フックとスクリプト
- フックインターフェース、MCPヘルスチェック、ヘルパースクリプト、OS互換性を分類
- その他
- コンテキスト、例、MCP設定、テンプレート、ガイダンスドキュメントを分類
サブエージェントが利用できない場合は、同じパスを順次実行します。
コアワークフロー
1. リポジトリを読み取る
何かを分類する前に、実際のスタックを特定します：
- 使用中の言語
- 使用中のフレームワーク
- 主要なパッケージマネージャ
- テストスタック
- リンター/フォーマッタースタック
- デプロイメント/ランタイム環境
- 既に存在するオペレーター統合
2. エビデンステーブルを作成する
すべての候補インターフェースについて、以下を記録します：
- コンポーネントパス
- コンポーネントタイプ
- 提案バケット
- リポジトリのエビデンス
- 簡単な説明
以下の形式を使用します：
skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | コアフロントエンドスタック
skills/django-patterns | skill | LIBRARY | no .py files, no pyproject.toml | このリポジトリではアクティブではない
rules/typescript/* | rules | DAILY | package.json + tsconfig.json | アクティブなTSリポジトリ
rules/python/* | rules | LIBRARY | zero Python source files | アクセスのみ保持
3. DAILY vs LIBRARY を決定する
以下の場合に DAILY に昇格させます：
- リポジトリが明確に対応するスタックを使用している場合
- コンポーネントがすべてのセッションに役立つほど汎用的である場合
- リポジトリがすでに対応するランタイムまたはワークフローに依存している場合
以下の場合に LIBRARY に降格させます：
- コンポーネントがスタック外である場合
- リポジトリが後で必要になる可能性があるが、毎日は必要ない場合
- 即時的な関連性がないのにコンテキストのオーバーヘッドを増加させる場合
4. インストール計画を作成する
分類をアクションに変換します：
- DAILY スキル ->
.claude/skills/にインストールまたは維持 - DAILY コマンド -> まだ有用な場合のみ、明示的なshimとして保持
- DAILY ルール -> マッチする言語セットのみインストール
- DAILY フック/スクリプト -> 互換性のあるもののみ保持
- LIBRARY インターフェース -> 検索または
skill-library経由でアクセス可能に維持
リポジトリがすでに選択的インストールを使用している場合は、別のシステムを作成する代わりに、その計画を更新します。
5. オプションのライブラリルーターを作成する
プロジェクトが検索可能なライブラリインターフェースを望む場合は、以下を作成します：
.claude/skills/skill-library/SKILL.md
そのルーターには以下を含める必要があります：
- DAILY vs LIBRARY の簡単な説明
- グループ化されたトリガーキーワード
- ライブラリ参照の保存場所
ルーター内にすべてのスキル本文を複製しないでください。
6. 結果を検証する
計画を適用した後、以下を検証します：
- すべてのDAILYファイルが期待される場所に存在するか
- 古い言語ルールがアクティブのまま残っていないか
- 互換性のないフックがインストールされていないか
- 結果のインストールが実際にリポジトリスタックにマッチしているか
以下の項目を含む簡潔なレポートを返します：
- DAILY カウント
- LIBRARY カウント
- 削除された古いインターフェース
- 未解決の疑問点
引き継ぎ
次のステップがインタラクティブなインストールや修復である場合、以下に引き継ぎます：
configure-ecc
次のステップが重複のクリーンアップやカタログレビューである場合、以下に引き継ぎます：
skill-stocktake
次のステップがより広範なコンテキストのトリミングである場合、以下に引き継ぎます：
strategic-compact
出力形式
結果をこの順序で返します：
STACK
- 言語/フレームワーク/ランタイムの概要
DAILY
- エビデンス付きの常時読み込みアイテム
LIBRARY
- エビデンス付きの検索可能/参照アイテム
INSTALL PLAN
- インストール、削除、またはルーティングすべきもの
VERIFICATION
- 実行されたチェックと残っているギャップ