Agent Sort は何をしますか？
このスキルは、リポジトリにプロジェクト固有のECC表面が必要で、デフォルトのフルインストールが適さない場合に使用します。
目標は「便利そう」と推測することではありません。目標は、実際のコードベースから得られた証拠に基づいてECCコンポーネントを分類することです。
使用するタイミング
- プロジェクトがECCのサブセットのみを必要とし、フルインストールではノイズが多すぎる場合
- リポジトリのスタックは明確だが、誰も手動でスキルを1つずつ厳選したくない場合
- チームが意見ではなくgrepによる証拠に基づいた、再現可能なインストール判断を望む場合
- 常時読み込む日常ワークフロー表面と、検索可能なライブラリ/リファレンス表面を分離する必要がある場合
- リポジトリの言語、ルール、フックセットが本来のものからずれており、クリーンアップが必要な場合
不可避のルール
- 一般論ではなく、現在のリポジトリを真実の情報源として使用すること
- すべての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ファイル、next.config.tsが存在 | コアフロントエンドスタック
skills/django-patterns | skill | LIBRARY | .pyファイルなし、pyproject.tomlなし | このリポジトリではアクティブではない
rules/typescript/* | rules | DAILY | package.json + tsconfig.json | アクティブなTSリポジトリ
rules/python/* | rules | LIBRARY | Pythonソースファイルがゼロ | アクセス可能な状態でのみ保持
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
- 実行されたチェックと残っているギャップ