simple-english

与 workflow-axa 一起打包，源自 AminBlg/SimpleEnglish 的 skills/simple-english/SKILL.md，提交为 a6fcb4f（版本 2.1.1），采用 MIT 许可（LICENSE）。下方的上游文本未作改动；末尾的 workflow-axa 适配内容在与其冲突时优先适用。

简明英语

使用通俗的英语，让专业领域之外的聪明读者读一遍就能理解。这些规则源自 ASD-STE100，即航空航天行业用于维护手册的受控语言。这里有两种语体：你撰写或改写的文档，以及你在聊天中输入的回复。下文为两者分别列出了简短的规则集。

文档

需要编写或改写文档时，请遵循以下正文规则：

1. 对每段文字进行分类。操作文本告诉读者要做什么：使用祈使语气，每句不超过 20 个单词，每句只包含一条指令。描述文本用于解释：使用简单时态，每句不超过 25 个单词，每段只讨论一个主题，每段最多六句。
2. 绝不改动代码、标识符、命令、标志、文件路径、引用的错误、产品名称或事实。源文未给出数字或原因时，保留概括性表述。
3. 条件放在命令前，并用逗号隔开：“如果构建失败，请阅读日志。”
4. 使用简单时态和主动语态。不要使用现在完成时（“has completed” → “completed”）。逗号后不要使用以“-ing”结尾的动词（“, making it easy” → 改为新句）。明确指出执行者：“你运行迁移。”
5. 情态动词：can、will、must。绝不使用 should、would、may、might、could。表示必须时，将 “should” 改为 “must”。表示可选时，删除 “should”。
6. 使用完整的语法。不要使用缩写，保留冠词和 “that”。写简短句子，不要使用电报式语言。
7. 不要使用分号和破折号。拆成两个句子，或明确说明两者的关系。
8. 一个词在全文中只表达一种含义。使用 make sure that 表示检查、核实、确认、验证和确保。使用 configuration 表示配置、设置和选项。超过三个词的名词链应使用介词拆开（“连接池的超时值”）。
9. 在读者需要某个术语或事实之前，先提供该术语或事实。首次出现时，用不超过十个词定义概念术语，每句只定义一个。不要定义产品名称、标准名称（Postgres、S3、HTTP）或本文档所述的工具。还要指出命令所依赖的主机、标志或前置步骤。“重启服务”应改为“在运行作业的主机上重启 sync 服务。”
10. 陈述事实，不要强调其重要性。删除不传达事实的词语：simply、seamlessly、robust、powerful、comprehensive、leverage、crucial、“in order to”、“it is worth noting”。不要使用“not just X, it is Y”句式。不要使用装饰性排比。不要写“in conclusion”。
11. 仅在格式能体现结构时使用格式。不要使用粗体引导语，不要用粗体强调，不要使用表情符号，标题不超过两句话。三个或更多并列项目或步骤应使用纵向列表：引导语以冒号结尾，每项以大写字母开头，每项只包含一条指令。
12. 警告：先写命令或条件，再写风险。“不要对生产环境运行此命令。该命令会删除行。”

使用美式拼写。references/word-swaps.md 将过度使用的词替换为朴素表达。对于错误消息、操作手册、事故报告、发行说明、提交消息或 UI 文案，请先阅读 references/use-cases.md。其中列出了每种内容对应的模式和写法。

改写前（AI 输出）：

连接超时。 如果 sqlpipe 卡住或出现 dial tcp: i/o timeout，请检查运行 sqlpipe 的主机是否可以访问 Postgres 端口（通常为 5432）——这通常是安全组或防火墙规则阻止了连接。如果连接的是托管数据库（RDS、Cloud SQL 等），请确认实例允许来自 sqlpipe IP 的连接。

改写后（操作性内容，带标题和编号）：

连接超时

如果无法连接到 Postgres 端口（默认端口为 5432），sqlpipe 会停止并显示 dial tcp: i/o timeout。

1. 确保运行 sqlpipe 的主机可以连接到 Postgres 端口。防火墙或安全组通常会阻止连接。
2. 如果数据库由服务提供商托管（RDS、Cloud SQL），请确保实例接受来自 sqlpipe IP 的连接。

回复

每条聊天回复，无论处于哪种模式，都遵循以下规则：

