Agent Sort

---
name: agent-sort
description: "通过并行且具备仓库感知的审查过程，将技能、命令、规则、钩子和附加项分类到 DAILY (日常) 与 LIBRARY (库) 桶中，为特定仓库构建有证据支持的 ECC 安装计划。当需要将 ECC 裁剪到项目实际需要的内容，而非加载完整包时使用。"
origin: ECC
---

# 代理分类器 (Agent Sort)

当仓库需要项目特定的 ECC 界面，而非默认的完整安装时，请使用此技能。

目标不是去猜测什么“看起来有用”，而是根据来自实际代码库的证据对 ECC 组件进行分类。

## 何时使用

- 项目只需要 ECC 的子集，而完整安装会带来太多干扰。
- 仓库的技术栈很明确，但没人想一个接一个地手动挑选技能。
- 团队希望得到一个由 grep 证据支持而非基于主观意见的可重复安装决策。
- 需要将始终加载的“日常工作界面 (DAILY)”与可搜索的“库/参考界面 (LIBRARY)”分开。
- 仓库偏离了正确的语言、规则或钩子设置，需要清理。

## 强制规则

- 使用当前仓库作为事实来源，而非通用的偏好设置。
- 每个 DAILY 决策必须引用具体的仓库证据。
- LIBRARY 并不意味着“删除”；它意味着“保留访问权限，但默认不加载”。
- 不要安装当前仓库无法使用的钩子 (Hooks)、规则或脚本。
- 优先使用 ECC 原生界面；不要引入第二套安装系统。

## 输出成果

按顺序生成以下产出：

1. DAILY 清单
2. LIBRARY 清单
3. 安装计划
4. 验证报告
5. 如果项目需要，提供可选的 `skill-library` 路由技能

## 分类模型

仅使用两个桶：

- **DAILY (日常)**
  - 应该在为该仓库开启的每个会话中加载。
  - 与仓库的语言、框架、工作流或操作界面强相关。
- **LIBRARY (库)**
  - 值得保留，但不值得默认加载。
  - 应保持可通过搜索、路由技能或有选择性的手动调用来访问。

## 证据来源

在进行任何分类之前，请使用仓库本地证据：

- 文件扩展名
- 包管理器和锁定文件 (lockfiles)
- 框架配置文件
- CI 和钩子配置
- 构建/测试脚本
- 导入 (imports) 和依赖清单
- 明确描述技术栈的仓库文档

常用的检查命令包括：

```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)**
   - 分类 `agents/*`
2. **技能 (Skills)**
   - 分类 `skills/*`
3. **命令 (Commands)**
   - 分类 `commands/*`
4. **规则 (Rules)**
   - 分类 `rules/*`
5. **钩子与脚本 (Hooks and scripts)**
   - 分类钩子界面、MCP 健康检查、辅助脚本和操作系统兼容性
6. **附加项 (Extras)**
   - 分类上下文 (Contexts)、示例、MCP 配置、模板和指导文档

如果子代理不可用，请按顺序执行这些阶段。

## 核心工作流

### 1. 读取仓库信息

在分类任何内容之前，确定真实的技术栈：

- 正在使用的语言
- 正在使用的框架
- 主要的包管理器
- 测试工具栈
- 代码检查/格式化工具栈
- 部署/运行时界面
- 已经存在的操作集成

### 2. 构建证据表

为每个候选组件记录：

- 组件路径
- 组件类型
- 建议归属的桶
- 仓库证据
- 简短理由

使用此格式：

```text
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 还是 LIBRARY

在以下情况下提升至 `DAILY`：

- 仓库明确使用了匹配的技术栈。
- 该组件足够通用，能为每个会话提供帮助。
- 仓库已经依赖于相应的运行时或工作流。

在以下情况下降级至 `LIBRARY`：

- 该组件不属于当前技术栈。
- 仓库以后可能会用到，但不是每天都用。
- 它增加了上下文开销，但没有即时的相关性。

### 4. 构建安装计划

将分类转化为行动：

- DAILY 技能 -> 安装或保留在 `.claude/skills/` 中。
- DAILY 命令 -> 仅在仍有用时保留为显式填充。
- DAILY 规则 -> 仅安装匹配的技术栈。
- DAILY 钩子/脚本 -> 仅保留兼容的项。
- LIBRARY 组件 -> 保持可通过搜索或 `skill-library` 访问。

如果仓库已经使用了选择性安装，请更新该计划而非创建另一套系统。

### 5. 创建可选的库路由 (Library Router)

如果项目需要一个可搜索的库界面，请创建：

- `.claude/skills/skill-library/SKILL.md`

该路由技能应包含：

- 对 DAILY 与 LIBRARY 的简短解释。
- 分组的触发关键字。
- 库参考资料的存放位置。

不要在路由技能中复制每个技能的具体正文内容。

### 6. 验证结果

应用计划后，验证：

- 每个 DAILY 文件都存在于预期位置。
- 过时的语言规则未被激活。
- 未安装不兼容的钩子。
- 最终的安装确实匹配仓库技术栈。

返回一份简洁的报告，包含：

- DAILY 组件数量
- LIBRARY 组件数量
- 已移除的过时界面
- 待解决的问题

## 任务移交

如果下一步是交互式安装或修复，移交给：

- `configure-ecc`

如果下一步是重复项清理或目录审查，移交给：

- `skill-stocktake`

如果下一步是更广泛的上下文裁剪，移交给：

- `strategic-compact`

## 输出格式

按以下顺序返回结果：

```text
STACK (技术栈)
- 语言/框架/运行时总结

DAILY (日常)
- 始终加载的项及其证据

LIBRARY (库)
- 可搜索/参考的项及其证据

INSTALL PLAN (安装计划)
- 应该安装、移除或路由的内容

VERIFICATION (验证)
- 已执行的检查和剩余差距
```