Agent Sort

エージェントソート

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

目標は「便利そうなもの」を推測することではありません。目標は実際のコードベースからのエビデンスで ECC コンポーネントを分類することです。

使用タイミング

• プロジェクトが ECC のサブセットのみを必要とし、フルインストールがノイズが多すぎる場合
• リポジトリスタックが明確だが、誰もスキルを一つずつ手動でキュレーションしたくない場合
• チームが意見ではなく grep エビデンスに基づく繰り返し可能なインストール決定を望む場合
• 常にロードされる毎日のワークフローサーフェスと検索可能なライブラリ/参照サーフェスを分離する必要がある場合
• リポジトリが間違った言語、ルール、またはフックセットにドリフトし、クリーンアップが必要な場合

非交渉ルール

• 現在のリポジトリを真実の源として使用し、一般的な好みではない
• すべての DAILY 決定は具体的なリポジトリエビデンスを引用すること
• LIBRARY は「削除」を意味しない；「デフォルトでロードせずにアクセス可能に保つ」を意味する
• 現在のリポジトリが使用できないフック、ルール、スクリプトをインストールしない
• ECC ネイティブのサーフェスを優先；2 番目のインストールシステムを導入しない

成果物

この順序で成果物を生成する：

1. DAILY インベントリ
2. LIBRARY インベントリ
3. インストール計画
4. 検証レポート
5. プロジェクトがルーターを望む場合はオプションの skill-library ルーター

分類モデル

2 つのバケットのみを使用する：

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

エビデンスソース

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

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

有用なコマンド：

rg --filesrg -n "typescript|react|next|supabase|django|spring|flutter|swift"cat package.jsoncat pyproject.tomlcat Cargo.tomlcat pubspec.yamlcat go.mod

並行レビューパス

並行サブエージェントが利用可能な場合、レビューをこれらのパスに分割する：

1. エージェント
   • agents/* を分類
2. スキル
   • skills/* を分類
3. コマンド
   • commands/* を分類
4. ルール
   • rules/* を分類
5. フックとスクリプト
   • フックサーフェス、MCP ヘルスチェック、ヘルパースクリプト、OS 互換性を分類
6. エクストラ
   • コンテキスト、例、MCP 設定、テンプレート、ガイダンスドキュメントを分類

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

コアワークフロー

1. リポジトリを読む

何かを分類する前に実際のスタックを確立する：

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

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 か 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- 言語/フレームワーク/ランタイムのサマリー
DAILY- エビデンスを伴う常にロードされるアイテム
LIBRARY- エビデンスを伴う検索可能/参照アイテム
INSTALL PLAN- インストール、削除、またはルーティングすべきもの
VERIFICATION- 実行されたチェックと残っているギャップ