mturac エージェントソート
リポジトリにデフォルトのフルインストールではなく、プロジェクト固有の ecc サーフェスが必要な場合にこのスキルを使用します。
目標は「便利そうなもの」を推測することではありません。目標は実際のコードベースからのエビデンスで ecc コンポーネントを分類することです。
使用タイミング
- プロジェクトが ecc のサブセットのみを必要とし、フルインストールがノイズが多すぎる場合
- リポジトリスタックが明確だが、誰もスキルを一つずつ手動でキュレーションしたくない場合
- チームが意見ではなく grep エビデンスに基づく繰り返し可能なインストール決定を望む場合
- 常にロードされる毎日のワークフローサーフェスと検索可能なライブラリ/参照サーフェスを分離する必要がある場合
- リポジトリが間違った言語、ルール、またはフックセットにドリフトし、クリーンアップが必要な場合
非交渉ルール
- 現在のリポジトリを真実の源として使用し、一般的な好みではない
- すべての DAILY 決定は具体的なリポジトリエビデンスを引用すること
- LIBRARY は「削除」を意味しない；「デフォルトでロードせずにアクセス可能に保つ」を意味する
- 現在のリポジトリが使用できないフック、ルール、スクリプトをインストールしない
- ecc ネイティブのサーフェスを優先；2 番目のインストールシステムを導入しない
成果物
この順序で成果物を生成する：
- 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. リポジトリを読む
何かを分類する前に実際のスタックを確立する：
- 使用中の言語
- 使用中のフレームワーク
- 主要なパッケージマネージャー
- テストスタック
- 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 スキル ->
.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
出力フォーマット
この順序で結果を返す：
STACK
- 言語/フレームワーク/ランタイムのサマリー
DAILY
- エビデンスを伴う常にロードされるアイテム
LIBRARY
- エビデンスを伴う検索可能/参照アイテム
INSTALL PLAN
- インストール、削除、またはルーティングすべきもの
VERIFICATION
- 実行されたチェックと残っているギャップ