项目简介
一个 Claude Code 技能，运用 ASD-STE100 简明技术英语规则改写含混英文，使下游 AI 代理不会误读。它逐句标记违规、在不丢失事实的前提下重写，并附带确定性 Python 检查器做结构校验，支持严格流程与说明性文本两种模式。
README 预览
# ASD-STE100 Skill — Simplified Technical English for Agent Output\n\nA Claude Code skill that rewrites dense, ambiguous English into [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/) (STE) — the controlled-language standard the aerospace and defense industry built so aircraft maintenance instructions cannot be misread.\n\nThis skill repurposes that same discipline for a different reader: an **AI agent** parsing another agent's output, a tool description, an error message, or an inter-agent instruction, with no human in the loop to resolve ambiguity.\n\n## Why STE, and Why for Agents\n\nSTE exists because a misread instruction on an aircraft can kill people, and the intended readers were often not native English speakers with no author to call for clarification. The standard's fix: one meaning per word, active voice, simple tenses, one instruction per sentence, short sentences, no dropped words.\n\nAn LLM agent parsing another agent's output is in a strikingly similar position — no back-channel, no way to ask "did you mean X or Y?" The same rules that keep a mechanic from misreading a torque spec keep a downstream agent from misreading a tool description or an inter-agent message.\n\n## Before / After\n\n| Before | After |\n|---|---|\n| "This tool will attempt to synchronize state across the various backends that have been configured, and if a conflict is detected it may resolve it automatically depending on the strategy that has been set, or otherwise it will surface the conflict for manual review." | "The tool tries to synchronize state across the configured backends. If it finds a conflict, it reads the configured strategy. If the strategy allows automatic resolution, the tool may resolve the conflict without a user. If the tool does not resolve the conflict, it reports the conflict for manual review." |\n| "An error may have occurred while processing your request due to a possible mismatch in the expected data format, which could be caused b
常见问题 (3)
故障排除为什么 ASD-STE100 linter 会将 markdown 表格标记为超长句子？
这是一个 splitter bug，已在 PR #14 中修复。linter 没有从正文流中剥离 markdown 表格：表格行以 | 而非终止标点结尾，因此表头 + 分隔行 + 数据行被粘连成一个"句子"，每个 | 和 --- 标记都被计为一个词——导致计数膨胀，超过了 25 词的句子限制（例如，一个普通表格被计为 122 个"词"）。请更新到最新版本：表格结构标记不再计入统计，而单元格内的真实违规仍会被检测到。旧版本的变通方法：(1) 在每行最后一个单元格的末尾加上句号，让 splitter 按行断开；或 (2) 将表格转换为垂直项目符号列表，每行一个以句号结尾的条目——反正对于超过两项的列表，ASD-STE100 也更推荐这种形式。
故障排除为什么 examples/before-after.md 中的字数统计与示例文本不匹配？
列出的四个计数中有三个是错误的。使用空白字符拆分的正确计数如下：Example A（工具描述）= 44 个词，而非 55；Example C（智能体间指令）= 36 个词，而非 42；Example D（README 正文）= 34 个词，而非 36。只有 Example B（错误消息）的 28 个词是正确的。所有判定依然成立——每个示例仍超过其引用的上限（25 词描述上限、20 词指令上限），因此只需更正数字，无需改动 'After' 文本。你可以用 Python 中的 len(text.split()) 自行验证任何计数。请注意，该文件未说明其计数方法：这些数字假定以空白字符分隔词元且标点符号不计入，因此会将 'lock-in' 这类带连字符的词拆分开的分词器会得出不同的结果。另外，同一文件的第 43 行（项目自身的正文，由 PR #7 遗留）包含一个分号，违反了仓库自身的 Rule 8.1，应将其删除。
故障排除为什么 README 中的 Before/After 表格与 examples/before-after.md 相矛盾(诸如 "may have failed" 这类留有余地的措辞被改写成了 "failed")?
README 表格（README.md:17-18）在 PR #4 向 examples/before-after.md 添加情态保留规则时并未更新，因此两个 "After" 单元格展示的正是该技能所禁止的反模式（去掉模糊限定语会改变论断）。修复方法：将这两个 "After" 单元格替换为 examples/before-after.md 中修正后的改写。
第 1 行——保留模糊限定语：使用示例 A 的 "After"："The tool tries to synchronize state across the configured backends." 不要将 "will attempt to" 改写为 "synchronizes"，并保留 "may resolve"，而不是写成 "the tool resolves the conflict"。
第 2 行——使用示例 B 的 "After"："Your request may have failed. The cause may be a data format that does not match what the server expects. An outdated client can cause this mismatch. Check your client version." 不要使用 "The request failed... an outdated client is the most common cause"——前者断言了一个系统仅怀疑发生的失败，而后者编造了输入中并不存在的频率论断。
注意：自相矛盾的 Before/After 对比比完全没有更糟，因为同时读取这两个文件的模型会把该表格当作最强的信号。