用途：在动手实现之前，先决定要做什么、为何重要、用户体验如何、技术上将如何运作，并把关键取舍固定下来，避免实现方自行发明有影响的决策。
主要能力：读取需求、仓库说明、相关代码与链接材料，复用已确定的需求与仓库约定；找出会改变行为、接口、数据、安全、运维或验证方式的缺失决策；起草前提出阻塞性问题并给出建议答案，非阻塞问题记录建议默认值；按固定结构撰写 docs/<feature-slug>/design.md；执行一次评审并修正可修补的缺口，未决事项记入 Open questions；最终交付一份待评审的设计，不进行规划或实现。
文档结构：Requirements（需求：问题、受影响者、所需能力、约束与范围外），User experience（把系统视为黑盒，描述用户操作、所见所得及主流程与空、非法、拒绝、失败等结果和恢复，CLI、API、库的使用者可为操作者或调用方），Technical design and choices（改动如何融入现有系统、变更的职责、接口与数据、技术选型及理由和主要代价），Acceptance and proof（每条可测条件与检查方式配对，含失败路径与不变规则），Open questions（未决决策、建议答案、是否阻塞）。
技术细节仅包含本次改动需要决策的主题：技术选型（语言、框架、主要依赖、存储、部署，新项目选核心栈，已有项目引用既有选择并说明新增或变更，兼容性依赖时固定版本）；结构与契约（组件职责边界、API、命令、事件、schema、配置、迁移，标识符创建与兼容性）；失败与恢复（可失败点、结果状态、重试及限制、恢复，含启动、运行中变更与关闭）；安全与运维（信任边界、授权、敏感数据及规模、延迟、连接、磁盘、内存、成本等限制及触达限制后的行为）。每个选择说明决定、为何满足需求、主要代价或限制。
写作规则：用词平实，术语需定义；每条事实只写一处；INV-n 标记需稳定引用的规则，并映射到验收证明；AC-n 与 INV-n ID 不重编号、不复用，新增用下一个未用 ID；更新既有设计时保留锚点，不因套模板而重构；常规特性约 500 至 800 词。
限制：该技能只产出待评审设计，不做规划或实现；资料未提供具体安装命令、运行环境与授权方式，暂未提供。