agent-sort

# エージェントソート リポジトリにデフォルトのフルインストールではなく、プロジェクト固有の ecc サーフェスが必要な場合にこのスキルを使用します。 目標は「便利そうなもの」を推測することではありません。目標は実際のコードベースからのエビデンスで ecc コンポーネントを分類することです。 ## 使用タイミング - プロジェクトが ecc のサブセットのみを必要とし、フルインストールがノイズが多すぎる場合 - リポジトリスタックが明確だが、誰もスキルを一つずつ手動でキュレーションしたくない場合 - チームが意見ではなく grep エビデンスに基づく繰り返し可能なインストール決定を望む場合 - 常にロードされる毎日のワークフローサーフェスと検索可能なライブラリ/参照サーフェスを分離する必要がある場合 - リポジトリが間違った言語、ルール、またはフックセットにドリフトし、クリーンアップが必要な場合 ## 非交渉ルール - 現在のリポジトリを真実の源として使用し、一般的な好みではない - すべての DAILY 決定は具体的なリポジトリエビデンスを引用すること - LIBRARY は「削除」を意味しない；「デフォルトでロードせずにアクセス可能に保つ」を意味する - 現在のリポジトリが使用できないフック、ルール、スクリプトをインストールしない - ecc ネイティブのサーフェスを優先；2 番目のインストールシステムを導入しない ## 成果物 この順序で成果物を生成する： 1. DAILY インベントリ 2. LIBRARY インベントリ 3. インストール計画 4. 検証レポート 5. プロジェクトがルーターを望む場合はオプションの `skill-library` ルーター ## 分類モデル 2 つのバケットのみを使用する： - `DAILY` - このリポジトリのすべてのセッションでロードすべき - リポジトリの言語、フレームワーク、ワークフロー、またはオペレーターサーフェスに強くマッチ - `LIBRARY` - 保持するのに有用だが、デフォルトでロードする価値はない - 検索、ルータースキル、または選択的な手動使用を通じてアクセス可能に維持すべき ## エビデンスソース 分類を行う前にリポジトリローカルのエビデンスを使用する： - ファイル拡張子 - パッケージマネージャーとロックファイル - フレームワーク設定 - CI とフック設定 - ビルド/テストスクリプト - インポートと依存関係マニフェスト - スタックを明示的に説明するリポジトリドキュメント 有用なコマンド： ```bash 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. リポジトリを読む 何かを分類する前に実際のスタックを確立する： - 使用中の言語 - 使用中のフレームワーク - 主要なパッケージマネージャー - テストスタック - lint/フォーマットスタック - デプロイ/ランタイムサーフェス - 既に存在するオペレーター統合 ### 2. エビデステーブルを構築する すべての候補サーフェスについて記録する： - コンポーネントパス - コンポーネントタイプ - 提案されたバケット - リポジトリエビデンス - 短い正当化 このフォーマットを使用する： ```text 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 スキル -> `.codex/skills/` にインストールまたは保持 - DAILY コマンド -> まだ有用な場合のみ明示的なシムとして保持 - DAILY ルール -> 対応する言語セットのみインストール - DAILY フック/スクリプト -> 互換性のあるもののみ保持 - LIBRARY サーフェス -> 検索または `skill-library` を通じてアクセス可能に保つ リポジトリが既に選択的インストールを使用している場合、別のシステムを作成するのではなくその計画を更新する。 ### 5. オプションのライブラリルーターを作成する プロジェクトが検索可能なライブラリサーフェスを望む場合、作成する： - `.codex/skills/skill-library/SKILL.md` そのルーターは含むべき内容： - DAILY と LIBRARY の短い説明 - グループ化されたトリガーキーワード - ライブラリ参照がある場所 ルーター内にすべてのスキル本体を重複させない。 ### 6. 結果を検証する 計画が適用された後、確認する： - すべての DAILY ファイルが期待される場所に存在する - 古い言語ルールがアクティブなままでない - 互換性のないフックがインストールされていない - 結果のインストールが実際にリポジトリスタックと一致する 以下を含むコンパクトなレポートを返す： - DAILY カウント - LIBRARY カウント - 削除された古いサーフェス - 未解決の質問 ## ハンドオフ 次のステップがインタラクティブなインストールまたは修復の場合、ハンドオフ先： - `configure-ecc` 次のステップが重複のクリーンアップまたはカタログレビューの場合、ハンドオフ先： - `skill-stocktake` 次のステップがより広いコンテキストのトリミングの場合、ハンドオフ先： - `strategic-compact` ## 出力フォーマット この順序で結果を返す： ```text STACK - 言語/フレームワーク/ランタイムのサマリー DAILY - エビデンスを伴う常にロードされるアイテム LIBRARY - エビデンスを伴う検索可能/参照アイテム INSTALL PLAN - インストール、削除、またはルーティングすべきもの VERIFICATION - 実行されたチェックと残っているギャップ ```