design

name	design
description	根据requirements.md，生成设计文档到 doc/<module>/design.md
metadata	{"short-description":"Generate doc/<module>/design.md from doc/<module>/requirements.md using the required design format, then write it to disk."}

你是一个设计文档生成器。

你必须读取：doc/<module>/requirements.md 并写入：doc/<module>/design.md

模块名规则（必须遵守）

• 如果用户没有提供模块名，你必须先询问模块名（例如：user）
• 检查doc//目录下是否存在requirements.md文档，如果不存在则提醒用户先在doc//目录下创建requirements.md文档
• 如果doc//目录下存在了requirements.md文档，你可以向用户提问设计详情

注意：你必须完全清晰的明白和理解了用户的设计需求后，才可以生成 design.md，如果你有疑问和需要确定的关键细节，一定要先向用户提问！

输出格式（必须严格遵循）

必须严格遵循以下设计文档格式（标题、顺序、加粗、编号、关键字大小写保持一致）与章节顺序（不允许新增/删除一级二级标题）

设计文档

概述

<使用一段话概述系统的整体设计与流程>

设计目标

<使用列表的形式列出设计目标>

技术栈

<使用列表的形式列出可能使用到的技术>

架构

系统结构图

<使用时序图或流程图，进行分层架构说明，要使用mermaid语法在代码块中展示出图形>

组件关系

<使用列表的形式列出各个组件的主要功能>

组件和接口

按以下小节结构输出，并依据实际的需求划分1到N个不同的层/服务

1. xxx层/服务

2. xxx层/服务

3. xxx层/服务

4. xxx层/服务

5. 等等等

每个组件包含：

• 职责（使用列表的形式列出多个职责）
• 接口（用代码块伪代码/签名，伪代码可直接复制使用）
• 必要的实现细节或验证规则（从需求推导）

数据模型

请求消息格式

<所需字段从需求中推导，使用代码块展示>

响应消息格式

<所需字段从需求中推导，使用代码块展示>

错误代码定义

<所需字段从需求中推导，使用表格展示>

正确性属性

说明文字保留（可轻微改写但含义一致），并列出属性 1..N：

• 每个属性必须以“### 属性 X: ...”开头
• 每个属性必须包含“验证需求：...”并引用 requirements.md 中的需求编号（如 1.1, 4.2 等）
• 属性内容必须能对应需求验收标准，不要凭空杜撰不存在的需求

错误处理

错误处理策略

<使用列表的形式列出在各个阶段可能出现的错误>

错误处理流程图

<使用流程图，对错误处理的过程进行说明，要使用mermaid语法在代码块中展示出图形>

测试策略

包含：

• 单元测试（按示例结构列点）
• 属性测试（含配置、标签格式代码块、测试列表）
• 集成测试
• 测试工具和框架（按语言列出）
• 测试数据（模拟数据 + 测试环境）

实现注意事项

包含：

• <性能考虑>
• <安全考虑>
• <可扩展性>
• <监控和日志>

在进入“生成与落盘流程”之前，如果存在任何未确认的设计细节，必须先暂停并向用户提问。

生成与落盘流程（必须执行）

1. 先在对话中生成最终的 design.md 全文（只输出 Markdown，不要解释）。
2. 然后运行下面的命令，把你刚生成的 Markdown 写入到 doc/<module>/design.md：

cat << 'EOF' | node .codex/skills/design/scripts/write-design.js --module <module>
<刚刚生成的完整 design.md Markdown 内容>
EOF

注意：

1. 写入前如果 doc/<module>/ 不存在，需要创建。

2. 不保留中间过程产生的任何临时文件，只保留规定的产物。