将 PRD 翻译成「可独立测试」的功能设计文档。文档的下游使用者包括开发者、评审者、测试者,且三方互相隔离(测试者看不到开发者写的代码),所以必须把行为、状态、接口、数据、权限、异常、验收标准全部显式化,让测试者能独立从文档推导用例。输入是一份已写好的 PRD 文档,输出是一份完整的 Markdown 功能设计文档,保存到当前项目的 `markdown/` 目录。适用于:写功能设计文档、技术设计文档、Tech Design、详细设计说明书、FDD、Functional Design Doc、Detailed Design、模块设计文档、把 PRD 翻译成开发设计、把需求拆成可开发/可测试/可评审的规格。
93%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
测试者看不到开发者的代码。功能设计文档是三方的唯一共同依据:
| 角色 | 从文档里读什么 | 看不到 |
|---|---|---|
| 开发者 | 接口契约、数据模型、行为规则、边界条件 | — (有文档) |
| 评审者 | 设计原则、权衡取舍、验收标准 | — (有文档) |
| 测试者 | 用例推导的完整基础 | 开发者的源代码 |
→ 文档必须把行为写死,不留给实现者自由发挥的空间;同时不规定实现细节(避免越界成架构图)。这条边界是这份文档的灵魂。
markdown/ 下,或用户提供的路径)。如果输入没有 PRD,先停下来问用户要 PRD,不要凭空白生成功能设计文档。
通读 PRD 并提取产物
按 references/feature-design-template.md 起骨架
深化关键章节(优先级从高到低)
references/api-spec-template.md,每个端点都给出:请求/响应字段表、错误码表、幂等性、限流、鉴权点。references/state-machine-template.md,每个实体都要画出状态转移图,包括非法转移。references/test-matrix-template.md,用维度(角色 × 操作 × 数据状态 × 环境)穷举测试面,测试者直接按矩阵写用例。验收标准必须可执行
自检(见下方质检清单)
保存
markdown/<topic>-feature-design-<YYYYMMDD>.mdmarkdown/<topic>-<diagram-name>-<YYYYMMDD>.svg,在文档中用相对路径引用。markdown/ 目录(不存在则创建)。<topic>-feature-design-<YYYYMMDD>.md,其中 <topic> 用 PRD 的主题拼音/英文 slug。references/feature-design-template.md — 完整模板(16 章节),骨架必读。references/api-spec-template.md — 接口契约子模板,深化"对外接口"章节时使用。references/state-machine-template.md — 状态机子模板,深化"状态机"章节时使用。references/test-matrix-template.md — 测试矩阵子模板,深化"验收标准"章节时使用。digoal/blog
7abecbf
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.