企业官网建设流程全解析

wait-what：用“三个词”触发 Agent 重述你没听懂的那段对话

【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills

本文围绕 Matt Pocock Skills 仓库（skills13/skills）中的wait-what技能展开，讲解当 Agent 的消息“没接住”时，如何用一条极短的指令让它补上缺失前提、改用通俗英语并回归项目词汇表重新表达。读完你会掌握/wait-what的调用时机、命名机制背后的提示词原理、它与CONTEXT.md/CONTEXT-MAP.md的协同方式，以及如何判断一次重述是否真的成功了。

What it does：一句话说清这个技能是什么

wait-what是你在一条消息没有接住时输入的内容。你打出/wait-what，Agent 就会重新表述它刚才说的话（re-pitch）：补上你缺失的上下文、改用平实的英文，并且使用项目CONTEXT.md中的词汇表术语。

它是用户主动调用的技能。查看 SKILL.md 的完整实现，全部正文只有三行：

Wait, I don't understand where you've got to here. Re-pitch that: give me a little bit of context, talk in ASD-STE100 Simplified Technical English, and use the ubiquitous language from `CONTEXT.md` (follow `CONTEXT-MAP.md` to the right one if the repo has more than one).

这份技能只有三行长，这是设计使然，而不是未完成的草稿。文档明确解释了原因：对抗冗长的技能如果靠“增加规则”来生效，最终会失败——一个四百行的“简洁技能”依然会让模型保持啰嗦，因为模型读到的是体量，而不是那句恳求。而wait-what只携带一个精确的引导词（leading word）wait，再无其他。

从源码结构也可以印证这一点：agents/openai.yaml 中声明了display_name: "Wait What"与short_description: "Re-pitch that: simpler, with the context I'm missing"，并且通过policy.allow_implicit_invocation: false禁止模型自行触发。这与 CLAUDE.md 中描述的技能分类规则一致：凡带disable-model-invocation: true加上allow_implicit_invocation: false的技能，只能由人主动输入，模型不可隐式调用。

When to reach for it：什么时候该用它

wait-what的调用方式就是直接输入/wait-what。Agent 不会自己伸手去用它，也不应该。只有你知道自己什么时候跟丢了。

建议在你**刚意识到自己在“扫读”**的那一刻就使用。典型触发场景包括：

• Agent 已经滑向了它自己发明的行话；
• 它一次性堆叠了五个缩写词；
• 它解释了一个你从未见过前提的决策。

wait-what修复的是你正在进行的这段对话。如果你想从根本上阻止行话出现，应该改用grill-with-docs，后者会在事前就构建好共享语言（见下文“Where it fits”）。一个是事后补救，一个是事前预防，两者互补而非替代。

在仓库的产品力技能目录中，wait-what被归入User-invoked（用户触发）分组，描述为“消息没接住的那一刻触发它，Agent 会用你缺失的上下文、以通俗英语并使用CONTEXT.md词汇重新表述”。这个分组定位与上面源码中的调用策略完全一致。

The name is the mechanism：为什么“名字本身就是机制”

整个技能的关键在于引导词是wait（等等）。这背后是一套关于模型行为塑造的思考，值得单独展开。

• “Be concise（简洁点）”是对 Agent 输出的指令。模型服从它的方式是裁剪文字，而裁剪会让你丢失更多——它删掉的可能正是你缺的那部分上下文。
• “Wait（等等）”关注的是“你”的状态。它明确传达：这里理解失败了。一个听到“简短点”的 Agent 会回电报体；一个听到“等等，你跟丢我了”的 Agent 会后退一步，重新解释。

这个区别就是整个技能。文档对比了市面上常见的冗长问题修复方案——/tldr、/no-fluff、/talk-normal——它们的共同点是都在给输出命名，于是模型会过度纠正成“穴居人语式”的粗短表达，更短但同样不清楚。而wait-what给听者命名，一次同时要求两件事：更少的词和你缺失的上下文。

这与仓库中 writing-for-agents/SKILL.md 的“引导词（leading word）”理论一脉相承：一个已经存在于模型预训练中的紧凑概念，以 token 形式反复出现，就能以最少的 token 锚定一整片行为。wait正是这样一个词——它带着“理解失败、需要回退”的既有语义，比任何自造词都更省定义成本。该文档还专门警示了“否定式指令（negation）”的失败模式：靠禁止来引导（“别啰嗦”）会把被禁行为拖进上下文，反而让它更活跃；wait-what走的是正向路线——直接陈述目标行为（重述、补上下文）。

