Menü
当用户需求已基本明确、希望生成结构化的规格文档、或明确说"写规格""写 spec""整理需求"时使用。基于 EARS 方法生成需求规格说明。如果需求还很模糊，应先使用 sd-brainstorm 收敛。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | sd-write-spec |
| description | 当用户需求已基本明确、希望生成结构化的规格文档、或明确说"写规格""写 spec""整理需求"时使用。基于 EARS 方法生成需求规格说明。如果需求还很模糊，应先使用 sd-brainstorm 收敛。 |
你正在帮助开发者使用 EARS（简易需求语法方法）创建一份结构化的需求规格说明文档。
如果你判断用户当前给出的还只是模糊想法，尚不足以直接写正式规格，先建议或切换到 sd-brainstorm 收敛需求，再回到本 skill。
角色：资深需求工程师（EARS 专家）
核心职责：将功能描述转化为一份全面、结构化的需求规格文档，使用 EARS 语法清晰定义需要构建的内容。
EARS 模式：
<系统> 应 <响应>，始终适用的需求当处于 <状态> 时，<系统> 应 <响应>，特定状态下的行为当 <事件> 发生时，<系统> 应 <响应>，由事件触发的行为若 <功能存在>，<系统> 应 <响应>，可选能力若 <条件>，则 <系统> 应 <响应>，异常处理初始请求来自当前用户对话。
操作：
sd-brainstorm 产出的设计共识（包含目标、参与者、核心流程、边界与异常、范围外、实现方向），直接以此为输入，跳过下方的澄清提问，进入阶段二目标：产出完整的 EARS 格式规格文档
操作：
../../templates/spec.md（相对于本 SKILL.md）TODO、TBD、待定、后续补充 等占位表达目标：保存前确保规格文档准确捕捉需求
操作：
目标：保存最终确认的规格文档
操作：
user-auth、payment-flow.claude/specs/：
mkdir -p .claude/specs
.claude/specs/[功能名称].mdsd-dev skill 开始实现规划与开发操作：
.claude/specs/[功能名称].mdsd-dev skill 开始实现遇到以下情况时，停下来重新评估：
当用户希望根据已有规格文档推进实现、说"开始开发""实现这个功能""按 spec 来做"时使用。读取 spec、探索代码库、生成任务计划，并在用户确认后执行开发。如果没有 spec 文档，会引导用户先创建。
生成 AI 图片，支持文字描述生成图、参考图片、多种宽高比和批量生成。当用户要求"生成图片""画一张图""生成一张 XX 的图""create an image""generate a picture"、或任何需要 AI 生图的场景时使用。这是通用图片生成能力，wj-visual 和 wj-xhs-images 等 skill 在生图时会调用此 skill。
生成单张图片（文章封面、信息图、海报、技术架构图、学术配图、概念插画等所有单图场景）。当用户要求"生成封面图""做个封面""画张信息图""infographic""做张海报""banner""editorial cover""画个架构图""系统架构图""ER 图""时序图""流程图""学术配图""论文配图""pipeline figure""神经网络架构图""graphical abstract""knowledge card""高密度信息大图""可视化笔记""做张图说明 XX""治愈系插画""概念场景图"或任何需要单图输出的场景时使用。即使用户只说"封面""cover""信息图""做张图""画张图"也应触发。多张图系列（小红书图文）请用 wj-xhs-images。
生成小红书图文系列（1-10 张卡通风格图片）。当用户提到"小红书图片""XHS""RedNote""做套图""图文笔记""knowledge series"时使用。即使用户只说"做几张小红书的图"也应触发。单张信息图请用 wj-visual。
当用户描述一个开发意图但不确定该从脑暴、写规格还是开发开始时使用。简单想法、信息不足、需要思考或脑暴时进入 brainstorm；已有较详细 PRD、技术文档、需求说明或明确规格素材时进入 write-spec；如果已经有 spec 文档并明确要推进实现，可以进入 dev。workflow 不直接进入 review/debug/parallel。
当用户只有模糊想法、功能边界不清晰、在多个方案之间摇摆、或说"我想做一个...""不太确定怎么做""帮我想想"时使用。通过逐步提问把想法收敛为可写规格的设计共识，而非直接跳到规格编写或代码实现。