Distilling Lessons Into Assets

distilling-lessons-into-assets —— 经验该落成哪种资产、怎么落

一条候选经验摆在你面前:它可能该写进一份纪律文档、该长成一个新 skill、该固化成一段确定性 workflow、或 该配一个专职 subagent——选错归宿,这条经验要么被淹没、要么被滥用、要么干脆无人再看。本 skill 承载的是 这一步路由判断的品味,不是任何具体项目的执行流程(执行流程归调用你的那个命令/工作流本身)。

四类资产判据速查

| 资产类型 | 适合承载 | 不适合承载 | |---|---|---| | 纪律文档(项目的 AGENTS.md / CONTRIBUTING / 设计文档一类主纪律载体) | 一次性但意义持久的事实、项目专属的红线或惯例、需要一句 why 才站得住的具体约束 | 需要被反复不同任务触发调用的可迁移判断力——判断力埋进线性文档会被读者错过 | | skill(带触发描述、可被独立调用的判断力/方法论文档) | 可复用到其他任务的判断力或方法论、需要专门触发描述、压力下容易被合理化因而需要纪律型 body 的规则 | 一次性事实(该进纪律文档)、纯确定性机制形状(该进 workflow) | | workflow(确定性编排脚本) | 确定性的编排/并行形状本身(先做什么、并行还是串行、怎么 fan-out) | 需要临场判断力的决策点——判断力应留给触发它的 agent,不要把决策塞进脚本里 | | subagent(角色化的专职人格定义) | 需要独立 persona + 独立工具/上下文边界、会被反复以同一角色调用的专职分工 | 一次性任务委托——用普通派发即可,不必新建一个命名 subagent 定义 |

归宿判断决策树(顶层三问,细节见 [references/routing-decision-tree.md](references/routing-decision-tree.md))

1. 这条经验的本质是事实还是判断力? 事实(这次因为具体原因踩了坑,下次注意这件具体的事)→ 纪律文档;

判断力(一套可迁移到其他任务的决策方法/品味)→ 继续第 2 问。

1. 这条判断力是确定性可编排的机制形状吗(无需临场判断,纯结构)? → workflow;否则继续第 3 问。
2. 这条判断力需要角色化的专职视角吗(独立 persona + 工具边界,会被反复以同一角色调用)? → subagent;

否则 → skill。

二义性(同一条经验既该在纪律文档留一句指针、又该在 skill 里承载细节)与"三问都判不清"的兜底处理,细节都在 [references/routing-decision-tree.md](references/routing-decision-tree.md)——核心纪律:归宿不确定或基础 设施缺失时,绝不静默丢弃这条经验;找不到理想归宿就落成本最低的纪律文档指针,并显式标注"归宿不确定"或 "该项目无对应基础设施,已降级",留给人工审阅时改判。宁可归宿判浅了被人工纠正,也不能让一条经验凭空消失。

唯一硬约束:证据忠实性(存在性声明,细则见 references/evidence-fidelity.md)

从候选内容草稿写进目标资产的这一步,不允许发生任何脱离原始证据的改写或泛化。 措辞收不住时,你要做的是 收窄回证据能支持的范围(保留场景限定词),而不是把它写得更通用、更"放之四海而皆准"。发现候选草稿本身 已经泛化过头,也不是照抄了事——按证据范围收窄,并显式注明"已收窄:原候选草稿过度泛化,落地时按证据范围 收窄为…"。这条红线的判断细则、"泛化 vs 收窄"的对照例子,都在 [references/evidence-fidelity.md](references/evidence-fidelity.md)。

落地手艺与反模式

每类资产的具体落地手艺(文风套用、frontmatter/触发描述写法、workflow 脚本纪律、subagent persona 边界)与 一张 Rationalization Table(你会怎么对自己说、现实是什么),都在 [references/landing-craft-by-asset-type.md](references/landing-craft-by-asset-type.md)。四类资产共享的 一条元反模式先摆在这里:"这条经验挺重要的,得进 skill 才够重"是本 skill 要堵的头号自我说服——重要 不等于可复用判断力,重要的一次性事实老实进纪律文档更合适。

边界:与其他判断力不重叠

• 不是代码工程手艺判断——本 skill 管"一条经验该归属哪类资产、以及落地到该资产时的品味",不涉及"领域

该怎么建模 / 类该怎么写 / 要不要先写规格再实现"这类代码本身的设计判断,那是另一个专管工程手艺的判断力。

• 不是目标分解方法论——本 skill 的输入是候选经验清单,不是待完成的目标;把一个目标切成任务依赖图是

完全不同的输入输出形态。

• 不是任务执行循环心智——本 skill 不涉及"接手一个任务怎么迭代推进到验收"的执行侧循环,那是另一件事。
• 不是资产落地机制本身的操作手册——若归宿判定落在"某种带命令行的状态载体"上,本 skill 只管"该不该

往那里写、写什么",不教"具体命令怎么敲"——命令怎么敲去读那个载体自己的操作手册。

• 不是"这个能力要不要独立成一个新 skill"的治理判断——那是只服务本项目维护者、且假设读者对本项目

内部结构了如指掌的治理层判断,与"经验→资产"这个面向任意目标项目的落地判断不是同一件事、也不是同一批 读者。若一条候选经验判定该落成 skill、且遇到"该新建 skill 还是塞进既有 skill 的一节"这类治理分歧,把 这个二级问题转交给项目自己的 skill 治理规范(若存在),本 skill 到此为止。

Pointers

• [references/asset-taxonomy.md](references/asset-taxonomy.md) —— 四类资产各自"适合承载什么性质的经验"

的完整定义 + 判据,速查表的展开版。

• [references/routing-decision-tree.md](references/routing-decision-tree.md) —— 完整决策树(含二义性 /

多归宿路由 / 不确定兜底)。

• [references/landing-craft-by-asset-type.md](references/landing-craft-by-asset-type.md) —— 每类资产的

落地手艺 + 完整 Rationalization Table。

• [references/evidence-fidelity.md](references/evidence-fidelity.md) —— 证据忠实性硬约束的判断细则:何为

"脱离证据的泛化"、怎么收窄措辞、"绝不静默丢弃"具体怎么落地。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: nemori-ai
• Source: nemori-ai/cc-master
• License: MIT

Install and usage instructions live in the source repository linked above.