另一个细节：技能说的是重述that（那件事），而不是“那最后一条消息”。让你跟丢的通常比一个段落更大，所以由 Agent 自己决定要往回退多远，而不是机械地重说最后一句。

It plugs into the language you already have：复用你已有的语言体系

wait-what的正文复用了两处你已经配置好的引导词：

1. 你全局的CLAUDE.md；
2. 你项目的CONTEXT.md。

其中ASD-STE100 简化技术英语（Simplified Technical English）设定语域（register），通用语言（ubiquitous language）提供名词。技能、CLAUDE.md、CONTEXT.md三者指向同一批 token，所以调用wait-what并不是一条全新的指令，而是对 Agent已经同意过的某条规则的提醒。

关于CONTEXT.md的形态，可以参考本仓库根目录的 CONTEXT.md：它是一份纯词汇表（glossary），每个领域术语有定义、有“避免使用（Avoid）”清单，还有术语关系与歧义说明。例如仓库中把承载 Issue 的工具规范为Issue tracker，并明确“backlog”“backlog backend”等词不再作为领域术语使用。wait-what重述时要求的就是这类词汇回归。

如果项目没有CONTEXT.md（也没有指向当前场景对应CONTEXT.md的CONTEXT-MAP.md），技能依然能工作——你只是失去“领域词汇”那一半。剩余的“补上下文 + 简化技术英语”仍然生效。仓库中的 domain-modeling/SKILL.md 展示了多上下文仓库的布局约定：根目录存在CONTEXT-MAP.md时，各子目录（如src/ordering/、src/billing/）各自持有CONTEXT.md，这正是wait-what正文中“followCONTEXT-MAP.mdto the right one”所指向的机制。

It's working if：如何判断重述成功了

文档给出了四个可验证的成功标准，也可以当作每次调用后的自检清单：

• 重述更短且更清晰，而不是“更短但更生硬”；
• 它补上了你缺失的前提，而不只是删词；
• 项目名词取代了自造词——你CONTEXT.md里的术语回来了；
• 你可以连续用两次，而它不会劣化成电报体。

最后一条尤其重要：一个好技能要经得起反复调用。如果第二次使用就退化成极简回复，说明引导词没有真正把“理解状态”传达给模型。

Where it fits：它在技能体系中的位置

wait-what可以在任何时刻、任何对话、任何其他技能内部使用——它修复的是消息发生之后的事。它的定位是“事后补救”，而真正治本的是事先约定好的共享语言。

在这个仓库的技能地图中，与它相邻的组件包括：

• grill-with-docs：事前方案。它运行一场 grilling（拷问式访谈）并在过程中执行 domain-modeling，让你和 Agent 用过的词落到CONTEXT.md里。docs/engineering/grill-with-docs.md 详细描述了这条“状态化”工作流：术语一经确认立刻写入CONTEXT.md，达到三个门槛（难逆转、脱离上下文会让人困惑、真实权衡）的决策才写入docs/adr/。
• ask-matt：路由技能。当你拿不准此刻该用哪个技能时，ask-matt会帮你分流。skills/engineering/ask-matt/SKILL.md 的 Standalone（独立技能）一节对wait-what的描述与本文完全一致：在对话中途、任何其他技能内部使用它，Agent 会补上你缺失的上下文、用通俗英语、使用CONTEXT.md词汇重新表述；它工作在事后，而grill-with-docs是事前解药。

从更宏观的角度看，wait-what也是这套技能体系中“最小可运行单元”的范本：一个用户触发的技能，正文短到可以整体读入上下文，机制全部浓缩在一个引导词里，语言复用了项目已有的词汇基础设施。它证明了在 Agent 技能设计里，克制本身可以是一种设计，而不是偷懒。

实践建议

1. 时机：在“发现自己开始扫读”的瞬间就输入/wait-what，不要等整条消息彻底失控。
2. 前提准备：想让重述质量最大化，提前维护好项目根目录的CONTEXT.md（单一上下文），或通过CONTEXT-MAP.md管理多上下文仓库——那是wait-what领域词汇那一半的数据来源。
3. 效果检验：用文中的四条“It's working if”标准逐条核对每次重述；如果重述只是变短却没有补前提，说明这次调用没有真正传达“理解失败”的状态，可以再补一次。
4. 根治：如果发现需要频繁使用wait-what，说明共享语言没有建立起来，应回到 grill-with-docs 做一次事前访谈，而不是继续依赖事后补救。

【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills