wait-what

1. Bilingual SKILL.md

左右滑动可直接切换英文版与中文版；两种语言按段落自动对齐。英文中的蓝色虚线词语可点击查看解释。共标记 7 处。

Entry SHA-256: e3f44e3ccbc0e7b62f20ba70b295fc9c9f4aa3f96c77168faee1c71bacbf4215

2. Why This Skill Is Clever

一句话核心机制

把“我没跟上”编码成一次显式的会话修复：同一内容必须补足少量前提、换成受控的简明英语，并重新对齐项目已经约定的领域词汇。

触发与调用边界

直接来源： frontmatter 的 disable-model-invocation: true 规定它只能由用户显式触发。正文从 Wait, I don't understand 开始，把触发条件定位在听者已经失去理解，而不是模型自行判断自己的回答太长。

支持背景： agents/openai.yaml 的 allow_implicit_invocation: false 再次确认显式调用边界；官方 docs 给出 /wait-what 入口，并说明它修复当前会话中已经发生的沟通失败。这些文件只用于解释架构，没有被混入上方原文。

解释： 只有用户知道自己在哪一刻停止理解。禁止隐式调用可以避免模型用一个“简化”技能擅自压缩本来已经清楚、但技术上必要的解释。

信息架构与执行顺序

1. Wait 先中断当前解释链，承认理解已经失败。
2. where you've got to here 要求重新交代当前推理位置和缺失前提。
3. Re-pitch that 保留同一个讨论对象，但允许重排 framing、顺序和措辞，禁止只原样复述。
4. a little bit of context 补足理解所需背景，同时给上下文量设置克制边界。
5. ASD-STE100 Simplified Technical English 约束句法和技术表达，使重讲更清晰而非仅仅更短。
6. ubiquitous language from CONTEXT.md 约束名词，使回答回到项目已经共享的领域模型。
7. 如果仓库有多个上下文，CONTEXT-MAP.md 先完成路由，再选择正确的词汇表。

最巧妙的设计点

1. 报告听者状态，而不是给输出贴格式标签

“Wait, I don't understand”

直接来源： 技能不是从 “be concise” 开始，而是明确说理解在这里断裂。

支持背景： docs 把这解释为名称本身就是机制：描述“听者没跟上”会促使模型回退并补前提，而只要求简短可能让模型机械删词。

解释： 这将优化目标从 token 数量改为 comprehension。更短只是可能的手段，恢复共同理解才是验收结果。

2. Re-pitch 阻止无效复读

“Re-pitch that”

直接来源： 动词不是 repeat 或 summarize。它要求围绕同一内容重新组织表达。

解释： 当第一次表达路径已经失败，原样重复只会重现失败；重新 pitch 允许改变入口、例子、顺序和抽象层级，同时保持主题连续性。

3. 三个约束分别修复三类问题

“context ... Simplified Technical English ... ubiquitous language”

直接来源： 一句话同时要求补背景、控制句法，并采用项目词汇。

解释： 背景不足、句子过难、术语漂移是不同故障。只做“简化”会丢前提，只补背景会继续啰嗦，只换词又可能保留错误结构；三者组合形成一个小型修复协议。

4. 给上下文补充设置有意的上限

“a little bit of context”

直接来源： skill 要求一点背景，而不是完整教程。

解释： 这是对过度纠偏的阻尼器。模型需要向后退，但不能把一次澄清扩张成从零开始的长篇讲座，否则技能会制造下一次理解失败。

5. 用映射文件让统一语言在大型仓库中可路由

“follow CONTEXT-MAP.md to the right one”

直接来源： 多 CONTEXT.md 仓库不能默认选择任意一份，必须经映射找到当前语境对应文档。

解释： 统一语言并不意味着全仓只有一个词表。映射层把“共享术语”从硬编码单文件升级为可分域、可扩展的上下文路由。

6. 极短正文与任务性质一致

“Wait ... Re-pitch that”

直接来源： 实际行为被压进一个完整句子，没有步骤清单或输出模板。

支持背景： docs 明确说明三行长度是刻意设计，而不是未完成草稿。

解释： 一个用来修复冗长和理解失败的 corrective 如果自身携带大量规则，会先消耗更多上下文再要求模型简化。这里让触发词和一条可执行约束承担全部工作。

防失败机制与明确不变量

• 必须由用户触发，不允许模型隐式决定何时调用。
• 修复的是刚才没有讲明白的同一内容，不得擅自切换话题。
• 不能只删词：必须补充少量缺失背景。
• 不能继续发明新术语：存在 CONTEXT.md 时必须采用其中的统一语言。
• 多上下文仓库必须经过 CONTEXT-MAP.md 找到语境正确的文档。
• 表达需要遵循 ASD-STE100 Simplified Technical English 的清晰约束，而不是退化成生硬、断裂的电报体。

Trade-offs、可移植风险与 harness 假设

直接来源： 该技能假设 harness 识别 disable-model-invocation，模型理解 ASD-STE100，并能读取仓库中的 CONTEXT.md 与可选 CONTEXT-MAP.md。

支持背景： agents/openai.yaml 使用另一套 allow_implicit_invocation 元数据表达同一边界；docs 说明没有上下文文件时仍可使用，但会失去领域词汇这一半能力。

解释：

• 极短 prompt 易调用、低负担，但没有显式完成条件；“是否重新讲明白”最终仍由用户判断。
• ASD-STE100 是外部规范名。不了解它的模型可能只做泛化的“简单英语”，移植时可补充本地风格基线，但不应把 corrective 膨胀成规范全文。
• CONTEXT.md 若过时、互相冲突或路由错误，统一术语反而会稳定地复现错误；上下文文件本身需要维护。
• “一点背景”没有硬性长度阈值，复杂主题可能需要多轮 /wait-what；技能优先提供渐进修复，而不是一次性百科解释。
• 它只修复已经发生的消息，不预防前置共同语言缺失，也不验证事实正确性。

可迁移原则

1. 用用户可观察的失败状态命名 corrective。 “我没跟上”比“少废话”更能表达真正目标。
2. 重新组织失败的表达，不要只压缩或复述。
3. 把背景、句法和术语当作三个独立控制旋钮。
4. 用一个映射层路由大型仓库中的领域上下文。
5. 纠偏型 skill 应比被纠正的问题更轻量。
6. 由最了解失败是否发生的人掌握触发权。

今日实践题

如果一个技术解释同时缺少前提、充满长句，而且把项目里的“订单”改叫“任务”，你会怎样用“背景、句法、统一语言”三个旋钮重讲它，而不是只把原句缩短？

Evidence note

• 直接来源： 本报告展示的完整 skills/productivity/wait-what/SKILL.md，包括显式调用元数据、会话修复句、ASD-STE100 和上下文路由要求。
• 支持背景： agents/openai.yaml、docs/productivity/wait-what.md、README 与 ask-matt 路由仅用于解释调用方式、极短设计和流程位置；它们没有被冒充为所选原文。
• 解释： 关于 comprehension 目标、三类故障、阻尼器和可路由词汇表的论述属于工程判断。