用途
本技能是一套分层技术写作标准，目标是写出让疲惫的工程师第一遍就能读懂的文档。它要求同时应用四层规则，并遵守三条凌驾于分层之上的总则。
三条总则
- 删去不做功的词。句子删掉某词仍成立，该词就应删除。例如“in order to”改写为“to”，“It is important to note that”直接删除。
- 使用简短日常词。“use”而非“utilize”，“help”而非“facilitate”，“do”而非“perform”。长词必须用精确性来换取其长度。
- 当规则让句子变差时，换种方式改写或保持原样。完全合规但读起来像机器写的句子是失败的。
此外，代码库就是词表：写真实的符号、文件、标志或命令名，不用同义词或描述替代。不要自造行话，使用开发者口头会说的词。命名模式首次出现时要说明含义。
节奏与具体性
有意混合句长：短句落点，长句承载带条件或后果的事实。一句一个想法不等于句句同一长度。在适合的模式下表达观点：解释类可权衡取舍并给出判断，参考类保持干燥。追求具体而非空泛，写“列重命名会导致构建失败”，而非“schema 变更可能引发问题”。
第一层：先选模式（Diátaxis）
一篇文档只用一个模式。用两个问题判定：内容是指导行动（做）还是传递理解（想），服务于学习还是工作。
- 行动 + 学习：教程。
- 行动 + 工作：操作指南。
- 理解 + 工作：参考。
- 理解 + 学习：解释。
教程：边做边学，学习者能否成功是作者的责任。开头说明将构建什么而非将“学到”什么。每一步产生可见结果，并告知应看到什么（预期输出、提示变化、日志行）。解释压缩为一个从句加链接，用“we”和命令式写作。
操作指南：通向目标的步骤，解决人的问题而非机器操作。假定读者有能力，不教学。只讲行动，不跑题、不铺垫、不为完整而完整，用链接替代。允许分支与判断。按任务命名，如“How to calibrate the radar array”。
参考：供查阅的事实，只描述，不指导、不说服、不发表意见。干燥、完整、确定，陈述事实、选项、限制和错误，不加模糊限定。结构与所描述之物对应，材料放在读者预期位置，尽可能从代码生成。
解释：理解与原因。一个有限主题，可脱离产品单独阅读。每个标题应能容忍前面加“About...”。围绕真实的原因问题，给出设计决策、历史、约束和替代方案。只有这里允许表达观点。
不要混用模式：教程里不放参考表，参考里不放手把手教学，操作指南里不辩论。需要时拆分并链接。
第二层：面向读者写句子（Google 开发者风格）
- 以“you”称呼读者，用现在时；“will”仅用于确实以后发生的事。
- 说明谁做什么，用主动语态；仅当施动者未知或无关时可用被动。
- 指令写成命令句，如“Click Submit.”；事实平实陈述，不写“should be done”。
- 条件放在指令前，如“To delete the document, click Delete.”。
- 常见情况在前，例外在后。
- 语气像懂行的朋友。不用流行词、比喻；指令中不用“please”；流程中绝不用“simply”“easy”“quickly”。
- 不预告未来功能；连续句子不以相同短语开头。
- 链接文字说明去向，用页面标题或简短描述，绝不用“click here”。优先在页面内提供上下文，而非链出。
- 标题承载要点而非仅主题（“Pick the mode first”而非“Modes”）。使用句首大写。任务标题为动词短语，概念标题为名词短语。每页一个 h1，不跳级。
- 序列用编号列表，其余用项目符号。列表前用完整句子引入，各项保持平行。
- 代码用代码字体，UI 元素用粗体，使用序列逗号。不用“etc.”，如需说明列表不完整应前置声明。
第三层：让陈述逐条承载信息（STE 规则）
- 一句一条指令；其他文本一句一个想法。
- 拆分超过约 20 词的指令和超过约 25 词的其他句子。
- 警告或条件放在其保护的步骤之前。
- 保留“the”和“a”，避免歧义。
- 每个词一个含义、一个职责，并保持一致。如“check”表示检查，就不再用它表示约束。
- 每个动作固定一个词，如统一用“start”而非此处“start”彼处“initiate”。
- 流程写成直接命令，不用叙述、不用被动，如“Install the component”。
- 尽量避免“-ing”形式。
第四层：不留两种读法（Global English）
- “only”“not”等词紧邻其修饰对象。
- 拆开长名词串，如“the proto import budget check script”改为“the script that checks the proto-import budget”。
- 每个“it”“they”“this”都指向唯一明显对象，存疑时重复名词。不用“this”或“which”指代整个从句。
- 不省略动词。
- 保留体现结构的小词，如“Ensure that the switch is off”中的“that”。
- 系列中重复冠词以防误读，如“the client and the host”。
- 说明“and”“or”连接的是哪部分。可用“Both...and”“either...or”“if...then”消歧。
- 用句号而非分号；破折号改为新句子。
- 括号内容须为完整语法单位或独立句子。不用“(s)”构成复数。
- 不用斜杠，写“a, b, or both”。
- 同一事物全文一名。
- 避免习语、口语、拉丁缩写和比喻。
适用范围与仓库细节
- 对本技能触及的每篇文档应用 unslop 技能，该技能负责 AI 用词、空话、模糊限定、格式痕迹等模式目录。
- PR 描述和提交信息也是写作，适用除 Diátaxis 外的各层规则。PR 正文应让审阅者一分钟内读完，不要粘贴 swarm 日志、SHA 列表或指标表，改为链接。
- 产品 UI 文案不是文档，使用产品自身的文案指南。
- 代码片段用制表符缩进，写真实路径。任何计数或目录树声明在落地提交处必须为真，并附可重新生成的命令。
示例
改前：
Configuration of the proto import ratchet budget script parameters is performed via budget.json. Note that it's important to remember that running with --write, which updates the committed budget to reflect the current count, should only be done when lowering it. If exceeded, CI fails.
改后：
budget.mjs reads the committed budget from budget.json and counts the files that import protos. If the count exceeds the budget, CI fails. Run budget.mjs --write only to lower the budget.
限制
资料未提供安装方式、收费信息、支持平台或具体使用步骤。资料提到多数 pstack 技能为仅用户可用，技能工具无法加载，技能以加粗、反引号或 /<name> 形式引用时需读取对应 ../<name>/SKILL.md 文件并遵循。