跳到主要内容

第 3 章：内容模型——六种资产如何分工

ECC 的可维护性来自“同一个概念只在一个层里拥有权威”。最重要的六种内容资产如下：

资产载体典型消费者解决的问题
Agentagents/*.md委派/子 agent角色、工具权限、模型偏好、任务边界
Skillskills/*/SKILL.md主 Agent 按需加载一套可复用的工作流和领域知识
Commandcommands/*.mdslash command / 兼容入口用户触发的快捷入口，逐步迁移到 skills-first
Rulerules/<pack>/*.md宿主规则加载器始终遵守的编码、安全、测试约束
Hookhooks/hooks.json + scripts/hooks/宿主生命周期在工具/会话边界执行自动化和阻断
Adapter.claude*、.codex* 等各 harness把共同资产翻译成宿主可识别的形态

“知道”与“执行”的边界​

一个实用判断：如果内容是在告诉模型“遇到 X 时采取 Y 步骤”，它更像 skill；如果要在模型有机会决定之前阻止动作，它应该进入 hook；如果所有会话都应无条件知道，它才适合 rule；如果它是一个可被用户点名触发的工作流入口，可以保留 command。

知识/流程：SKILL.md ──┐
角色/委派：agent.md ───┼→ 模型上下文/委派决策
稳定约束：rules/*.md ──┘

工具边界：hooks.json → scripts/hooks/*.js → allow / warn / block

文件格式是协议​

Agent 与 Skill 都以 Markdown 为主，但 frontmatter 并非装饰。Agent 的 frontmatter 至少表达 name、description、可用 tools 和 model；Skill 的 name、description、metadata.origin 让 catalog、安装器和运行时能够识别它。

---
name: planner
description: Expert planning specialist for complex features and refactoring.
tools: Read, Grep, Glob
model: opus
---

这也是为什么新增能力应该复制现有模板，而不是在 commands/ 里随便放一个 Markdown。文件名、frontmatter 和目录位置共同构成发现协议。

Canonical 与兼容副本​

README、AGENTS.md 和 skills/ecc-guide/SKILL.md 都指向同一事实：skills/ 是长期 canonical workflow surface，commands/ 是向后兼容的 slash-entry surface。于是：

  • 新工作流优先放到 skills/<id>/SKILL.md。
  • 仍需要 /tdd 这类用户入口时，commands/ 保留轻量 shim。
  • 跨 harness 的适配文件不应重新复制一套规则正文，而应引用或投影共同来源。

设计取舍​

这种“文件即 API”的设计牺牲了强类型统一性，却获得了三个好处：模型和人都能直接阅读；社区可以通过 PR 增加能力；不同 harness 可以只加载自己支持的部分。代价也明显：frontmatter 漂移、引用失效和重复能力会成为主要维护成本，所以 ECC 需要 catalog、harness-audit、skills-health 和测试来守住协议。

源码定位​