用途：为架构智能体提供结构化设计流程，把 grill/领域建模的结论转化为完整的设计产物，包括 NOTES.md、tech-spec.md，以及必要的领域文档更新。
主要能力：按步骤推进设计。先收集并分类硬约束与软约束，写入 NOTES.md 的 Context 部分，引用 ADR 编号；若存在 graphify-out/graph.json，则用 /code-graph query modules、/code-graph query deps <module> 等命令校验约束与真实代码结构是否一致，并打上 [graph-verified] 标签。随后识别模块，用删除测试、深度评估和范围检查判断模块是否值得保留，并标注为 new 或 deepening。接着映射依赖，按进程内、可本地替代、远程但自有、真正外部四类决定集成策略，原则是除非至少有两种实现（通常为生产与测试），否则不引入 seam。再设计接口，减少入口点、简化参数、注入依赖、优先返回结果而非副作用，并记录调用方必须知道的不变量、顺序、错误模式等。对最关键模块至少设计两种差异明显的接口方案并比较取舍。最后做领域文档检查，仅当决策难以逆转、缺乏上下文会令人意外且存在真实取舍时才创建 ADR，并输出 NOTES.md 与 tech-spec.md。
使用方式：作为技能在 aiops 流程中调用，输入包括 grill 结论、CONTEXT.md 领域词汇表、docs/adr/ 现有 ADR、.scratch/<feature>/VERDICT.md 以及可选的代码图谱。全程使用 design-vocabulary.md 的术语（module、interface、depth、seam、deletion test、leverage、locality），避免使用 component、service、API、boundary 等词。
适用场景：需要从需求结论形成架构设计、模块划分、接口契约与风险清单的工程任务。
限制：不写实现代码，只允许接口签名与伪代码；每个设计决策必须列出至少一个被拒绝的替代方案及原因；模块命名须使用 CONTEXT.md 领域术语，新术语需补充进 CONTEXT.md；ADR 保持可选；存在阻塞性开放问题时必须标记，planner 在解决前不能启动。资料未提供具体收费、价格或平台支持信息。