1. 使用散文作答。不要使用标题、项目符号列表、粗体或表格。读者需要复制内容时，可以使用代码块。
2. 第一句话直接给出答案或结果。不要复述问题。
3. 不要使用破折号。说明两者之间的关系（“因为”“但是”“例如”），或拆成两个句子。
4. 首次使用概念术语时，用几个词对其进行定义：“幂等（可安全运行两次）”。不要定义产品名称。
5. 不要使用缩写形式。不要使用开场白（“当然”“好问题”），也不要使用结束语（“希望这能帮到你”“有需要请告诉我”）。
6. 不要缩短引用的错误文本、安全警告，或执行破坏性操作前的确认内容。

之前：故障源于 Pod 频繁变动期间的控制平面领导者选举，没什么好担心的！ 之后：Pod 重启了，队列短暂失去了领导者。随后系统自行恢复。你不需要做任何事。

提交前自检

1. 回复：搜索 —、**、#，以及以 - 开头的行。逐一删除。
2. 文档：统计三个最长句子的词数。超过 20 或 25 个词时，拆分句子。搜索 '、has been、should、may、;、—、, making、**、check、verify、config，以及涵盖不到三个句子的任何标题。逐一修正每个命中项。阅读每个步骤：它是否指出了主机、标志，或读者必须事先了解的步骤？如果没有，请补上相关信息或指向相应内容。

模式

Plain 是默认模式，包含以上所有规则。当用户指定 STE、ASD-STE100 或合规时，使用 Strict：起草文档前先阅读 references/strict-vocabulary.md，并说明一次，没有工具可以保证合规。无论处于哪种模式，回复都保持 Plain。

当用户要求检查文本，而不是撰写文本时，先打开 references/rule-catalog.md。然后逐项报告每个违规之处，格式为：引用该文件中的规则编号、违规文本、符合规则的改写。切勿凭记忆引用规则编号。当用户要求合规时，以一句话结尾：没有工具可以保证符合 ASD-STE100；该标准可从 asd-ste100.org 免费下载。

限制

这些规则适用于事实说明和操作指引，不适用于营销文案或品牌写作，因为它们会削弱说服力。请说明这一点，并表示可以将这些规则用于文档。

参考资料

• references/rule-catalog.md：Issue 9 的 53 条规则及软件示例，供 CHECK 模式使用
• references/strict-vocabulary.md：Strict 模式的词汇规范
• references/word-swaps.md：常用词语的通俗替换方案
• references/use-cases.md：各种模式以及错误消息、运行手册、事件报告、发行说明、提交信息、Agent 提示词、界面文案和翻译准备的范例

workflow-axa 适配

workflow-axa 使用此技能处理供人阅读的文本：所有 HTML 报告（计划、进度、交付）以及交接这些报告的聊天消息。仅限纯文本模式。

• 报告是文档。 对报告 JSON 的每个文本字段应用“The Document”规则：理解说明、各节文本、ticket 规格和预期结果、验收说明、检查预期、结果和限制、决策摘要、风险。在渲染前，对这些文本运行其自检。
• 绝不更改必须保持精确的内容： 标识符、文件路径、命令、带引号的用户原话（双引号或反引号）、决策记录、报告值（verified、partial 等），以及 design.md 规则 4 中逐字引用的问题。
• 保留项目的术语。 一个词只表达一个意思，但项目和工作流中已确立的术语优先（ticket、agreement、gate、acceptance）。不要将它们替换为同义词。
• 聊天消息： “The Reply”规则 2 到 6 适用：不使用缩写（用“do not”，不要用“don't”）、不使用分号、不添加填充内容。规则 1（仅限散文）服从工作流要求的格式：带选项的编号问题、包含三项或更多内容的简短列表，以及结束状态行（“Waiting on you:”、“Running:”、“Done.”）。
• 先陈述事实，不加赘述。 不陈述事实、检查或决策的句子应删除，而不是改写。
• 情态动词保留原意。 此规则优先于规则 5：当 may、might、could、should 和 would 表示不确定性、许可或提议时，应予以保留。仅改写空洞的委婉表达，不要直接删除。
• 渲染器会在写入前检查每份报告。 它会打印 PLAIN ENGLISH: 问题和针对情态动词的 PLAIN ENGLISH NOTE: 行，并跳过引文。问题不会阻止渲染；--open 会等待。在用户看到内容之前，使用 --replace-unpresented 重新渲染到同一文件。