扩展能力：Skill、Hook、MCP、命令与子代理
不要一开始就堆扩展。先手动跑通，再把稳定流程分层沉淀：规则文件放长期约定，命令放常用提示，子代理隔离上下文，Hook 做硬约束，Skill 封装流程，MCP 连接外部系统。
本章目标
- 知道各类扩展分别解决哪类问题。
- 会判断重复任务应该沉淀到哪一层。
- 能避免过早自动化和过度接入 MCP。
先分清六层能力
- 规则文件：每次进项目都该遵守的长期规则。
- 命令 / 提示模板：一段常用提示，一句话触发。
- 子代理：独立上下文、专职职责、并行或 fresh review。
- Hook：动作前后自动运行的确定性脚本，用于格式化、检查、拦截。
- Skill：一套稳定的可复用流程，包含说明、输入输出和必要资产。
- MCP / CLI：连接外部系统和实时上下文，比如 GitHub、设计稿、日志、数据库。
怎么判断放到哪一层
- 每次进项目都要遵守：写进规则文件。
- 一段提示反复要用：做成命令或提示模板。
- 需要独立上下文或专职角色：拆成子代理。
- 希望某个动作确定性发生或被拦住：写 Hook。
- 一套稳定步骤要跨项目复用：做成 Skill。
- 需要外部系统的数据或动作：优先看官方 CLI，再考虑 MCP。
- 只影响当前一次：留在当前 prompt，不要沉淀。
什么时候做成 Skill
CASE
把发布检查沉淀成 Skill
场景
新增或修改 writing MDX 后，每次都要检查同一套字段、入口和生成结果。重复三次后就适合沉淀。
可以这样说
请帮我设计一个发布检查 Skill：新增或修改 writing MDX 后，检查 frontmatter、slug、标签、RSS、sitemap，运行 npm run lint，涉及路由或元数据时运行 npm run build，并输出验证结果和风险。先给 Skill 的 description、输入、输出和步骤，我确认后再创建。验收点
- 流程重复且稳定。
- 输入输出明确。
- 步骤能独立执行。
- 创建前先确认。
Hook、MCP、CLI 不要混用成一团
Hook 解决确定性问题：每次都要跑、每次都要挡。MCP 解决外部上下文问题：让 agent 稳定读取工单、设计、日志或数据库。CLI 则是很多外部系统最省 token 的入口。
- 适合 Hook：编辑后格式化、提交前 lint、禁止改 migrations、拦截危险命令。
- 适合 MCP：Figma、Notion、Jira、数据库、监控、内部知识库。
- 适合 CLI：gh、aws、gcloud、sentry-cli 这类已有成熟命令行工具的系统。
- 先手动跑通：流程不稳定时自动化，只会把错误流程固化。
- 小范围试跑：批量任务先跑 2-3 个样本，再铺开。
自动化要等流程稳定
- 适合自动化：定期总结提交、扫描 CI 失败、生成 release notes、重复分析日志。
- 不适合自动化：目标经常变、需要产品取舍、验证信号不稳定、权限边界不清。
- 无人值守时权限要更窄：只允许必要工具和路径。
- 自动化结果仍要抽查：尤其是会产生提交、PR 或外部动作的流程。
照着做
请判断我这个重复任务应该放在哪里：规则文件、命令、子代理、Hook、Skill、MCP、CLI，还是暂时只写在当前 prompt 里。先问清任务频率、是否需要独立上下文、是否需要确定性自动化、是否依赖外部系统，再给建议。