plain——将密集/术语响应翻译成通俗英文
这是强制执行的规则：聊天中使用可理解、易消化的英文——每一个自创的代码都用通俗语言解释，没有任何内容被埋没在过程叙述中。
这条规则经常被违反——返回的回复充斥着文件代码（F027、B13、PTT、def_hash……）、未展开的缩写以及难以阅读的压缩名词堆砌。
这个技能就是解决方案：接收那个回复，然后用通俗、口语化、内容丰富的英文再说一遍。
这是"反简洁"技能——与/breakdown完全相反。注重长度？没问题；但丢失含义，绝不允许。
需要翻译的内容
默认目标：前一条助手消息。如果用户粘贴了文本或通过@提到了某个文件/代码块，则翻译那个。如果有歧义，询问一次。
如何操作
- 解析每一个代码、标签和缩写，找到其真实含义——不要猜测。 当出现文件代码/阶段名称/门控名称/哈希值时，在项目文件中查找（例如
findings.md、CHECKPOINT.md、相关规范），并用人们能理解的语言说明它实际上是什么。如果你确实找不到某个代码所指的内容，请说"我找不到X指的是什么"——永远不要编造含义。 - 重新表达，不要总结。 保留所有实质内容。这是翻译，不是删减后的摘要；为了简短而遗漏细节是失败的模式。
- 拆解压缩的名词堆砌和嵌套从句，变成简短、普通的句子。
- 不要引入新的简写——不要使用代码、项目术语。如果某个技术术语确实无法避免，则在第一次使用时内联定义它。
- 结构化以便阅读——使用短段落或纯文本列表，不要使用大段文字。
规则
- 使用通俗、口语化的英文，结构清晰易消化：先给出答案，使用短段落，足够展开来定义每一个术语——绝不能出现大段文字。
- 永远不要为你无法解析的代码编造含义。
- 不要添加新的分析、意见或下一步行动——只需让现有内容清晰易读。如果用户想要更多，他们会问。