/docs-governance

name: docs-governance
description: >-
  作为面向长期 AI 协作项目的知识、决策与验证治理总入口，把优秀 Agent 的一次性工作沉淀为可继承、可验证、可持续演进的项目集体能力；根据用户意图把任务路由到活文档、领域上下文与 ADR、变更影响、接口契约、测试资产、模块回归或闭环设计能力，并在大型变更中组织正确顺序。用于用户只说“文档治理”“项目治理”“帮我整理项目知识”“改完怎么收尾”而未指定具体 Skill，或需要跨多项治理能力时。English triggers: docs governance router, project knowledge governance, documentation workflow, governance workflow.

文档治理总路由

定位

> **把优秀 Agent 的一次性工作，沉淀为项目可继承、可验证、可持续演进的集体能力。**

本插件不是让 Agent 多写文档，而是治理长期 AI 协作中的项目知识、关键决策与验证证据：让后续 Agent 能恢复上下文、沿用已确认约束、复核结果，并把新的有效做法继续沉淀回项目。

先判断意图，再读取并执行对应 Skill。不要在本路由复制各 Skill 的方法论。

单项路由

| 用户意图 | 路由到 | |---|---| | 新建核心模块、补齐模块文档或维护模块约定，无须点名 Skill | `module-governance`；讨论只读，普通 Bug／样式不启动建档 | | 审计核心模块知识入口覆盖 | `docs-audit`，仅报告；边界核对使用 `architecture-docs` | | 检查治理规则应放在入口、Skill、附件、脚本还是 Hook，识别散落的可复用工作流 | `agent-workflow-governance`，默认只读交付证据与建议 | | 采集项目健康证据、核对验证入口与 CI 衔接 | `living-docs-governance` 的“项目健康证据采集” | | 编写或优化 Skill、Agent 入口及 AI 读取的文档 | `writing-for-agents`；事实核对仍走审计流程 | | 规划、整理或只读审查文档目录、归属与读取入口 | `docs-structure` | | 生成、精简或审查 AGENTS.md / CLAUDE.md，明确项目规范和产品读取入口 | `agent-entrypoints` | | 产品文档管理员、来源登记、需求池／编号／版本、十阶段管理与产品审查 | `product-evolution`；Claude Code 可由 `product-docs-manager` 执行 | | 新项目、讨论后项目或已有项目首次配置产品文档包与 Agent 入口 | `living-docs-governance` 的“统一 setup”模式；Claude Code 使用 `/governance-setup`，`/governance-init` 是兼容别名 | | 本次改动后的文档同步、整理、收尾或交接 | `docs-maintenance` | | 从对话、文档变更与审计记录复盘文档管理经验 | `docs-retro` | | LOG 管理或复盘 | `living-docs-governance` | | 是否需要架构文档，生成、完善或审查模块分工、状态归属、依赖与核心流程 | `architecture-docs` | | 领域术语、`CONTEXT.md`、架构或数据库决策、ADR | `domain-modeling`（Matt 原文与本地适配）；`context-and-decisions` 仅兼容旧调用 | | 修改前判断牵连面、迁移、回滚、实施后对照 | `change-impact` | | 前后端或服务间接口 | `contract-first` | | 测试资产、成功标准证据、Bug→TEST-ID | `test-collaboration` | | 修改后验证本模块及下游 | `module-regression` | | 文档散乱、导航、时效、重复主源与当前／历史区分的只读审计 | `docs-audit` | | 指定 spine/context/adr/artifacts/full 的兼容审计 | `living-docs-governance` 的审计模式 | | 设计可判定目标和反馈回路 | `loop-design-check` |

模块变更流程

修改模块功能、公共接口或共享数据时，当前 Agent 负责串起以下流程，无须用户逐个点名 Skill。只读请求保持只读；纯排版等小改动只做相关检查，不展开整套流程或另写报告。

1. **改前看影响**：记录任务起点及已有未提交修改，按 `change-impact` 查真实调用方、数据与契约，确定受影响模块、候选文档和验证命令。需求不清先定位已确认 Spec／Issue；跨端接口按 `contract-first` 处理，难回退决策按 `domain-modeling` 处理。 2. **实施并核对范围**：完成获准修改，对照实际 diff 补查新增影响。任务开始时已有修改须单独区分，不能全归为本轮；出现新的需求或授权冲突时先澄清该部分。 3. **验证本模块与下游**：按 `module-regression` 执行影响分析确定的回归；测试点与证据需要维护时调用 `test-collaboration`。本次引入的失败由当前改动者修复并复验；旧失败、环境阻塞与未跑范围分别说明，不能把局部通过说成全部通过。 4. **同步文档并交付**：需编写或优化面向 AI 的文档时，先按需读取 `skills/documentation/writing-for-agents/SKILL.md`，传入已确认材料、原文与获准范围，核对改写含义后再同步。将任务范围、实际 diff、影响清单和回归结果交给 `docs-maintenance`；复用同一基线与有效审计结果，补查实际变化，不重复推导。最终简述改了什么、影响谁、跑了什么、同步了哪些文档及剩余缺口。回归受阻仍可记录已知状态，但不能把功能写成验收通过。

接入项目入口

由 `agent-entrypoints` 在已授权配置的共享入口保留一句路标：

> 修改模块功能、公共接口或共享数据前，读取 docs-governance 的“模块变更流程”，完成影响分析、实施后对照、相关回归和文档同步后再交付。

将 Skill 名替换为实际可读取路径；外部插件使用完整路径。setup 通过 `agent-entrypoints` 接入；已有项目只补这条路标，不复制流程正文。Skill 存在不等于自动运行：这是 Agent 执行约定，未安装 Hook／CI 就不声称强制触发。

边界

• 让 `CLAUDE_MAP.md` 管项目知识位置，让 `ARCHITECTURE.md` 管当前 Module 结构；本 Skill 只管插件能力路由。
• 让 Spec/Issue 管业务成功标准，Issue Tracker 管任务状态和排期；不要复制进路由或数据库。
• 不因为用户说“治理”就一次性创建所有可选文档和目录。先发现现有事实载体，再按预警信号懒创建。