关于 design-doc
根据项目简述和相关资料编写精简技术设计文档的技能。它记录设计选择与权衡，并在进入规格编写或实现前等待人工确认。
主要功能
- 01查阅简述及相关资料
- 02询问会影响设计的未知事项
- 03撰写 1 至 3 页设计文档
- 04记录备选方案、权衡与风险
- 05等待人工确认后再继续
适用场景
- 01记录拟议的技术设计
- 02比较设计方案及其权衡
- 03在实现前准备设计评审材料
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/design-doc确认已加载。
详细介绍
设计文档
- 阅读简述及任何链接的文档、代码或计划。只有在缺少的信息会改变设计时，才一次提出一个问题，并附上推荐答案。
- 使用下方模板编写
docs/<design-slug>/design.md，篇幅为 1-3 页。省略不适用的部分。 - 写完后停止。在人员确认之前，不要继续编写规范、计划或进行实现。
规则
- 让设计决策及其权衡易于审阅。
- 聚焦于代码之后无法说明的决策。
- 除非确切形式至关重要，否则不要复制完整的架构、API 或代码。
- 将 Status 留为 Draft，并将 Decision 留空。这两项都在审阅期间填写。
模板
# <标题>
**状态：** Draft | In review | Approved
**作者：** <姓名> **日期：** <日期>
## 概述
用一段话说明问题、提议的解决方案及其原因。
## 目标
此设计必须实现什么。
## 非目标
本设计明确不解决什么。
## 约束
技术、产品、迁移、兼容性、运维、成本或时间限制。
## 提议的设计
工作原理、结构、数据流和关键接口。仅在有助于阐明时使用图表。
## 备选方案和权衡
列出考虑过的每个方案，以及未采用的原因。这是审阅者评判的部分。
## 风险
可能出现的问题及缓解措施。
## 发布
如何发布：迁移、功能开关、回退。
## 待解决的问题
仍需做出的决策，以及由谁决定。
## 决策
审阅后填写：决定内容、决定者及决定时间。
评论
支持 Markdown