用途与定位 本技能用于编写解决方案设计规范（SDS）。它是SDLC文档流水线的第三阶段（发现→需求定义→解决方案设计），输入为PRD，输出为后续测试定义阶段所需的设计规范。技能本身不修改代码、不产生提交；只读取代码以描述设计必须遵守的现有接口、格式和工具约束。设计规范描述要构建的系统，但不构建系统。
输入契约 主要输入是PRD（需求定义技能的输出）。写任何内容前先解析输入：若PRD存在（附带、引用或在对话中），需完整阅读并收集四项内容——所有FR与NFR编号（进入第1节范围清单和第9节可追溯表左列，每个编号都必须在两处出现）；所有Open Questions（每个转为第8节的一条ADR，无ADR的开放问题会阻塞规范）；附录A（被拒选项）；验收标准（第9节测试列必须与之兼容）。若PRD中有标记为“hunch provenance”的FR，需在第1节列为设计风险。 若没有PRD，应说明缺少PRD会使规范变弱，并建议先使用需求定义技能；用户拒绝时，从对话重建最小需求清单，写入第1节并标注“reconstructed requirements”，规范头部标记“no upstream PRD”。若设计过程中PRD发生变化，新增需求不得静默加入，应命名、给临时编号（FR-Dn）、放入第1节并提示用户更新PRD。
工作流程 解析输入后，阅读references/ste-writing-rules.md（所有行文遵守其规则），复制assets/design-spec-template.md作为起始文件并保持章节顺序，按以下顺序填写：范围→设计规则→契约→架构→组件→行为→失败模型→ADR→可追溯性→延期项。契约先于组件是有意设计：组件成为具名契约的读取者和写入者，两个实现者可依据冻结的契约并行工作。最后运行自检，把输出写入Markdown文件并呈现；若契约是数据模式，可提议同时写成CI可校验的JSON Schema文件。
各节要点 范围与PRD关联：一段范围说明，列出覆盖的FR/NFR编号、hunch来源FR的设计风险、未覆盖需求及原因（缺口是发现，不得隐藏）。设计规则：从NFR推导的4至6条优先级排序的取舍规则，每条引用所服务的NFR，低编号规则优先，需让实现者（人或代理）无需追问即可应用。契约：第二次实现必须一致的模式、文件格式和接口，每项包含字段表、唯一写入者和始终成立的不变量；契约是公共API，独立于代码版本。架构概览：一张简图，命名每个组件及其唯一写入的契约，每个产物只有一个写入者，并列出不写任何产物的组件。组件设计：每个组件须有“Functions”“Not functions”（强制）及带退出码的接口。行为：状态机与流程，逐步给出条件与结果；若系统持久化状态，需包含写入顺序分析，说明每对相关写入的顺序、突然中断后的状态及该状态可恢复的理由。失败模型：表格列出失败、检测器、设计响应，至少覆盖缺失输入、超限、突然停止、不可恢复外部状态、缺失可选依赖、检测到的损坏，每行对应第9节一个测试。ADR：每个PRD开放问题一条，加上每个有影响的新决策一条，固定结构为上下文、选项、决策、理由、结果；被拒选项的理由须与采纳选项同样具体，引用PRD附录A。可追溯性与测试映射：需求ID→设计章节→测试程序的表格，测试程序用祈使式STE写法（“Do X. Make sure that Y.”），只做验证设计，不含具体测试用例、夹具、测试代码、环境和覆盖率目标；无对应行的需求阻塞审批，无对应行的设计元素属于范围蔓延。延期与范围外：V2项各附升级触发条件，“Never”项各附会违反的设计规则。
自检与限制 提交前须检查：所有PRD的FR/NFR出现在范围清单和可追溯表；每个开放问题有ADR且记录被拒选项理由；每个契约只有一个写入者并列出不变量；每个组件有“Not functions”；持久化系统有写入顺序分析；每个失败模型行有对应测试；测试与PRD验收标准兼容；不出现函数签名、库选择、语言选择（判断标准：第二次实现是否必须一致，否则删除）；行文遵守STE规则。若用户要求普通英语，保留结构与全部规则，仅去除STE风格约束。下游测试定义阶段消费第7节失败模型和第9节测试映射，结合PRD验收标准把每行扩展为测试文件、夹具和CI接线；第7、9节应写得接近转录：一行一测试，无需解释。