Design: $ARGUMENTS
严格按照 docs/design-process.md 执行每个步骤——该文件是本技能的规则所在，此技能仅编排任务顺序。若两者冲突，以该文件为准。
- 是否需要设计 — 对照
docs/design-process.md第 1 节表格进行评估- 不需要：用一行说明原因，然后回退到
new-feature - 不确定：先询问用户
- 不需要：用一行说明原因，然后回退到
- 开始（第 3.0 节）：创建 epic issue（标签
design），分支docs/<id>-design-<slug>，复制docs/design/template.md→docs/design/<slug>.md（命名为system.md或<epic 编号>-<slug>.md），设置status: draft，并在docs/design/README.md中新增一行 - 阅读后再提问：
CONTEXT.md、docs/adr/、docs/architecture.md、docs/design/下的其他设计文档——自己能查到的信息自己去查，不要提问 - 多轮访谈（第 3.1 节），格式为
Qn — 主题: 问题+ 每个问题给出建议: …，每轮必须包含 1–2 个边缘案例——完整遍历 A–H 分支（第 3.2 节），并在审批点 1、2（系统设计）、3 停下来等待用户 - 每轮结束后写入文件：更新设计文件中的对应章节，在
CONTEXT.md中添加新术语，在docs/adr/中创建状态为proposed的 ADR（并更新索引），若容器或外部系统发生变化则更新docs/architecture.md中的 C4 模型 - 检查（第 3.3 节）：必须通过
make docs-check（若仓库 Makefile 中尚无该目标，则运行python3 <web-template 路径>/scripts/check-docs.py <repo>——对于 Hermes 团队：/home/opc/projects/web-template）并自行完成检查清单，然后将状态设为proposed - 仅含文档的 PR：标题格式
docs(design): <slug>，正文包含Refs #<epic>、未决选项的摘要以及## CHANGELOG节（内容为-）——禁止包含代码，禁止合并 - 审批（第 3.4 节）：当审批者提交后，将状态更新为
approved并添加approved-by字段，同时在同一个 PR 中将 ADR 状态改为accepted（需通过make docs-check），然后由审批者合并 - 合并后（第 3.5 节）：按照第 13 节主题逐个创建子 issue，每个子 issue 链接到 epic 和设计文件——编码工作从
new-feature开始