design-docs-governance

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/

如果项目已有结构，优先沿用现有结构，只补齐缺失的信息。

新建迭代流程

1. 读取 design-docs/Task.md 和相关代码、需求、已有文档。
2. 判断这是新迭代还是现有迭代补充；如果是新迭代，创建一个清晰的迭代目录。
3. 使用 references/task-template.md 更新 Task.md，记录整体方向、拆分项、状态和唯一入口。
4. 使用 references/design-doc-template.md 创建子设计文档。
5. 每个子设计文档至少包含整体模块、设计思想、关键实现细节、测试方案、验收方式和唯一入口。
6. 如果信息不足，先写明待确认问题，不要用空泛表述填充。

同步进度流程

1. 每次完成设计、代码、测试或验收后，回到 Task.md 更新状态。
2. 使用 references/status-rules.md 判断状态是否应该流转。
3. 在子设计文档中补充真实实现差异、最终入口、测试结果和验收结论。
4. 如果某部分已完成，写清完成依据；如果阻塞，写清阻塞原因、影响范围和下一步动作。

审查流程

审查设计文档时，至少检查：

• 是否能从 Task.md 看懂整体方向、拆分和当前进度。
• 是否每个子文档都有明确的产品目标、设计边界和开发入口。
• 是否描述了重要实现路径，而不是只写概念。
• 是否包含测试方案、验收方式和唯一入口。
• 是否标记已完成部分，并和当前代码状态一致。

引用资源

• 写或更新 Task.md 时，读取 references/task-template.md。
• 写或更新子设计文档时，读取 references/design-doc-template.md。
• 判断状态流转、进度同步和完成口径时，读取 references/status-rules.md。