Gongwen Rectify skill

整改材料（gongwen-rectify）

巡视巡察、审计、督查、考核反馈问题后，整改材料一般要写三样：整改方案、整改台账、整改报告。本 skill 先把反馈意见拆成编号的问题清单，再建台账（问题、任务、责任三清单合一），方案和报告都从台账取材。报告里每条问题的状态、完成数和完成率必须与台账一致，“未完成写成已完成”属于虚假整改，会被问责。

适用范围

• 适用：
  • 整改方案：针对反馈问题制定的方案，附整改任务清单（高校审核评估、中小学督导评估等反馈问题的整改也在此列，编号沿用反馈的问题清单）；
  • 整改台账：问题、任务、责任三清单，可转 Excel；
  • 整改进展报告（月报、阶段报告）和整改情况报告；
  • 整改类或专项检查的自查报告：上级发了检查清单（自查表、评分细则），逐项自查；
  • 对账：核对已有的整改报告与台账是否一致。
• 不适用（转交）：

用户要的	转给
没有检查清单的一般工作总结、专项工作总结、迎检汇报材料	gongwen-report
以上级文件为依据的实施方案、贯彻落实方案和任务分解表	gongwen-implement
整改专题民主生活会对照检查材料、个人检视剖析材料；民主生活会、组织生活会查摆问题的整改措施和整改清单	gongwen-party
印发整改方案的通知、报送整改报告的请示或函	gongwen-draft
会议纪要、会议督办清单	gongwen-minutes
报表体检、多表合并、指标计算	gongwen-data
成稿全面核稿 / 排成 Word	gongwen-review / gongwen-format
装有行业包时：乡镇街道迎检汇报和迎检自查；医院九项准则（行风）自查、院感与安全检查整改、等级评审自评；高校审核评估自评报告；中小学督导评估自评报告	依次交 gongwen-grassroots、gongwen-hospital、gongwen-university、gongwen-k12；未安装的按本表其他行或本 skill 通用流程处理，不拒绝
说不清要写什么	gongwen

能调用其他 skill 的环境直接调用；目标 skill 未安装或在网页环境的，按 references/_shared/style/output-format.md 第四部分转交：给交接卡、“新开对话粘贴 dist/prompts/<skill 名>.md 继续”的说明和安装命令。其余回复中不写 skill 名，用描述性说法。

开工检查

1. 保密（references/_shared/guardrails.md 第一条）：
   • 有 Python 时，先运行 python scripts/secret_check.py <文件> 检查保密标识（含页眉页脚），命中即停。
   • 材料出现敏感信号时，才在起草说明末尾附一句（回复开头不放）：“提示：涉密材料请勿输入联网 AI。”普通材料不提示，同一会话只说一次。
   • 巡视巡察反馈意见、审计报告常带密级或“内部资料”“注意保密”“不得外传”等标识。读材料前先看版头和页眉：有这类标识的，按 guardrails 第一条第2款立即停止，不建台账、不复述、不摘录，说明原因和可以继续的条件。正文只是提到“保密工作”的不算。
   • 问题线索、信访件和被处理人员、举报人、患者、学生的个人信息不进台账和正文：被反映人、被处理人写“张某”，举报人一律不写；证件号、手机号、病案号、学号删去或写成“138****0000”；“保密提示”写明已替换。
2. 单位画像：读 .gongwen/单位画像.md，没有再找 ~/.gongwen/单位画像.md，用户粘贴了画像的按粘贴内容；再读 references/_shared/profiles/units/ 下对应文件和 references/units.md。没有画像的按 references/_shared/profiles/roles.md 第九节“无画像降级”。
3. 角色模式：按 roles.md 第一节确定。巡视巡察整改材料要报上级党组织，一律叠加严谨模式；要对外公开的整改情况也叠加严谨模式。
4. 交接卡：用户贴了【交接卡】的，按卡上的画像、模式、任务、本站和已确认事项开工，卡上有的不再问（output-format.md 第四部分）。更新交接卡时，“已确认”栏只抄用户确认过的内容，本站假设写进起草说明“假设”。
5. 不办的事：用户要求倒签日期、补记台账、把未完成写成已完成、编成效数字、把问题“写轻一点”、要“保证查不出是 AI 写的”的，说明原因（虚假整改会被追责，见 references/sources.md 第一部分），不照办，其余工作照常进行。

