ECC Agent Sort：用证据驱动的 DAILY/LIBRARY 分类为仓库生成精准安装计划

ECC（Everything Claude Code）自带数百个 skills、commands、rules 与 hooks，直接全量安装会给上下文带来大量与当前项目无关的噪声。Agent Sort 是 ECC 内置的一个"安装规划"技能：它不靠主观感觉挑选组件，而是要求以当前仓库的文件扩展名、包管理器清单、框架配置等客观证据为唯一依据，将 ECC 组件划分进 DAILY（每个会话都加载）与 LIBRARY（保留但默认不加载）两个桶，并产出一份可验证的安装计划。读完本文，你可以掌握这套"读仓库—建证据表—分类—出计划—验证"的完整流程，并了解其产出如何与 ECC 2.0 的选择性安装体系（profiles、modules、install-state）对接。

这个技能解决什么问题

ECC 仓库的组件面非常宽：skills/ 下有数百个技能目录，rules/ 按语言拆成 typescript、python、golang 等十余个子目录，commands/、hooks/、contexts/、examples/ 各自独立。manifests/install-modules.json 甚至把 full 这个 profile 定义为包含 26 个模块的完整安装（见 manifests/install-profiles.json）。对于一个只写 Next.js + TypeScript 的项目，全量安装意味着把 Swift、Django、Rust 相关的规则和技能全部加载进上下文。

Agent Sort 的定位在 SKILL.md 开头说得很直白：

Use this skill when a repo needs a project-specific ECC surface instead of the default full install. The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.

即：目标不是猜"什么看起来有用"，而是用真实代码库里的证据做分类。

适用场景（继承自原文档 "When to Use" 一节）：

• 项目只需要 ECC 的一个子集，全量安装太吵；
• 仓库技术栈清晰，但没有人愿意手工逐个筛选技能；
• 团队希望得到一个"由 grep 证据支撑"的、可重复执行的安装决策，而不是基于个人意见的结论；
• 需要把"每次会话都加载的日常工作面"与"可搜索的库/参考面"分开；
• 仓库已经漂移到了错误的语言/规则/hooks 集合，需要清理。

两条不可妥协的原则

原文档 "Non-Negotiable Rules" 一节给出五条硬约束，是整个方法论的护栏：

1. 以当前仓库为唯一事实来源，而不是通用偏好（"Use the current repository as the source of truth, not generic preferences"）；
2. 每一条 DAILY 决策都必须引用具体的仓库证据——没有证据就不能升级进 DAILY；
3. LIBRARY 不等于"删除"，而是"保留可访问但默认不加载"；
4. 不要安装当前仓库用不上的 hooks、rules 或脚本；
5. 优先使用 ECC 原生安装面，不要引入第二套安装系统。

第 5 条与 ECC 的架构取向一致：ECC 已有基于 manifests 的选择性安装管线（见 docs/SELECTIVE-INSTALL-ARCHITECTURE.md），Agent Sort 的产出应当喂给这套原生管线，而不是再造一套并行的安装机制。

分类模型：只有两个桶

Agent Sort 刻意把分类空间压缩到最小——只用两个桶：

• DAILY
  • 该仓库的每个会话都应加载的组件；
  • 与仓库的语言、框架、工作流或运维面强匹配。
• LIBRARY
  • 值得保留，但默认加载不值得；
  • 应通过搜索、路由器技能（router skill）或手动选择性使用来保持可达。

不引入"灰色地带"或第三档，是为了让安装计划可以直接翻译成动作：DAILY 对应"装进默认加载路径"，LIBRARY 对应"留在仓库里供检索"。这种二值模型也天然适配后文的 skill-library 路由器设计。

证据来源与证据采集命令

在做任何分类之前，必须先采集仓库本地证据。原文档列出的七类证据来源：

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

配套的证据采集命令（可直接复制执行）：

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

