agent-sort

name	agent-sort
description	通过将技能、命令、规则、钩子和额外内容并行进行仓库感知审查，为特定仓库构建基于证据的 ECC 安装计划，将其分为 DAILY 和 LIBRARY 两类。当 ECC 应精简为项目实际所需而非加载完整包时使用。
origin	ECC

技能分类

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

目标不是猜测"什么感觉有用"。目标是根据实际代码库中的证据对 ECC 组件进行分类。

何时使用

• 项目只需要 ECC 的子集，完整安装过于嘈杂
• 仓库技术栈明确，但无人希望逐个手动筛选技能
• 团队希望获得基于 grep 证据而非主观意见的可重复安装决策
• 需要将始终加载的日常工作流表面与可搜索的库/参考表面分离
• 仓库已偏离至错误的语言、规则或钩子集，需要清理

不可协商的规则

• 以当前仓库为事实来源，而非通用偏好
• 每个 DAILY 决策必须引用具体的仓库证据
• LIBRARY 并不意味着"删除"；它意味着"保持可访问但不默认加载"
• 不要安装当前仓库无法使用的钩子、规则或脚本
• 优先使用 ECC 原生表面；不要引入第二个安装系统

输出

按顺序生成以下工件：

1. DAILY 清单
2. LIBRARY 清单
3. 安装计划
4. 验证报告
5. 可选的路由器（如果项目需要）

分类模型

仅使用两个分类：

• DAILY
  • 应为该仓库的每个会话加载
  • 与仓库的语言、框架、工作流或操作者表面强匹配
• LIBRARY
  • 保留有用，但不值得默认加载
  • 应通过搜索、路由器技能或选择性手动使用保持可访问

证据来源

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

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

有用的命令包括：

rg --files
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
cat package.json
 pyproject.toml
 Cargo.toml
 pubspec.yaml
 go.mod