project-doc

name	project-doc
description	审查和维护项目明确声明的长期工程文档，收录、删除、合并、迁移和压缩稳定工程事实，并验证权威归宿、入口与引用。用于工程边界、契约、运行链路或验证要求变化后的文档同步，以及长期文档重复、错位、过时或结构性治理；不用于开发 Agent 行动规则与技能、产品运行时 prompt 或 skill、普通 Markdown、临时材料、生成物或单纯文案润色。

项目长期文档治理

以减少未来维护误判为目标，使每条稳定工程事实只有一个权威归宿。优先删除、合并、迁移和压缩，再补写真实缺口。

默认完成必要的文档修改、验证和交付；请求仅要求审查、检查、解释、诊断、计划或明确只读时，只报告结果，不把只读请求扩大为写入。

确定治理边界

1. 读取仓库级行动规则和文档索引，确定项目声明的长期文档集合、事实归宿和验证入口，不假定固定目录、文件名、技术栈或文档数量。
2. 先判定任务是否直接治理该集合，或是否因实现变化需要同步该集合；两者均不满足时停止应用本技能的治理流程，改用任务对象所属工作流。
3. 技能和指令按消费它们的运行时分类：开发 Agent 的行动规则与技能属于开发控制面，产品内置 prompt 与 skill 属于产品实现；二者都不因文本形式进入长期文档集合。
4. 行动规则、开发技能、产品运行时资源、代码、测试和配置可以作为事实证据或长期文档引用检查面；读取或修改这些材料不代表对其应用文档收录、迁移、合并或压缩规则。
5. 项目未声明完整体系时，以现有文档入口、引用和用户指定的长期文档目标为范围，不为追求形式完整而新建文档拓扑；同一信息涉及多个归宿时拆开，其它文档只保留定位所需的短引用。

收录闸门

一条信息必须同时满足以下条件才进入长期文档：

判断问题	不满足时
它会改变未来维护者对落点、边界、契约、行为或验证的判断吗？	删除
它描述当前稳定事实，而不是历史过程、本次改动或临时状态吗？	删除或改写
它需要跨文件或跨层重建，或承载非显然理由、公开契约、关键入口吗？	删除
能否为它确定一个权威归宿？	拆分、合并、迁移或列为未决

通常不收录可从单个局部实现轻易看出的事实。

新增内容必须替换、合并、迁移或压缩既有信息，或补上会导致维护误判的真实缺口。“更完整”“更保险”“顺便提醒”不是收录理由。

选择证据

按事实类型选择最接近权威来源的证据：

事实类型	优先证据
当前运行行为	实现、行为测试、运行配置
公开或结构化契约	schema、类型、协议定义、契约测试
治理规则、入口和验证要求	仓库级行动规则、配置、脚本、文档索引
用户要求改变的事实	当前任务要求及完成后的实现结果

证据冲突时回到拥有该事实决策权且最接近实际行为的来源；仍无法判定时列为未决，不写成稳定规则。不要覆盖无关改动，也不要删除工具链入口、外部流程入口、用户指定保留内容或生命周期不明的材料。

执行顺序

1. 定义本轮信息集合，包括规则、入口、链接、表格、章节和叙事。
2. 为每条信息记录证据、权威归宿和处理结论：删除、合并、迁移、压缩、补写、保留或未决。
3. 先删除不满足收录闸门的内容和重复正文。
4. 再合并重复规则、迁移错位内容、压缩低密度叙事，最后补写稳定缺口。
5. 检查仓库入口、脚本提示、测试断言、技能提示和其它文档中指向长期文档的引用；只更新受文档入口变化影响的引用，不以此治理承载引用的材料本身。
6. 执行项目声明的相关验证并回看 diff，确认没有新的并行规则、失效入口、历史叙事或无关改动。

结构性任务应优先体现删除、合并、迁移或压缩；现状已经干净时说明证据，不强行制造改动。

必须重组的信号

• 同一主题在多份长期文档中重复出现。
• 新规则只能靠“补充、另外、注意、同时”塞入既有段落。
• 章节仍按旧目录、历史来源或已失效系统形态组织。
• 表格和列表持续增长，却没有改变维护判断。
• 专题文档承载行动规则，或把可选产物写成恒定入口。

遇到这些信号时重写信息块，不局部追加一句。

交付

按实际结果汇报信息集合变化：

• 删除：不合格信息、重复正文或旧入口。
• 合并：收成唯一权威的重复规则。
• 迁移：移动到正确归宿的信息。
• 压缩：改成判断规则的长段、表格或历史叙事。
• 补写：新增缺口及其证据。
• 保留：看似可疑但仍保留的理由。
• 未决：证据不足而未写入的问题。
• 验证：文档集合、链接、引用、项目验证和 diff。

明确只读的请求改为报告位置、证据、影响和建议。