这套命令覆盖了 Node/Python/Rust/Dart/Go 五大生态的清单文件，rg --files 则提供扩展名分布的全量视图。以 ECC 仓库自身为例，执行同样的采集就能看到 package.json、pyproject.toml、ecc2/Cargo.toml、scripts/*.js、src/llm/*.py 共存——它本身就是一个多语言仓库，恰好可以演示一个"证据混杂"的真实案例。

六个并行审查通道

分类阶段把 ECC 的全部组件面拆成六个审查通道（review passes）。如果运行环境支持并行子代理（subagents），六个通道可以并行执行；不支持时按顺序执行同样的通道：

通道	分类对象	对应 ECC 仓库目录
1. Agents	代理定义	agents/*
2. Skills	技能	skills/*
3. Commands	斜杠命令	commands/*
4. Rules	语言/框架规则	rules/*
5. Hooks 与脚本	hook 面、MCP 健康检查、辅助脚本、OS 兼容性	hooks/*、scripts/hooks/*
6. Extras	contexts、examples、MCP 配置、模板与指导文档	contexts/*、examples/*、mcp-configs/*

这六个通道与 ECC 仓库的实际目录布局一一对应：仓库顶层就有 agents/、skills/、commands/、rules/、hooks/、contexts/、examples/、mcp-configs/，所以通道划分不是抽象划分，而是可以直接落地的文件遍历。

从源码结构看，通道 5（Hooks 与脚本）是最需要"兼容性审查"的：manifests/install-modules.json 中 hooks-runtime 模块声明的 targets 只有 claude、claude-project、cursor、opencode、codebuddy，而 rules-core 的 targets 覆盖到 zed、qwen、hermes 等十余种 harness。也就是说同一批 hooks 在不同 harness 上可用面不同，分类时必须结合目标 harness 判断"当前仓库/环境能不能用"。

核心工作流六步

第 1 步：读懂仓库，先定技术栈

在分类任何组件之前，先把真实技术栈写清楚，覆盖七个维度：

• 使用的语言；
• 使用的框架；
• 主要包管理器；
• 测试栈；
• lint/格式化栈；
• 部署/运行时面；
• 已存在的运维集成。

这一步的产出就是后文输出格式中 STACK 段落的内容。跳过这一步直接分类，就是把"通用偏好"混进了"仓库证据"，违反第一条硬约束。

第 2 步：建立证据表

对每个候选组件，记录五个字段：

• 组件路径（component path）；
• 组件类型（component type）；
• 建议桶（proposed bucket）；
• 仓库证据（repo evidence）；
• 简短理由（short justification）。

原文档给出的证据表格式（可原样复用）：

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

注意"证据"列全部是可复核的客观事实：文件计数、配置文件存在性、清单文件缺失。rg --files | grep -c '\.tsx$' 这类命令随时可以复跑验证，这正是"由 grep 证据支撑的决策"的含义。

第 3 步：判定 DAILY 还是 LIBRARY

升级进 DAILY 的条件（三条需同时成立）：

• 仓库明确使用了匹配的技术栈；
• 该组件足够通用，对每个会话都有帮助；
• 仓库已经依赖对应的运行时或工作流。

降级到 LIBRARY 的条件：

• 组件偏离当前技术栈；
• 仓库"以后可能需要，但不是每天需要"；
• 它只会增加上下文开销而没有即时相关性。

这里的隐性逻辑是上下文成本意识：ECC 官方对"能力放在哪个面"有同样的成本偏向，docs/capability-surface-selection.md 在比较两种可行方案时要求"偏好更小的运行时面、更低的 token 开销、更少的外部活动部件"。DAILY/LIBRARY 的二分法就是把这个原则从"能力面选择"搬到了"安装面选择"上。

第 4 步：生成安装计划

把分类结果翻译成动作：

• DAILY skills → 安装或保留在 .claude/skills/；
• DAILY commands → 仅当仍然有用时保留为显式 shim（ECC 仓库自身就维护着一层旧命令垫片，见 legacy-command-shims/，其中包含 agent-sort 的垫片命令）；
• DAILY rules → 只安装匹配语言集合（例如纯 TS 仓库只装 rules/typescript/ 与 rules/common/）；
• DAILY hooks/scripts → 只保留兼容的；
• LIBRARY 面 → 通过搜索或 skill-library 路由器保持可达。

原文档还强调：如果仓库已经在用选择性安装，应该去更新那套既有计划，而不是再建一套系统——这与硬约束第 5 条呼应。落到 ECC 2.0 的实现上，"既有计划"通常就是 manifests/install-profiles.json 中的 profile 加 manifests/install-modules.json 中的模块组合。当前 profiles 一共七个：minimal、opencode、core、developer、security、research、full。例如 minimal 明确"没有 hook 运行时"（modules 只有 rules-core、agents-core、commands-core、platform-configs、workflow-quality），而 opencode profile 的注释写明它刻意排除 hooks-runtime，"opt in with --modules hooks-runtime"——这正是 DAILY/LIBRARY 思路在 profile 层面的落地：排除不是删除，是显式 opt-in。

Agent Sort 的产出与安装计划之间还有一条只读预览管线：node scripts/install-plan.js 可以在不改动任何目标的前提下解析 profile 或模块组合，支持 --profile <name>、--modules <id,...>、--with <component>、--skills <ids>、--without <component>、--target <target>、--json 等参数（见 scripts/install-plan.js 的 help 文本与参数解析逻辑，底层解析能力来自 scripts/lib/install-manifests.js）。用它可以把"证据表里得出的模块选择"翻译成一份机器可读的计划，再交给 install-apply 执行。

模块目录本身的结构也值得说明：每个模块有 id、kind、description、paths、targets、dependencies、defaultInstall、cost（light/medium）、stability 等字段（对照 schemas/install-modules.schema.json）。其中 cost 字段与 Agent Sort 的"上下文开销"判据直接相关——hooks-runtime 是 medium、rules-core 是 light，分类时可以作为开销维度的辅助证据。

第 5 步：可选的 skill-library 路由器

如果项目希望保留一个"可搜索的库面"，创建 .claude/skills/skill-library/SKILL.md 路由器。路由器只放三样东西：

• DAILY vs LIBRARY 的简短说明；
• 分组的触发关键词（grouped trigger keywords）；
• 库内容实际存放的位置。

原文档特别警告：不要把每个 skill 的正文复制进路由器。路由器是索引，不是副本——复制正文既浪费上下文，又会在技能更新后产生两份漂移的文档。

第 6 步：验证并输出报告

计划应用之后必须验证四件事：

• 每个 DAILY 文件都存在于预期位置；
• 没有遗留过期的语言规则仍然激活（例如 TS 仓库里的 Python 规则）；
• 没有安装不兼容的 hooks；
• 最终安装面与仓库技术栈一致。

验证完成后返回一份紧凑报告，包含四个字段：DAILY 数量、LIBRARY 数量、已移除的过期面、遗留的开放问题（open questions）。"开放问题"这一项很关键：它承认证据不可能完备，把判断不了的部分显式留出来，而不是强行塞进某个桶。

标准输出格式

Agent Sort 要求结果按固定顺序返回，这也是它对下游消费者（人或脚本）做出的接口契约：

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

这个"证据随结论一起输出"的格式，使得每个 DAILY 条目都可以被独立审计：读者不需要重跑整个流程，只需要复核"证据"列引用的文件是否真的存在、计数是否对得上。

技能在 ECC 体系中的位置与交接

Agent Sort 不是一个孤立流程，它在 ECC 的技能编排中有明确的上下游交接（Handoffs）：

• 下一步如果是交互式安装或修复 → 交给 configure-ecc（skills/configure-ecc/SKILL.md）；
• 下一步如果是重叠清理或目录盘点 → 交给 skill-stocktake（skills/skill-stocktake/SKILL.md）；
• 下一步如果是更大范围的上下文裁剪 → 交给 strategic-compact（skills/strategic-compact/SKILL.md）。

这条链路体现了 ECC 的一个分工思路：Agent Sort 负责决策（装什么、不装什么、为什么），configure-ecc 负责执行（交互式安装/修复），skill-stocktake 负责盘点（重叠与冗余），strategic-compact 负责压缩（已安装内容的上下文裁剪）。决策与执行分离，且决策必须带证据，是整个体系可审计性的来源。

从仓库的工程化配置看，该技能还有两类配套事实可以引用：

• 技能本体同时存在于 skills/agent-sort/SKILL.md（带 metadata.origin: ECC）与 .agents/skills/agent-sort/SKILL.md（供 harness 直接加载的副本）两处，前者多出 frontmatter 中的 metadata 字段，其余内容一致；
• .agents/skills/agent-sort/agents/openai.yaml 声明了其接口元数据：显示名 "Agent Sort"、短描述 "Evidence-backed ECC install planning"，并且 allow_implicit_invocation: true，意味着 harness 可以在任务匹配时无需显式点名而隐式调用它；CI 侧有 tests/ci/agent-yaml-surface.test.js 这类测试覆盖该 surface 的一致性。

适用前提与限制

使用 Agent Sort 时需要明确以下前提：

• 它面向的是"已经决定采用 ECC、但想裁剪安装面"的场景，对没有 ECC 组件的仓库没有作用对象；
• 证据采集命令默认面向 rg（ripgrep）可用环境，cat 清单文件假设对应生态的清单文件存在，缺哪个就少一类证据；
• DAILY 建议默认以 .claude/skills/ 为 Claude Code 的落点表述，其他 harness（Cursor、Codex、OpenCode 等）的落点由 ECC 的 target 适配器体系决定（可参考 docs/SELECTIVE-INSTALL-ARCHITECTURE.md 中 claude-home、cursor-project、antigravity-project 等适配器设计），分类结论本身与 harness 无关，落点映射在生成安装计划时再处理；
• 证据表中的"文件计数""配置存在性"是可复核证据，但"该组件是否通用到每个会话都有用"仍含模型判断——这正是输出格式保留 open questions 的原因。

小结

Agent Sort 把"给这个项目装多少 ECC"从一个凭感觉的选择题，改造成一个可审计的证据链流程：先用 rg --files、清单文件、CI 配置建立技术栈事实，再对 agents/skills/commands/rules/hooks/extras 六个通道逐一产出带证据的 DAILY/LIBRARY 分类，随后翻译成与 ECC 原生 profiles/modules 体系兼容的安装计划，最后用四项检查加紧凑报告收尾。它的核心价值不在于"更省"，而在于每个安装决定都能回答'为什么'——证据列里引用的每一个文件，都可以被团队成员独立复核。