Ugreen 文档协作流

这是产品、立项人和各设计 owner 的统一文档协作入口。先判断用户要解决的问题，再按需读取并执行对应子 skill 的 SKILL.md；不要把三个流程同时执行，也不要重复实现子 skill 已定义的规则。

四个独立子 skill 位于：

• skills/prd-readiness-review/SKILL.md
• skills/testcase-alignment-review/SKILL.md
• skills/doc-context/SKILL.md
• skills/update-doc/SKILL.md

路由表

判断顺序

1. 用户说“检查 PRD”“需求清不清楚”“能不能给研发” → 使用 prd-readiness-review。
2. 用户说“检查测试用例”“用例覆盖 PRD”“需求和用例对齐”“还有哪些没测” → 使用 testcase-alignment-review。
3. 用户说“立项”“建目录”“文档清单”“台账”“接受新版”“dismiss” → 使用 doc-context。
4. 用户明确说正文已经修改完成，要通知下游、追加变更记录或生成 chg-XXX → 使用 update-doc。
5. 同一请求跨越多个阶段时，按实际先后顺序逐个执行，并在每次外部写入前遵守对应子 skill 的确认纪律。
6. 意图仍有歧义时，只询问会改变路由选择的必要信息，不要默认执行钉钉写操作。

能力边界

• prd-readiness-review 只审产品业务信息，不审接口、存储、技术选型等研发实现。
• testcase-alignment-review 只审测试用例是否忠实覆盖 PRD，不编写用例、不修改 PRD，也不审研发技术方案。
• doc-context 管文档工作区、团队清单和个人台账，不替 owner 修改规格正文。
• update-doc 只在正文修改完成后追加正式变更记录，不修改任何人的 accepted，也不维护团队文档清单。
• 钉钉读写由共享脚本通过 dws 执行；dws 不可用时不得伪造成功结果。

扩展约定

以后增加新的文档协作能力时：

1. 在 skills/<new-skill>/SKILL.md 新增独立子 skill；
2. 如需脚本或共享库，放到包根的 scripts/、lib/ 或 schemas/；
3. 在本路由表补充一行“用户意图 → 子 skill”；
4. 保持子 skill 的 description 精确，外层入口只负责分流，不复制完整执行规则。