材料速查

材料	结构	篇幅（工具约定）	关键点	详细写法
整改方案	开头一段；整改目标、整改任务、工作安排、保障措施；附整改任务清单	正文不超过4000字，附件另计	问题照录，措施、责任、时限、成效标准逐条落实	references/plan.md
整改台账	三清单合一，列名见 ledger.md 第一部分	不限	唯一事实源；缺项写【待补】不留空	references/ledger.md
进展报告	统计句；本期进展；未完成问题；下一步	1000～2000字	先更新台账；超期如实写	references/writing.md 第一部分
情况报告	统计句；开展情况；逐条整改情况；长效机制；未完成和下一步	问题10个以内约3000字	逐条状态与台账一致	references/writing.md 第二部分
自查报告	自查基本情况；逐项自查；问题和原因；整改措施；附自查表	按清单项数	清单逐项对应，无记录不写“符合”	references/writing.md 第三部分

用户指定字数的，以 ±10% 为目标；素材不足时按 guardrails 第四条第2款，用工作性表述补足常规板块，不新增事实，不注水，起草说明一句话说明哪几部分是常规表述；【待补】不计入字数。

整改状态只用四种口径：已完成、立行立改、持续推进、长期坚持（临时可用“未启动”），认定标准见 references/status.md。

五条硬规则

1. 问题照录原文。台账“问题表现”和正文引用的问题，与反馈意见一字不差，限定词、数字、对象都保留；只把直引号等标点改成规范的全角写法；要短名的另设“问题简称”（正误例见 references/ledger.md 第三部分）。
2. 台账是唯一事实源。方案的任务、报告的状态、统计数和完成率，全部从台账取；报告与台账不一致时改报告，台账状态只凭用户提供的新进展和佐证更新。
3. 状态不升级。开会、发部署通知、印发方案只算部署，没有实际动作的仍记“未启动”（成效标准就是制度印发的，印发后有文号即可记已完成）；没有佐证不算完成；“基本完成”不是状态；长期坚持不计入完成数（正误例见 references/status.md 第三部分）。
4. 事实只来自用户，计划措施可按常规写足。追回金额、处理人数、制度文号、已采取的措施和进展，用户没给的标【待补：说明】（正文一般不超过 3 处，其余在台账标注），存疑的写进起草说明“待核实”一行；不写“取得明显成效”“群众满意度大幅提升”。尚未实施的整改措施，按问题和文种常规写成计划（“要”“将”），责任主体只用材料已有的单位、部门，不夹带新数字、项目名、制度名；调度频次、领导小组组成、专题民主生活会的具体安排只来自用户，“定期调度、对账销号”这类一般表述可写；示例里的日期、金额、制度名不得照抄。
5. 日期写实。进展日期写实际发生日，没给的标【待补：日期】。期限保留用户原话，不推算具体日；材料已写明年份的，补上年份写成带年份的原话期限（“2026年10月底前”“2026年年底前”“2026年11月中旬”），台账“完成时限”栏同样写法；“周五”“下周三”这类相对日期按今天推算为具体日期，起草说明注明；“本周”和没有月份的“月底”保留原话或标【待补：具体日期】。

工作流程

第一步　定任务

先填任务卡（材料、整改来源、发文主体、报送对象、期限、单位、角色模式），只作内部整理，不在对话里展示；期限按 references/plan.md 第五部分推算，如巡视整改自反馈之日起6个月；缺项的默认值合并成起草说明“假设”。

首轮交付（references/_shared/profiles/roles.md 第十节，任何模式都一样）：有反馈意见（原文或转述）、检查清单或台账，且至少有一个具体问题的，首轮就交付台账和正文；措施按常规写出，时限、数据等须用户提供的进台账标【待补】，不靠追问补齐。只有三种情形停下，并在回复开头说明属于哪种：一个具体问题都没有（给结构和补料清单）；用户要求先看问题清单或提纲；材料涉密（按开工检查第1条停止）。

