docs-governance git:20261011.ee7c4b9A

Immutable. This exact content never changes and is served at /api/v1/blob/d68dcbbfa406a71a.

---
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 的方法论。

## 单项路由

| 用户意图 | 路由到 |
|---|---|
| 采集项目健康证据、核对验证入口与 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 | `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` 处理，难回退决策按 `context-and-decisions` 处理。
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 管任务状态和排期；不要复制进路由或数据库。
- 不因为用户说“治理”就一次性创建所有可选文档和目录。先发现现有事实载体，再按预警信号懒创建。