[Skills-08] 从废弃 Skill 看演化：四个被吸收的工作流

Deprecated 不等于没有价值。相反，废弃目录能展示 skill 如何随实践演化：有用的原则被保留，过窄的入口或重复的流程被更通用 skill 吸收。本篇覆盖仓库中的全部四个 deprecated skill。

1. design-an-interface：Design It Twice 的早期独立版本#

这个 skill 源自 John Ousterhout 的 Design It Twice：第一个 interface 很少是最优解，因此并行生成至少三种“根本不同”的设计，再比较。

流程是：

1. 先确定 caller、operations、constraints 与要隐藏的复杂度；
2. 给多个 sub-agent 不同优化方向，例如最少 method、最大 flexibility、common case 优先；
3. 每个方案展示 signature、usage、隐藏内容和 trade-off；
4. 按 interface simplicity、generality、implementation efficiency、depth、误用风险比较；
5. 与用户合成最终方向，但不实施。

它被废弃后，核心方法没有消失，而是进入 codebase-design/DESIGN-IT-TWICE.md，成为设计深模块时的一个分支。这样 vocabulary 与设计流程只有一份事实来源，也避免一个 model-invoked skill 额外占用路由上下文。

2. qa：从“边聊边报 bug”演化到统一 triage#

QA skill 让用户自然描述故障，Agent 每次最多问 2-3 个澄清问题，同时在后台探索代码库理解 domain language，随后直接用 gh issue create 建 issue。

Issue 强调 durable behavior：

• What happened / What I expected；
• 可重复的 steps；
• 相关用户语境；
• 不写脆弱 file path 和 line number。

复杂报告会拆成多个 thin issue，并明确 blocking relationship，以便多人并行。

这些优点后来进入更完整的 triage：不仅接收 bug，也处理 enhancement 和外部 PR；不仅建 issue，还验证 claim、检查是否已实现、查询 prior rejection，并通过状态机决定 ready-for-agent、needs-info 或 wontfix。QA 的“会话式录入”是一个入口，而 triage 管理的是整个请求生命周期。

3. request-refactor-plan：从小提交计划演化到通用交付图#

早期 refactor skill 会：让用户长述问题、核对代码现状、讨论替代方案、确认范围与测试，再按 Martin Fowler 的建议切成非常小且始终保持程序工作的 commits，最后生成 GitHub issue。

Issue 中记录 Problem、Solution、Commits、Decision Document、Testing Decisions、Out of Scope，并避免具体路径和代码片段。

它的问题是把“需求澄清、规格、拆票、实现策略”压在一个只服务 refactor 的流程里。现在这些职责分别由 grill-with-docs、to-spec、to-tickets 和 tdd 承担。

对于跨全仓库的机械 refactor，to-tickets 还发展出更清楚的 expand-contract 模型：先兼容新旧形式，分批迁移，最后删除旧形式。它比提前规划一长串 commit 更适合 issue tracker 和并行 Agent。

4. ubiquitous-language：从一次性提取演化到持续 domain modeling#

这个 skill 扫描 conversation 中的领域 noun、verb 和 concept，找出：

• 同词多义；
• 多词同义；
• vague 或 overloaded term。

然后生成 UBIQUITOUS_LANGUAGE.md：按 subdomain 分组的 glossary table、relationships、example dialogue 与 flagged ambiguities。它要求为同义概念选一个 canonical term，并列出 aliases to avoid。

它的局限是批处理：先聊完，再提取。现在的 domain-modeling 把这件事变成 session 中持续运行的纪律——发现冲突立即指出、用场景压测、与代码交叉验证、决定落地就更新 CONTEXT.md，只在满足门槛时写 ADR。

从一次性生成报告到持续维护模型，是一次重要升级。Domain language 不是文档阶段的副产品，而是所有需求和代码讨论的底层 interface。

5. 废弃不是删除知识，而是降低重复#

四条演化路径很清晰：

Deprecated	有价值的核心	新归属
design-an-interface	多方案对比、深接口	codebase-design reference
qa	行为导向 issue、可复现步骤	triage
request-refactor-plan	小步安全变化、测试决策	grill-with-docs + to-spec + to-tickets + tdd
ubiquitous-language	canonical glossary、歧义检测	domain-modeling

维护 skill 和维护代码一样，需要主动删除重复入口。否则同一个规则在多个 SKILL.md 里漂移，Agent 会因为触发竞争和版本差异变得更不可预测。

判断是否应废弃一个 skill，可以问：

1. 它是否拥有独立 trigger，还是只是另一个 flow 的步骤？
2. 它是否复制了别处的 reference 或模板？
3. 合并后能否保留更清楚的 context pointer？
4. 用户是否仍能从 router 找到这项能力？

好的 skill 集不是只增长不收缩的命令列表，而是一套持续重构的知识架构。

6. 系列收束：41 个文件背后的 8 条原则#

读完整个仓库，可以留下八条比具体命令更耐久的原则：

1. 事实由 Agent 查，决策由人确认；
2. 对话推动工作，持久工件保存状态；
3. 用稳定领域词汇降低长期沟通成本；
4. 按用户行为纵向切片，并显式记录 blocking edges；
5. 超大未知先画 decision map，不要假装已有执行计划；
6. 实现、调试和审查都从可重复反馈信号开始；
7. Interface 是调用者与测试共同使用的 seam；
8. Skill 本身也需要单一事实来源、渐进披露和持续删改。

参考#

• deprecated skills
• design-an-interface
• qa
• request-refactor-plan
• ubiquitous-language