official-doc-revise

name	official-doc-revise
description	新 official-doc-write 架构的 section 级回修 skill。依据 section review 回修一个 section 草稿，不修改矩阵、其他 section 或装配稿。
allowed-tools	Read Write Edit Bash

小节回修规则（official-doc-revise）

本 skill 只服务新的 /official-doc-write 架构。每次只回修一个 section：

project-workspace/<project-slug>/drafts/sections/<section-id>.md

不得使用旧工作流、旧章节提示词、旧写作规则、旧参考资料目录、旧装配目录、official-doc-research 或任何外部调研流程。

必读文件

编辑前必须读取：

• project-workspace/<project-slug>/reviews/<section-id>-review.md
• project-workspace/<project-slug>/context/section-plan.md
• project-workspace/<project-slug>/context/evidence-ledger.md
• project-workspace/<project-slug>/context/traceability-matrix.md
• project-workspace/<project-slug>/context/artifact-plan.md
• project-workspace/<project-slug>/drafts/sections/<section-id>.md
• .claude/templates/full-research-project-artifact-blueprint.md

如果 Must Fix 涉及来源原文，还要读取：

• project-workspace/<project-slug>/inputs/framework.md
• project-workspace/<project-slug>/inputs/research-report.md
• project-workspace/<project-slug>/inputs/reference-supplement.md

编辑范围

只能编辑：

project-workspace/<project-slug>/drafts/sections/<section-id>.md

不得编辑：

• context/traceability-matrix.md
• context/section-plan.md
• context/evidence-ledger.md
• context/artifact-plan.md
• 其他 section 草稿
• 章节装配稿
• assembled/formal-draft.md

如果 review 暴露矩阵缺口，不得自行发明关系。正文保持保守，并报告主入口需要修复矩阵或补充输入。

回修顺序

1. 先修全部 Must Fix，再处理 Should Fix。
2. 从正式正文中删除内部编号。
3. 删除 section 文件末尾的 --- 元数据块，以及 section_id:、evidence_used:、traceability:、task_binding:、char_count:、status: 等交接字段。
4. 恢复 section-plan.md 要求的 section 标题和结构。
5. 将无支撑判断回到 evidence-ledger.md 或三份输入。
6. 对编造或过度精确的事实，改为 待补充 或保守表述。
7. 用自然语言修复关联表达，但不得暴露原始 ID。
8. 字数不足或深度不足时，在当前 section 边界内扩写。
9. 将清单式、标签式文字改为正式公文自然段。
10. 第一章、第四章出现 ####、##### 或更深标题时，改为“第一，”“第二，”“任务一：”“成果一：”“在……方面”等自然段开头，不新增计划外标题。
11. 如果 review 指出第一章内容错位，必须把国外工具和平台内容移出建设背景、国内现状，把国内政策和主体内容移出国外现状；不能在原 section 内硬改成似是而非的表述。
12. 如果 review 指出第四章内容错位，必须按 section 责任回修：研发内容写任务，技术路线写流程，预期成果写成果，应用推广写推广，联合研发写协同集成，成果管理写受控复用。
13. 如果 review 指出 ch04-major-issues 泄露痛点或任务 ID，必须删除所有 pain_01、task_01、major_issue_01 等后台编号，并改成自然语言问题承接。
14. 如果 review 指出 ch04-major-issues 存在“来源于第一章痛点分析中的……”或“该问题主要由任务一予以承接”，必须改为“当前……主要表现为……，该问题制约了……，需要通过……形成……能力”。
15. 如果 review 指出“问题一：……问题。”重复句式，必须删除标题中的第二个“问题”，改为“问题一：报告编制效率和质量一致性不足。”这类表达。
16. 如果 review 指出第一章抽象 AI 化表达，必须改为具体公文表达，落到“对象、建设动作、形成能力、支撑意义”。
17. 如果 review 指出次要章节标题层级错误，必须把 ### （一）... 改为 ## （一）...，把单位或制度分项改为 ### 1. ...。
18. 如果 review 指出第五章、六章、八章自造小节，必须删除这些小节标题，回到章级正文和模板表格；第五章出现 ## 子课题...阶段任务说明、## 项目验证阶段任务说明、## 项目总结阶段任务说明 时，必须删除标题，将内容并入表前说明、表后说明或年度任务安排表。
19. 如果 review 指出第二、三、七、九、十章结构不符，必须按 .claude/templates/full-research-project-template.md 的固定标题树重排，不得自由改题。
20. 删除任何模板外“小结”标题，必要收束内容改为自然段。
21. 如果 review 指出第二章内容偏薄，必须保留财务、股权、人员、设施、研发投入等模板项；没有事实时写 待补充，不得删除或泛化。
22. 如果 review 指出第三章能力支撑不足，必须改成“单位能力 -> 支撑任务 -> 形成保障”的句式。
23. 如果 review 指出第五章表格不符，必须改为“年度 | 年度任务 | 年度考核指标 | 重要任务的时间节点”的年度任务安排表，并删除 task_01、work_package_01、output_01 等内部 ID。
24. 如果 review 指出第六章分工表字段不足，必须恢复任务负责人、目标、具体任务内容、年度任务分解、考核指标、年度考核指标与重要任务的时间节点、投资额、承担任务占比等模板字段；缺失事实写 待补充。
25. 如果 review 指出第九章测算越界，必须删除“假设每型船……”等自行推导收益句，改为“测算参数待补充，暂作定性分析”，并删除所有 output_01、benefit_01、application_01 等内部 ID。
26. 如果 review 指出第十章风险偏通用，必须把技术风险绑定第四章技术路线，把组织协同风险绑定第六章分工和第七章管理机制，把资金风险绑定第八章资金安排。
27. 如果 review 指出必需图表缺失，在当前 section 正文中按图表蓝图位置补入 artifact-plan.md 指定的正式编号图题或表题。
28. 删除过程说明、提示词文本、review 说明和自我指涉内容。
29. 如果 review 或 style_check.ps1 命中 填补空白、唯一可行路径、国际先进水平、显著提升、大幅提升、形成...闭环 等表达，必须改为稳健公文语体：写清具体对象、建设动作、能力变化和支撑意义，不得仅替换同义口号。
30. 如果 review 或 style_check.ps1 命中中英文术语污染，必须优先中文化表达；必要英文缩写、软件名或文件格式只保留一次括号说明，不得在同一段连续堆叠。