提问不超过 3 个，放在回复末尾，不阻塞起草，顺序是：反馈意见原文 → 要写哪种材料、报给谁 → 措施和分工有没有初步打算。期限、画像、模式取默认值写进起草说明“假设”。用户说“直接写”的不再提问；用户已说明的事项不再问；说“按我们公司的格式”而没给模板的，按通行结构出稿，起草说明请其提供模板，不占提问名额。没有反馈原文、只有口头转述的，照转述写，起草说明“待核实”一行请对照反馈原文。

改已有稿：用户拿来已写好的方案或报告要修改的，不从头重写。

1. 先按反馈原文建台账：问题表现照录原文，措施、责任、时限、状态取自原稿，原稿没有的标【待补】。
2. 只改问题表述、状态说法和统计句；原稿的措施、责任领导、责任部门、时限、日期保持不变，确需改动的写进修改说明请用户确认。
3. 修改说明逐条列入“附：修改说明”表（问题N：原表述／改后表述／理由，如照录反馈原文、按台账口径），起草说明“修改说明”一行概括。
4. 有 Python 时，改完运行 rectify_check（加 --feedback）和 python scripts/change_guard.py 原稿.txt 正文.txt --json（用户要求结构不动的加 --keep-structure）：CHG-001（事实变化）只能是恢复的反馈原文内容，其余逐条恢复或在修改说明写明理由；CHG-004（结构变化）在结构不动时必须恢复；CHG-003（无规则依据的改动）按需列入修改说明供用户核对。措施、责任领导、责任部门、时限、日期、义务强度 change_guard 不一定识别，对照原稿人工核一遍。

第二步　拆问题清单

1. 按反馈意见的顺序和分类逐条拆，一条一个问题，从 1 编号；反馈原文有编号的沿用。一条里含几个问题的拆成子项 4-1、4-2。
2. 问题表现照录原文（硬规则 1）。
3. 核对条数：拆出的条数与反馈意见列明的问题数一致；不一致的在起草说明写明怎样拆的。问题线索、信访件只记件数。

第三步　建台账

按 references/ledger.md 建 整改台账.md，三清单合在一张表里，列名照用（“编号”“整改状态”两列供脚本对账）。

1. 原因、责任领导（写职务）、责任部门、时限、成效标准只用用户给的，缺的写【待补：说明】，不留空；措施缺的按硬规则 4 写成计划措施。
2. 措施按常规写出的，附“措施提示”（references/ledger.md 第四部分第1条）请用户核对；没给原因的，附“原因分析提示”（references/plan.md 第四部分），由用户选择后补入。
3. 时限写法按硬规则 5，用户给了具体日期的照写；巡视整改的时限不晚于集中整改期结束，期限依据见 references/sources.md。
4. 成效标准写成可检验的样子（制度印发、系统上线、资金退回、账实相符），数值目标没给的标【待补：目标值】。
5. 状态按 references/status.md 第二部分的判定顺序认定，方案阶段只开会、定分工时限而没有实际动作的，记“未启动”。
6. 写进展报告、情况报告前，先按用户给的新进展更新台账并另存新版本（xlsx 台账先转成 md），见 ledger.md 第六部分。

第四步　起草

按材料类型读对应文件：整改方案读 references/plan.md；进展报告、情况报告、自查报告读 references/writing.md。共同要求：

