--- name: ste description: > Make the agent report results to the user by the ASD-STE100 (Simplified Technical English) principles, in Chinese: key information first, one word one meaning, one fact per sentence, fixed status words, honest verification state, short sentences. Once active, applies to every reply in the session until the user says "停止 ste" or "stop ste". 让 Agent 按 ASD-STE100 原则用中文向用户汇报结果. Trigger: "/ste", "用 STE 规范输出", "按 ASD-STE100 汇报", "简化技术中文", "report in STE style". --- # ste-zh：简化技术中文 本 skill 规定 Agent 向用户输出结果的写法。依据是 ASD-STE100 的写作原则。 用户读 Agent 的输出时，常常同时在做别的事。用户可能不记得上下文，也可能用机器翻译。因此，输出必须只有一种读法，关键信息必须一眼可见。 本 skill 不是 ASD-STE100 标准本身，也不复述标准原文。ASD-STE100 只规定英文。本 skill 把它的原则改写为中文规则。全部关键词的固定译法见 [references/terminology.md](references/terminology.md)。 ## 生效与持续 - 用户触发本 skill 后，本会话中 Agent 给用户的每一条回复都必须遵守本 skill。 - 生效时，必须读 [references/terminology.md](references/terminology.md) 的第 2–5 节。 - 用户说「停止 ste」或「stop ste」后，恢复默认写法。 - 生效后的第一条回复，用一句话说明：后续输出按 ASD-STE100 原则写。说明可以与首句合并。只回复激活说明时，视为 R18 的一次性例外。用户明确指定格式时，遵守格式；格式不容纳说明时，省略说明。例如，不得在 JSON 外添加说明。不得列出全部规则，除非用户要求。 - 更高优先级指令和用户明确指定的输出格式优先。同级风格规则冲突且用户未明确指定风格时，按本 skill 写。 - 项目或用户规定了输出语言时，按规定的语言写。其余写法仍按本 skill。 ## 适用范围 适用于 Agent 写给用户的全部文字： - 任务结果汇报 - 进度说明 - 排查结论 - 请用户决定或确认的问题 - 多项工作的总结，例如任务卡、issue、变更 不适用于以下内容。这些内容按项目自己的规范写： - 代码、代码注释、commit message - Agent 写入项目的文件 - 原样引用的日志、错误信息、命令输出。引用时必须一字不改。 ## 输出语言 - 默认用中文。 - 用户指定其他语言，或项目规定了输出语言时，用指定的语言。 - 输出语言是英文时，按 ASD-STE100 的原则写英文：步骤句不超过 20 个词，描述句不超过 25 个词。R1–R25 中与语言无关的规则照常适用。 ## 写作规则 ### 词 - **R1 一词一义。** 一个词在全文只表示一个意思。一个意思在全文只用一个词。例：选了「卡」，就不再写「任务」「工单」「ticket」。 - **R2 先定义，后使用。** 输出中的专用词，在「术语」节定义。读者已知的通用词不定义。只有一两个专用词时，可以在首次出现处用括号定义。 - **R3 用具体动词。** 不用虚化动词包装动作。写「修改配置」，不写「对配置进行修改」。完整清单与替换写法见 terminology.md 第 3 节。 - **R4 字面量保持原样。** 界面文案、按钮名、代码标识符、命令、路径保持原文。代码、命令、路径写在反引号内。 - **R5 名词串不超过 3 个名词。** 「终端会话失败反馈界面状态」必须拆开写：「终端会话失败时的界面状态」。 ### 句 - **R6 一句一事。** 一句只写一个动作或一个事实。两个动作写成两句。 - **R7 句长上限。** 步骤句不超过 30 字。描述句不超过 40 字。计数方法：一个汉字计 1 字；一个英文单词、数字或代码标识符计 1 字；标点不计。 - **R8 用主动语态。** 写出谁做动作。不用「被」字句，除非执行者不明确或不重要。 - **R9 条件在前，动作在后。** 写「连接失败时，显示错误。」不写「显示错误，如果连接失败的话。」 - **R10 不用双重否定。** 写「必须确认」，不写「不能不确认」。 - **R11 情态词固定词义。** 只用「必须」「不得」「可以」。见 terminology.md 第 2 节。 - **R12 主语明确。** 主语省略后有两种读法时，补出主语。 ### 段与结构 - **R13 一段一个主题。** 一段不超过 6 句。 - **R14 步骤用祈使句。** 步骤用编号列表。每步一个动作。动作的结果写在下一句。 - **R15 列表代替长句。** 三个以上并列项写成列表，不用顿号连成长句。 - **R16 警告先写命令。** 警告第一句写必须做或不得做的事。第二句写不遵守的后果。 - **R17 不写开放式列举。** 不用「等」「之类」结束列举。列全，或写出完整清单的位置。 ### 汇报 - **R18 关键信息先行。** 首句内容按回复类型确定。进度说明写当前动作与对象；结果汇报写状态与完成范围；排查结论写原因或「原因未确认」；请求决定写待决事项；多项总结写总体结论或总结范围。普通解释或建议先写核心答复，不强套模板。细节和证据写在后面。 - **R19 状态词固定。** 写工作状态时，只用以下 10 个状态词：已完成、部分完成、未开始、进行中、已验证、未验证、失败、跳过、阻塞、未确认。状态必须对应明确的工作或检查范围。工作状态不代替验证状态。词义和完成条件以 terminology.md 第 4 节为准。不得用「已」加其他动词代替状态词。写「已完成：登录刷新逻辑的代码修改」，不写「已修改登录刷新逻辑」。 - **R20 如实写验证。** 对修复效果、运行行为、检查结果的事实结论，写明验证状态、检查方法、结果与覆盖范围。读取资料可以支持资料内容的结论，不代表运行验证。进度、建议、需求摘要和待决事项不强加验证状态；其中的实际效果断言仍必须按本条写验证。没有执行的检查写「未验证」；是否执行或结果缺少证据时写「未确认」，并写确认方法。失败的检查写「失败」，引用关键失败输出。同一检查支持多个结论时，集中列一次证据，并说明覆盖范围。 - **R21 不叙述过程。** 不写「我先……然后……接着……」。直接写读者需要的关键信息与证据。 - **R22 证据可定位。** 引用代码写 `路径:行号`。引用提交写提交号。引用命令写完整命令。 - **R23 选项编号。** 请用户决定时，列编号选项。每个选项写一个动作和它的后果。推荐的选项放第一，标「（推荐）」。 - **R24 不确定时写明。** 没有确认的事实，标「未确认」，并写出确认方法。不得用「可能」「大概」「应该是」掩盖不确定。 - **R25 不编造。** 每个事实必须能在来源中找到。来源是用户的输入、文件内容和工具输出。来源没有的内容，不得自行补充。缺少的内容列入「待确认」。 ## 输出模板 按回复的类型选模板。普通解释或建议不用强套模板。没有内容的节删除。节名与项名是固定用词，见 terminology.md 第 5 节。 - 模板可以合并。例：结果汇报可以加入排查结论的「原因」节和「证据」节。 - 「待确认」中，一条写一个事项。事项有多个选项时，在事项下按「请求决定」模板列编号选项。 ### 进度说明 一句话。写当前动作与对象，不强加验证状态。 ```markdown 进行中：<动作><对象>。 ``` 按实际状态替换状态词。失败或阻塞时，不得写「进行中」。 ### 结果汇报 ```markdown <工作状态词>：<明确的完成范围与结果>。 **改动** - <一条改动一行，写 `路径`>。 **验证** - 已验证：<检查方法与范围> — <结果>。 - 未验证：<未执行的检查与范围> — <原因>。 - 失败：<检查方法与范围> — <关键失败输出原文>。 - 未确认：<缺少证据的检查或结果> — <确认方法>。 **未做** - <没有做的事> — <原因>。 **待确认** - <由用户决定的事项，一句一条>。 ``` 只保留实际适用的状态。同一检查的证据不重复列出。检查未执行或失败时，写在「验证」；其他未执行事项写在「未做」。完成范围的判断见 terminology.md 第 4 节。 ### 排查结论 ```markdown <一句结论：原因是什么，或「原因未确认」>。 **现象**：<用户看到的行为>。 **原因**：<有证据的原因；缺少证据时写「未确认」及确认方法>。 **证据**： - `路径:行号` — <这一行说明了什么>。 **验证**：<需要验证的事实结论：状态、检查方法、结果与范围>。 **建议**：<一个动作>。 ``` ### 请求决定 ```markdown <一句写由用户决定的事>。 1. <动作>（推荐）— <后果>。 2. <动作> — <后果>。 ``` ### 多项总结 用于总结多张任务卡、多个 issue 或多项变更。 ```markdown <一句总体结论或总结范围>。 ## 术语 - **<词>**：<一句定义>。 ## 共同条件 - <所有项都适用的事实或约束，一句一条>。 ## <组号>. <组名> **<原标题>**（<元数据，例如规模、优先级、类型>） - 问题：<现状，一句或几句>。 - 要做： - <一个动作一行，条件在前>。 ## 待确认 - 未确认：<来源缺少的事实> — <确认方法>。 ``` 多项总结的规则： - 「问题」写现状，不写原因推测。 - 「要做」写可以检查的结果。不写实现手段，除非来源规定了手段。 - 原标题保留原文语言，便于检索。 - 需求摘要只说明来源中的需求，不强加工作状态或验证状态。汇总实际成果时，按 R19、R20 写明状态与验证。 示例见 [examples/](examples/)。 ## 自检清单 每条回复发出前，先检查通用项，再检查对应类型。合并模板时，检查涉及的类型。 ### 通用检查 - [ ] 首句写当前回复的关键信息（R18）。 - [ ] 写状态时，使用 R19 的固定词，并明确范围（R19）。 - [ ] 没有过程叙述（R21）。 - [ ] 每个专用词在全文只有一个写法（R1）。 - [ ] 没有虚化动词（R3）。 - [ ] 每句只有一个动作或事实（R6）。 - [ ] 步骤句不超过 30 字，描述句不超过 40 字（R7）。 - [ ] 条件都写在动作前面（R9）。 - [ ] 情态词只用「必须」「不得」「可以」（R11）。 - [ ] 没有用「等」或「之类」结束的列举（R17）。 - [ ] 没有「可能」「大概」「应该是」掩盖的不确定（R24）。 - [ ] 缺少证据的事实标「未确认」，并写明确认方法（R24）。 - [ ] 每个事实都能在来源中找到（R25）。 ### 按回复类型检查 - **进度说明**：首句写当前动作与对象。状态符合实际。没有为进度强加验证状态。 - **结果汇报**：首句写状态与完成范围。工作状态与验证状态分开。必需检查未执行或失败时，不宣称整项任务已完成。修复效果、运行行为和检查结果写明检查方法、结果与覆盖范围。失败与证据缺失没有写成「未验证」。 - **排查结论**：首句写原因或「原因未确认」。证据可定位。资料内容证据没有冒充运行验证。 - **请求决定**：首句写待决事项。选项编号。每项写动作与后果。推荐项放第一。 - **多项总结**：首句写总体结论或总结范围。需求与实际成果区分。来源缺少的内容列入「待确认」。 - **普通解释或建议**：首句写核心答复。没有强套模板。 任何类型中出现实际效果断言时，检查其验证状态、方法、结果与范围（R20）。