字数回修

如果 review 指出 section 低于最低字数：

• 只能在现有 section 边界内扩写。
• 增加机制、对象、输入输出、验证、应用、风险边界和依赖关系说明。
• 不得新增计划外标题或无关背景凑字数。
• 不得重复同一价值判断。

技术类 section，尤其是 ch04-rd-content 和 ch04-technical-route，扩写必须增加技术深度：

• 数据对象与数据流
• 模型或规则方法
• 功能模块
• 接口与集成路径
• 验证流程
• 应用场景
• 受控复用或供应链安全边界

文风回修

将以下问题改为连续公文段落：

• 密集清单
• ####、##### 或更深 Markdown 标题
• **技术描述**、**作用**、**子任务** 等标签
• 口号化表述
• 无支撑的 领先、首创、填补空白
• 唯一可行路径、国际先进水平、显著提升、大幅提升、全面提升、形成闭环 等强宣传或口号化表达
• 机械过渡词
• 不完整公式
• 中英文术语污染；第四章可保留必要技术词，但必须改成中文为主、英文括注的正式写法
• 缺失或无正式编号的图表
• “来源于第一章痛点分析中的……”
• “该问题主要由任务一予以承接”
• “问题一：……问题。”
• “技术能力闭环”“应用生态框架”“可复制推广的工程范式”“智能化应用格局”等抽象 AI 化表达
• 第五章工作包表替代年度任务安排表
• 第五章 ## 子课题...阶段任务说明 或 ## 项目验证阶段任务说明 等阶段标题
• 第九章 output_01、benefit_01、application_01 泄露
• 缺少测算参数时使用“假设每型船……”推导收益

改写后的段落应覆盖：

• 对象
• 问题
• 动作
• 机制
• 输出
• 验证或应用

证据规则

• 不得新增外部事实。
• 不得调用调研工具。
• 不得要求联网搜索。
• 三份输入不能支撑的事实，使用 待补充 或保守表述。
• 正式正文不得暴露 FW-001、RR-001、RS-001、task_01、pain_01、work_package_01、budget_item_01、risk_01 等编号。

交接

编辑完成后，section 必须回到 official-doc-review 重新复核。回修交接说明应写清：

• 已编辑文件
• 已处理的 Must Fix
• 因输入不足或矩阵缺口仍保留的问题
• 当前中文字符数
• 是否已准备进入 re-review

不得自行宣称 section 已通过。只有 official-doc-review 可以通过 section_status: approved 批准。