1. 开门见山：开头写何时收到哪个检查组的反馈、共几个问题，不写重要意义和“极端重要性”之类的表态。
2. 报告开头用统计句，数字从台账算（写法见 references/status.md 第四部分）。
3. 逐条写到某个问题时用“问题3”指称，编号与台账一致；段末写状态句，用台账口径（writing.md 第四部分）。
4. 没有全部完成的，不写“全部完成整改”“全面整改到位”；“将于……前完成整改”只能用于计划。
5. 措施用要求式措辞（“要”“于……前完成”），不用“建议”“可以考虑”；保障措施只写有主体、有动作的两三条。
6. 用户材料中加引号的做法名称、本单位提法原样使用；确需改写的，原句保留，建议列入提法核对清单请用户确认（guardrails 第二条第8款）。
7. 避开 AI 腔和防御腔（references/_shared/style/ 下 ai-tone.md、defensive.md）；“一是……二是……”、四字格照常使用。
8. 用户要对外公开的版本，按 writing.md 第六部分删减。

第五步　对账与自检

1. 对账：有 Python 环境时运行 python scripts/rectify_check.py 整改台账.md 正文.txt --json；正文是整改方案的加 --plan；有反馈原文的加 --feedback 反馈意见.txt 核对问题是否照录；要查超期的加 --date 2026-11-25。只给台账时只做台账自检。P0（报告写成已完成而台账未完成、完成数或完成率高于台账、未全部完成却写“全部完成”）必须改报告；P1 逐条处理；P2 人工判断。不靠改台账状态来消除差异。
2. 机检：运行 python scripts/gongwen_lint.py 正文.txt --doc-type 整改方案，进展报告和情况报告用 整改报告，自查报告用 自查报告。P0 必改，P1 逐条判断；【待补】机检报 P2，保留并汇总进起草说明。ELM 要素缺失的，能确定的补写，不能确定的标【待补】；EVD 强评价缺数据的，补用户材料中的数据或改用不带强评价的写法，不得编造数据。
3. 不能运行脚本（网页版、无 Python、脚本报错）时，按 references/checklist.md 人工对账和检查，并在起草说明写明。
4. 最后过一遍本文“自检清单”。

第六步　交付

按 references/_shared/style/output-format.md 交付。

1. 能写文件的：在 公文/<YYYYMMDD>-<简短标题>/ 下写 正文.txt（只含正文）、整改台账.md；有 Python 时运行 python scripts/md2xlsx.py 整改台账.md 整改台账.xlsx --title <台账表题> 出 Excel。只对账、不改稿的，写 对账意见.md：一页纸摘要、P0/P1/P2 问题清单（每条写位置、问题、依据、改法）和对账脚本结果，不写正文.txt。更新的台账另存，不覆盖。对话回复（不含附表和末尾提问）不超过500字：文件位置、一段话概述、【起草说明】（对账结果并入其中一行），逐条状态、问题清单、交接卡等只写进文件。
2. 网页环境：依次输出正文、【起草说明】；台账放在起草说明之后，标题为“附：整改台账”。只要台账的，正文就是台账；只对账的，直接输出对账意见；起草说明照常写。路线还有下一站的（如 review 核稿、format 排版），按 output-format.md 第四部分在起草说明之后输出更新后的交接卡。
3. 起草说明只在对话中给出，按 references/_shared/style/output-format.md 第二部分：不超过 5 行、每行一句，待补、待核实各汇总一行，修改说明一行（台账状态变化列入“附：台账状态变化”）；教学模式的写作要点另列“附：写作要点”。之后按需附对账结果、原因分析提示、措施提示、提法核对清单、整改台账，标题写“附：××”，不计入 5 行。

输出规范

• 正文按 references/_shared/style/output-format.md：纯文本，不用 Markdown；层次序数 一、（一）1.（1）；数字按 references/_shared/rules/gbt15835.md；提示只用【待补：说明】，不写【待核实】。
• 台账、三清单、自查表、对账结果是工作底稿，可以用 Markdown 表格；交付 Excel 用 md2xlsx。

自检清单

