| name | design-docs-governance |
| description | 当用户要求创建、维护、审查或同步项目设计文档、功能迭代方案、design-docs、Task 进度、验收方案、唯一入口或人与 Agent 的协作协议时使用。该 Skill 指导 Agent 将大功能拆分为可落地的设计文档,并在代码实现、测试、验收后同步更新进度,保证产品、开发、设计与 Agent 对同一目标达成一致。 |
Design Docs Governance
使用本 Skill 时,把 design-docs 当作项目推进协议,而不是普通文档目录。每次大功能迭代都要先确认整体方向,再拆成可以独立设计、实现、测试和验收的小部分。
核心原则
- 先读取现有
design-docs/Task.md,确认当前迭代、状态、阻塞点和已完成部分。
- 先对齐目标,再写具体方案;先描述真实实现边界,再决定是否抽象。
- 设计文档要能让产品、开发、设计和 Agent 对同一功能达成一致。
- 已完成、变更、阻塞、废弃的内容都要及时回写
Task.md。
- 当代码实现、用户要求和设计文档不一致时,先指出漂移,再决定更新代码还是更新设计文档。
目录约定
默认使用以下结构:
design-docs/
├── Task.md
└── {迭代名称}/
├── 00-overview.md
├── 01-{模块或问题}.md
├── 02-{模块或问题}.md
└── assets/
如果项目已有结构,优先沿用现有结构,只补齐缺失的信息。
新建迭代流程
- 读取
design-docs/Task.md 和相关代码、需求、已有文档。
- 判断这是新迭代还是现有迭代补充;如果是新迭代,创建一个清晰的迭代目录。
- 使用
references/task-template.md 更新 Task.md,记录整体方向、拆分项、状态和唯一入口。
- 使用
references/design-doc-template.md 创建子设计文档。
- 每个子设计文档至少包含整体模块、设计思想、关键实现细节、测试方案、验收方式和唯一入口。
- 如果信息不足,先写明待确认问题,不要用空泛表述填充。
同步进度流程
- 每次完成设计、代码、测试或验收后,回到
Task.md 更新状态。
- 使用
references/status-rules.md 判断状态是否应该流转。
- 在子设计文档中补充真实实现差异、最终入口、测试结果和验收结论。
- 如果某部分已完成,写清完成依据;如果阻塞,写清阻塞原因、影响范围和下一步动作。
审查流程
审查设计文档时,至少检查:
- 是否能从
Task.md 看懂整体方向、拆分和当前进度。
- 是否每个子文档都有明确的产品目标、设计边界和开发入口。
- 是否描述了重要实现路径,而不是只写概念。
- 是否包含测试方案、验收方式和唯一入口。
- 是否标记已完成部分,并和当前代码状态一致。
引用资源
- 写或更新
Task.md 时,读取 references/task-template.md。
- 写或更新子设计文档时,读取
references/design-doc-template.md。
- 判断状态流转、进度同步和完成口径时,读取
references/status-rules.md。