Agent Sort

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

目標は「便利そうに思える」ものを推測することではなく、実際のコードベースからの証拠を使用して ECC コンポーネントを分類することです。

使用時期

• プロジェクトが ECC の一部のみを必要とし、完全インストールはノイズが多い
• リポジトリのスタックは明確だが、スキルを 1 つずつ手作業で精選したくない
• チームが意見ではなく grep 証拠に基づいた繰り返し可能なインストール決定を望んでいる
• 常時ロードされるデイリーワークフロー サーフェスと検索可能なライブラリ/リファレンス サーフェスを分離する必要がある
• リポジトリが間違った言語、ルール、またはフック セットに漂流していて、クリーンアップが必要である

譲れないルール

• 一般的な環境設定ではなく、現在のリポジトリを情報源として使用する
• すべての DAILY 決定は、具体的なリポジトリ証拠に基づいていなければならない
• LIBRARY は「削除」を意味するのではなく、「デフォルトでロードせずにアクセス可能に保つ」を意味する
• 現在のリポジトリで使用できないフック、ルール、またはスクリプトをインストールしない
• ECC ネイティブ サーフェスを優先し、2 番目のインストール システムを導入しない

成果物

以下のアーティファクトを順序通りに作成します:

1. DAILY インベントリ
2. LIBRARY インベントリ
3. インストール計画
4. 検証レポート
5. プロジェクトが希望する場合はオプションの 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

並列レビュー パス

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

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

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

コア ワークフロー

1. リポジトリを読む

何かを分類する前に、実際のスタックを確立します:

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

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 vs LIBRARY を決定する

以下の場合は DAILY に昇格します:

• リポジトリが明確に一致するスタックを使用している
• コンポーネントがすべてのセッションを支援するのに十分な汎用性がある
• リポジトリが既に対応するランタイムまたはワークフローに依存している

以下の場合は LIBRARY に降格します:

• コンポーネントがスタック外である
• リポジトリが後でそれを必要とするかもしれませんが、毎日ではない
• それが即座の関連性なしにコンテキスト オーバーヘッドを追加する

4. インストール計画を構築する

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

• DAILY スキル -> .claude/skills/ にインストールまたは保持
• DAILY コマンド -> まだ有用な場合はのみ明示的なシムとして保持
• 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
- 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