• 读材料前看过密级和“内部资料”等标识；人名、举报人、证件号已处理。
• 首轮已交付台账和正文；停下的属于第一步的三种情形，并在开头说明；提问不超过 3 个，放在末尾。
• 台账每条“问题表现”与反馈原文一致，没有弱化、删数字。
• 措施、责任、时限、成效标准没有空栏，缺的写了【待补】；措施是计划口吻，没有编造数字、制度名、调度频次和小组组成。
• 状态按口径认定；已完成、立行立改都有佐证；没有“基本完成”。
• 报告的统计句、每条状态句、完成率与台账一致；长期坚持没有算进完成数；未全部完成时没有“全部完成整改”。
• 成效数字、金额、处理人数都能在台账找到；没有无依据的评价。
• 用户加引号的做法名称、本单位提法原样保留（确需改写的列入提法核对清单）；“周五”等相对日期已按今天推算；“本周”“月底”等期限保留原话。
• 用户指定字数的，篇幅在目标±10%内，不足的已用工作性表述补足，没有注水。
• 开头没有意义铺垫，保障措施没有空表态，部署措施没有“建议”“可以考虑”。
• 正文没有 Markdown 符号、免责声明和【待核实】，【待补】一般不超过 3 处；起草说明不超过 5 行，待补、待核实各汇总一行；主送机关、落款、成文日期等要素能确定的已写上。
• 已运行第五步的对账和机检脚本，或已写明按人工清单检查。

单位差异

单位	调整要点（详见 references/units.md）
党政机关	巡视巡察整改用党组（党委）名义；提法逐字对照原文
基层	状态以台账为准，已完成须有佐证；不倒签、不补记；不向村（社区）转嫁整改任务
社区	篇幅从短，语言通俗；居民信息脱敏；不设定罚款等强制措施
公立医院	党委、行政两套代字按来源选用；“三重一大”措施写明党委会研究；患者信息脱敏；医保金额分口径
高校	学院台账与学校口径一致，编号沿用学校编号；学生信息不进对外材料
中小学	措施写到年级、处室和日期；不给教师摊派无关任务；学生信息不进材料
国有企业	党委前置研究再提交董事会或经理层；商业秘密不进公开版本；追责结果只写用户提供的

角色适配

• 教学模式：同样首轮交付问题清单、台账和正文，不等确认。“附：写作要点”：三清单为什么这样分、问题为什么必须照录、本稿一条状态的认定理由（用正误对照），每项【待补】到哪里找（反馈意见原文、分管领导、业务科室、财务凭证）。
• 高效模式：台账、正文、Excel 一次交付；起草说明只写假设、待补、待核实、状态变化和对账结果，不展开讲解，但每个对账问题、每处修改的问题类型和依据（台账编号、状态口径或条款）仍列入附表；需要时同时出报送版和公开版。
• 转译模式：接受业务科室的口语进展（“系统上个月上线了”），先改写成台账进展栏的“日期＋事实”，再判定状态并写明理由；只问日期、金额、佐证这类业务事实，不问公文术语。
• 审稿模式：用户拿来已写好的报告和台账要把关的，不重写全文，先对账，输出一页纸摘要（状态不一致、统计不符、弱化表述、无依据的成效，各几处）和 P0、P1、P2 问题清单（Agent 环境写入 对账意见.md）；要全面核稿的转 gongwen-review。被要求起草的，同样首轮成稿。
• 严谨模式：问题表述逐字对照反馈原文；政治性提法只用用户提供的原文，没有的用通用、稳定的表述，起草说明“待核实”一行请对照最新原文，并附提法核对清单；公开版删去问题线索和人员信息。

参考资料

没有文件系统（网页版、内网提示词版）时，下表中读不到的文件按本文和附录执行，不向用户索要这些文件。

文件	何时读取
references/status.md、ledger.md、plan.md、writing.md	判定状态、写统计句；建和更新台账、措施提示；写整改方案、原因分析提示；写各类报告和公开版本
references/sources.md、references/units.md	期限、报送对象和依据条款；读完单位画像后查本类单位的调整
references/checklist.md	第五步无法运行脚本时
references/_shared/guardrails.md、references/_shared/profiles/roles.md	开工前、与用户要求冲突时；角色模式、无画像降级、首轮交付
scripts/rectify_check.py、scripts/md2xlsx.py、scripts/change_guard.py、scripts/gongwen_lint.py	对账；台账转 Excel；改稿后核对数字、日期、引号内容；机检