第 5 章：Skills——ECC 的知识与工作流总线
281 个目录，不是 281 个独立插件
skills/ 更像一个能力 catalog。每个目录通常有一个 SKILL.md，少数 skill 还带 config.json、脚本或运行时资产。按来源可以观察到几类：
- 工程基线：
coding-standards、backend-patterns、api-design。 - 测试与验证：
tdd-workflow、verification-loop、e2e-testing。 - 语言/框架：
python-patterns、react-patterns、django-tdd、rust-testing。 - Agent 工程：
agent-harness-construction、agent-eval、context-budget。 - 研究、内容、运营：
deep-research、market-research、content-engine、github-ops。 - 领域包：医疗、供应链、网络、金融、科学计算和媒体生成等。
目录数量大，但安装器不会默认把所有内容塞进每个会话。profile 和 module 负责选择安装范围，宿主再按发现规则加载具体 skill。这样“能力库很大”和“单次上下文很小”可以同时成立。
一个 Skill 的内部结构
高质量 skill 通常遵循：
frontmatter
↓
When to Activate / When to Use
↓
Prerequisites and safety boundaries
↓
Step-by-step workflow
↓
Examples / commands / output contract
↓
Related skills and verification
以 tdd-workflow 为例，它不只是说“请写测试”，而是定义 runner 检测、用户旅程、RED/GREEN/REFACTOR、覆盖率和验证报告的完整流程。verification-loop 则把 build、typecheck、lint、test、security、diff review 排成可重复的检查阶段。
Skills 如何形成组合
Skill 之间用“互补引用”而不是深层继承组合：
feature request
├─ plan / plan-canvas
├─ tdd-workflow
├─ framework-patterns
├─ verification-loop
└─ security-review
安装器中的 module 依赖与文档中的 skill 引用是两套不同层次：module 依赖保证文件被安装；skill 引用指导模型在会话中继续加载相关能力。前者是机械的，后者是语义的。
Continuous learning 如何改变 Skill 的来源
ECC 的 learning v2 把一次会话里观察到的偏好先记录成原子 instinct，再在 /evolve 或 /promote 后形成 skill、command 或 agent。于是 skill 不再只有“仓库维护者手写”这一种来源：
tool / correction observations
↓
project-scoped instinct
↓ confidence + evidence
cluster / evolve
↓
skill / command / agent
这条链也解释了为什么 continuous-learning-v2 强调项目隔离：React 项目中的局部模式不应自动污染 Python 项目。
Skill 的质量检查点
- 有明确触发条件，不是泛泛而谈的百科文章。
- 命令和路径是当前仓库真实存在的，不引用已退役入口。
- 对外部输入、秘密、破坏性操作和越权请求有防线。
- 输出有可验证的结束条件，能交给 verification loop。
- 与已有 skill 没有大面积重复，或明确说明为什么需要独立存在。