agent-sort

name	agent-sort
description	リポジトリ認識の並列レビューパスを使用してスキル、コマンド、ルール、フック、その他を DAILY と LIBRARY のバケットに分類することで、特定のリポジトリ向けにエビデンスに基づく ECC インストールプランを構築します。フルバンドルをロードするのではなく、プロジェクトが実際に必要とするものに ECC をトリミングすべき場合に使用します。
origin	ECC

Agent Sort

デフォルトのフルインストールではなく、プロジェクト固有の ECC サーフェスが必要なリポジトリに対して、このスキルを使用します。

目標は「役立ちそう」と推測することではありません。目標は、実際のコードベースからのエビデンスを持って ECC コンポーネントを分類することです。

使用タイミング

• プロジェクトが ECC のサブセットのみを必要とし、フルインストールがノイジーすぎる
• リポジトリのスタックは明確だが、スキルを 1 つずつ手動でキュレートしたくない
• チームが意見ではなく grep エビデンスに裏付けられた再現可能なインストール判断を望む
• 常時ロードされる daily のワークフローサーフェスを、検索可能なライブラリ/リファレンスサーフェスから分離する必要がある
• リポジトリが誤った言語、ルール、またはフックセットにドリフトしており、クリーンアップが必要

非交渉のルール

• 汎用的な好みではなく、現在のリポジトリを信頼できる情報源として使用する
• すべての DAILY 判断は具体的なリポジトリエビデンスを引用しなければならない
• LIBRARY は「削除」を意味しない。「デフォルトでロードせずにアクセス可能に保つ」を意味する
• 現在のリポジトリが使用できないフック、ルール、またはスクリプトをインストールしない
• ECC ネイティブのサーフェスを優先する。第二のインストールシステムを導入しない

出力

以下のアーティファクトを順番に生成します:

1. DAILY インベントリ
2. LIBRARY インベントリ
3. インストールプラン
4. 検証レポート
5. プロジェクトが希望する場合、オプションの skill-library ルーター

分類モデル

バケットは 2 つのみ使用します:

• DAILY
  • このリポジトリでは毎セッションでロードされるべき
  • リポジトリの言語、フレームワーク、ワークフロー、またはオペレーターサーフェスに強くマッチ
• LIBRARY
  • 保持する価値はあるが、デフォルトでロードする価値はない
  • 検索、ルータースキル、または選択的な手動使用を通じて到達可能であるべき

エビデンスソース

分類を行う前に、リポジトリローカルのエビデンスを使用します:

• ファイル拡張子
• パッケージマネージャとロックファイル
• フレームワーク設定
• CI とフックの設定
• ビルド/テストスクリプト
• import と依存関係マニフェスト
• スタックを明示的に記述するリポジトリドキュメント

有用なコマンド:

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

並列レビューパス

並列サブエージェントが利用可能な場合、レビューを以下のパスに分割します:

1. Agents
   • agents/* を分類
2. Skills
   • skills/* を分類
3. Commands
   • commands/* を分類
4. Rules
   • rules/* を分類
5. Hooks and scripts
   • フックサーフェス、MCP ヘルスチェック、ヘルパースクリプト、OS 互換性を分類
6. Extras
   • コンテキスト、例、MCP 設定、テンプレート、ガイダンスドキュメントを分類

サブエージェントが利用できない場合、同じパスを逐次実行します。

コアワークフロー

1. リポジトリを読む

分類を行う前に実際のスタックを確立します:

• 使用されている言語
• 使用されているフレームワーク
• 主要なパッケージマネージャ
• テストスタック
• lint/format スタック
• デプロイ/ランタイムサーフェス
• 既に存在するオペレーター統合

2. エビデンステーブルを構築する

候補となるすべてのサーフェスについて記録します:

• コンポーネントパス
• コンポーネントタイプ
• 提案バケット
• リポジトリエビデンス
• 簡潔な根拠

以下のフォーマットを使用します:

skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
skills/django-patterns   | skill | LIBRARY | no .py files, no pyproject.toml       | not active in this repo
rules/typescript/*       | rules | DAILY | package.json + tsconfig.json            | active TS repo
rules/python/*           | rules | LIBRARY | zero Python source files             | keep accessible only

3. DAILY と LIBRARY を決定する

以下の場合に DAILY に昇格:

• リポジトリが対応スタックを明確に使用
• コンポーネントが毎セッションで役立つほど汎用的
• リポジトリが対応するランタイムまたはワークフローに既に依存

以下の場合に LIBRARY に降格:

• コンポーネントがスタック外
• リポジトリが後で必要になるかもしれないが、毎日ではない
• 直接的な関連性なくコンテキストオーバーヘッドを追加

4. インストールプランを構築する

分類をアクションに変換します:

• DAILY スキル -> .claude/skills/ にインストールまたは保持
• DAILY コマンド -> 有用であれば明示的なシムとして保持
• DAILY ルール -> マッチする言語セットのみインストール
• DAILY フック/スクリプト -> 互換性のあるもののみ保持
• LIBRARY サーフェス -> 検索または skill-library を通じてアクセス可能に保つ

リポジトリが既に選択的インストールを使用している場合、別のシステムを作成せず、既存のプランを更新します。

5. オプションのライブラリルーターを作成する

プロジェクトが検索可能なライブラリサーフェスを希望する場合、以下を作成します:

• .claude/skills/skill-library/SKILL.md

このルーターには以下を含めます:

• DAILY と LIBRARY の簡潔な説明
• グループ化されたトリガーキーワード
• ライブラリリファレンスの所在

ルーター内にすべてのスキル本体を重複させないでください。

6. 結果を検証する

プラン適用後、以下を検証します:

• DAILY ファイルすべてが期待される場所に存在
• 古い言語ルールがアクティブなまま残されていない
• 互換性のないフックがインストールされていない
• 結果のインストールが実際にリポジトリスタックにマッチする

以下を含むコンパクトレポートを返します:

• DAILY カウント
• LIBRARY カウント
• 除去された古いサーフェス
• 未解決の問い

ハンドオフ

次のステップが対話型インストールまたは修復である場合、以下に引き継ぎます:

• configure-ecc

次のステップが重複クリーンアップまたはカタログレビューである場合、以下に引き継ぎます:

• skill-stocktake

次のステップがより広いコンテキストトリミングである場合、以下に引き継ぎます:

• strategic-compact

出力フォーマット

結果を以下の順序で返します:

STACK
- language/framework/runtime summary

DAILY
- always-loaded items with evidence

LIBRARY
- searchable/reference items with evidence

INSTALL PLAN
- what should be installed, removed, or routed

VERIFICATION
- checks run and remaining gaps