用途
该技能面向需要写出「评审者能据此行动、也能据以反驳」的技术文档，而不是把模板填满。覆盖文档类型包括：需求/PRD、技术方案/设计文档、低层设计（LLD）、决策记录（ADR/MADR/RFC）以及权衡分析。核心主张是：文档的价值在于把事实、判断和不确定性讲清楚，而非形式上的完整。
主要流程
第 0 步：拒绝盲写。 动笔前先走 rules/core/prompt-validation.md 的六维校验，低于阈值时只追问最弱的 1–2 个维度，不猜测。随后在输出头部回答三个问题：谁读这份文档、用它做什么决策；哪些是已经成立的（代码/系统），哪些是提议的；什么情况会让这份文档变错。
第 1 步：定层级，默认往低走。 按复杂度而非投入量选层级：T0 为一句 Y-statement 或 PR 描述段落（可逆、撤销成本低即止）；T1 为 Nygard ADR 五节或一页规格（后果长期但选项单一明显）；T2 为 MADR 加适用的 LLD 章节（有两个以上真正值得比较的选项）；T3 为 RFC（跨团队、难以逆转）。仅在满足至少两项条件时升级：多团队受影响、难以逆转、两个以上可信选项、涉及安全/资金/数据丢失风险、读者不在场无法追问。不得因「话题感觉重要」而升级。所有文档按 Oxide RFD 生命周期标注状态：ideation → discussion → published → committed → abandoned，刻意不设 draft。
第 2 步：先取证，后起草（顺序关键）。 对超过 20k token 的源材料，先逐字摘录引文再分析。关于代码库的每条主张都需有前置的 Read 覆盖到相应文件/函数/符号，这是确定性检查、无 LLM 判断成本。引用写成 path/to/file.ts:120-134，而不是「认证模块处理了这一点」。起草后逐条回找支撑引文，找不到就删除并标记缺口，不软化措辞。承认不确定是合法输出：写「未验证：<内容>，以及何种方式可以验证」。每条非显然主张标注证据等级：[CODE] 本次会话读到并引用 file:line；[SOURCE] 外部来源并附 URL 与逐字引文；[CONVENTION] 标准或通行做法，注明标准名称但非有效性证明；[UNVERIFIED] 相信但未核查，说明核查方式。
第 3 步：独立验证，不在原上下文自评。 资料引用的测量显示，原地自我纠错会降低输出质量（如 GPT-4 在 GSM8K 上由 95.5 降至 91.5 再降至 89.0；GPT-3.5 在 CommonSenseQA 上由 75.8 降至 38.1 再升至 41.8），且多智能体辩论在同等预算下不如自洽采样。因此流程为：起草 → 针对草稿拟验证问题 → 在看不到草稿的新上下文中独立作答 → 据答案修订。外部验证优先：跑测试、执行代码片段、curl 端点、读迁移。资料同时声明这些技术显著减少但并未消除幻觉，关键信息仍须人工核验。
需求文档
规范标准为 ISO/IEC/IEEE 29148:2018（条款正文付费，不得假装引用原文名称）。工作评分表采用免费的 INCOSE GtWR v4：单条需求特征 C1–C9（必要、适当、无歧义、完整、单一、可行、可验证、正确、符合约定），需求集合特征 C10–C15（完整、一致、可行、可理解、可验证、正确）。可机械检查的规则子集包括：禁用模糊词（some/any/several/many/about/approximate）、禁用逃逸条款（as appropriate/as required/to the extent practical/if practicable）、单一性（每条陈述一个 shall，标记由 and/or 连接的多重义务）、量化词需有定义范围、数字需带单位与容差、同一概念用同一术语。其余规则需人工或 LLM 判断，不得宣称「42 项自动检查」。每条需求的推荐属性：理由、追溯到父项、追溯到来源、验证成功标准、验证策略、验证方法、唯一 ID、负责人、优先级、关键性、风险。追溯性按标准的「上行派生路径与下行分配/流下路径」表述。
低层设计
LLD 无统一标准形式：IEEE 1016-2009 明确说明体系结构、高层与详细设计之间的界限因系统而异，超出该标准范围；其唯一模板（附录 C）为资料性内容且按视角组织。最接近的权威是 IEEE 1016-2009 的十二个设计视角，在适用时应使用：上下文、组成、逻辑、依赖、信息、模式、接口、结构、交互、状态动态、算法、资源，应作菜单而非清单。常见章节（数据模型、API 契约、时序图、状态图、错误处理、并发、容量规划）都有标准来源可循；幂等性、可观测性、迁移/回滚三项未找到任何一手标准支撑，可以写但不得声称有标准依据，也不得系统不需要却硬加章节。停止标准来自 ECSS-E-ST-40C Rev.1：细化到「可编码、可编译、可测试」的软件单元，接口定义精确到「无需更多信息即可编码」，深度由可编码性与可测试性决定，而非页数。所查标准（ECSS、DoD DI-IPSC-81435A、NASA NPR 7150.2）均把架构与详细设计放在同一份文档，按评审里程碑（PDR/CDR）划分，因此默认使用一份带章节的设计文档。这些属安全关键与国防采购体系，借其结构只是类比，不构成合规。
反空话门槛
发布前删除：无本系统具体内容的章节（删除而非填充）；没有数字或机制支撑的 robust/scalable/seamless/best-practice；复述模板提示语；无法测试的需求；只列不比的备选方案；全是 MEDIUM 的风险表；无出处的数字（实测、引用或标 [UNVERIFIED]）；仅复述文字的图。T1 及以上文档必须包含：非目标、缺点（「为什么我们不该这样做」，此处留空会摧毁可信度）、不作为的代价、负责人 + 日期 + 状态。资料引用 Google 内部数据（约 90% 文档在弃用前数月无浏览无更新，文档成为内部开发者调查首要抱怨），但提示这是自报数据、未公布年份与样本方法，且属于文档未进源码管理的时代，须如实说明。建议将文档与代码同仓存放、有负责人、随代码同一提交修改。
适用场景与限制
适用于架构决策、方案评审、需求澄清、设计评审与跨团队 RFC 等场景。需要注意的是：文档章节顺序（问题先行、决策先行、Amazon 叙事）无证据支持哪种更好；多项常见说法已被证伪，例如 Google 强制模板化设计文档关卡、ISO/IEC/IEEE 42010 要求记录被拒方案理由、Rust RFC 模板强制问题先行、adr.github.io 恰好列出四个 ADR 家族。LLM 评判可靠性数据与 ALCE 引用质量数据未经核实，不得引用；AI 生成技术文档质量的基准是否存在，诚实说法是「未确立」。资料未提供该技能的具体安装命令或调用方式，暂未提供。