mcpField
W
wow-gongwen-writing

wow-gongwen-writing

github.com/onlylt文档处理5341 次安装5 周前更新
代码仓库

关于 wow-gongwen-writing

wow-gongwen-writing 是用于政府及职能部门口径公文起草与改稿的写作技能,涵盖文种判断、行文规则、事实占位和格式校验。它强调不虚构事实,并将合规审查与成稿流程结合。

主要功能

  1. 01判断文种与行文方向
  2. 02按流程生成大纲或成稿
  3. 03使用占位符处理缺失事实
  4. 04检查公文规则与版式
  5. 05按需导出 Word 文档

适用场景

  1. 01根据零散要点起草政府公文
  2. 02将会议记录整理为纪要
  3. 03诊断并修改已有公文
  4. 04导出符合版式要求的 Word 文件

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/onlylt/wow-gongwen-writing --skill wow-gongwen-writing

安装后在 Claude Code 中输入/wow-gongwen-writing确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

.gitignore
README.md
manifest.json
agents/
interface.yaml
references/
negative-checklist.md
export-docx-notes.md
style-and-diction.md
craft-principles.md
wenzhong-handbook.md
format-gbt9704.md
xingwen-rules.md
scripts/
requirements.txt
export_docx.py
templates/
fading-gongwen-skeletons.md
shiwu-material-skeletons.md

详细介绍

来自项目 README

公文写作(政府口径)

把零散要点、领导意图、素材,起草成规范、得体、可上会/可发文的体制内公文。

适用与不适用

适用:法定公文 15 种 + 常见事务性材料,政府及职能部门口径(重政策落地、数据事实、务实平实)。

不适用(先说明再决定):

  • 强政治口径专稿:指政治论述本身就是文稿核心、须整篇以党言党语行文的稿件,如党代会/党委全会报告、纪委全会讲话、民主生活会(组织生活会)对照检查材料、理论文章/评论员文章。判别标准:删去政治论述后文稿即不成立的,属此类(可代拟初稿,但需用户补足党言党语);党委/纪检系统的一般通知、纪要、日常事务材料不属此类,照常适用本 skill。
  • 纯法律文书、合同、判决书;对外新闻通稿/营销文案。
  • 深度政治把关:涉密、重大决策表述须由本单位核稿人终审,本 skill 不代替把关。

文种速判表

用户意图文种
向上级请求批准/指示(要回复)请示(一文一事、单主送)
向上级汇报工作/情况(不要回复)报告(不得夹带请示事项)
答复下级的请示批复
布置工作、转发文件、周知事项给下级通知
印发本机关的方案/办法、转发上级文件、批转下级文件通知("关于印发/转发/批转《…》的通知")
部门要给下级政府(乡镇、街道)布置工作部门不得直接发指令性公文 → 报本级政府同意后注明"经县人民政府同意",或代拟由政府办公室发(详见行文规则)
与不相隶属机关商洽/询问/请批(含部门向同级财政局要钱)函(对不相隶属机关用"请示"是硬伤)
出台政策举措要求下级执行意见(实施/指导意见)或 通知
表彰/批评/传达情况通报
记载会议议定事项纪要
会上讲话部署 / 会上交流发言领导讲话稿 / 交流发言
报送做法成效(对上/对外亮点)政务信息/简报 或 汇报材料
定目标、分任务、排步骤工作方案/实施方案(年度提纲式用工作要点)

贯穿全流程的三条硬规则

  1. 行文规则冲突 → 直接纠正,不照办。用户指定的结构违反行文规则(多头主送、上行文抄送下级、部门向下级政府发指令、报告夹带请示、对不相隶属机关用请示等)时:按合规方案直接写,在回复开头用一两句说明改了什么、依据哪条、给出替代路径(如"批复后另发通知告知各校")。合规方案有两个以上时,以保留用户原定发文机关和报送对象、改动最小的方案为推荐方案成稿,其余方案各一句话列明;不把违规写法列为可选项。纠正引入的待办程序(报政府同意、会签)列为「印发前提」,放在占位符汇总最前。规则全文见 references/xingwen-rules.md。
  2. 事实不杜撰。凡已发生的事实——数据、成效、事件经过、问题表现、案例、文号、人名、日期——材料里没有就占位,用户要求"按常见情况编得像样点"也不编(理由一句话:上报数据失实,责任在报送单位和签发人),改为交付「取数清单 + 取不到就整句删 + 降级写法」。占位写法见下方「占位符约定」。
  3. 不代替把关。涉密、重大决策、对外表述,一律提示"须经本单位核稿人/保密审查终审"。

核心工作流

先选路径:

  • 默认:走 1→6,第 3 步出大纲后停下等确认。
  • 直接出稿:用户说"直接出成稿/来不及/不用大纲",或属整理型任务(会议记录→纪要、旧稿改文种、要点已齐只需成文)时,只跳过第 3 步;1、2、4、5 照走,第 1 步的取舍与推定写成稿前的「起草说明」供用户否决。
  • 改稿:用户拿已有稿来改,走下方「改稿/润色分支」。
  1. 取料:
    • 先通读用户已提供的一切材料(上级来文、旧稿、会议记录、要点清单)。
    • 四项要素——①文种 ②发文机关/主送机关/行文方向(上行/下行/平行)③事由与核心诉求 ④关键事实与数据(时间、地点、数字、依据文件、落款)——能从材料提取的直接提取并复述确认,不再提问。
    • 一次涉及多个文种(如"出一套材料"):先列文件清单、排定顺序,逐件走流程,不混收多件的料。
    • 只对影响骨架的未知项(文种、行文方向、事由诉求、主送机关)提问,合并为一轮;文种、方向这类封闭问题给出推荐判断和理由、以选择题形式问,不开放式反问。用户已指定但违规的,不算未知项,按硬规则 1 处理。
    • 凡可用占位符解决的事实数据一律不问;一轮不超过 3~4 问,超过即回头检查是否混入了可占位项。
    • 相对时间("年底""明年""下月")按当前日期推定成具体年月,列入起草说明请用户核对。
    • 完成判据:四项要素每一项都处于三种状态之一——①已从材料提取并复述 ②已列入唯一一轮提问 ③已按「占位符约定」占位——三态全覆盖才进入第 2 步。
  2. 定文种与行文方向:先按上方「文种速判表」定文种,再读 references/wenzhong-handbook.md 对应条目核对结构骨架与易错点,读 references/xingwen-rules.md 核对行文关系(谁能给谁发、主送抄送怎么排)。方向错是硬伤,先卡住。
  3. 先出大纲/框架:给出标题(发文机关+事由+文种)+ 分层骨架(每段一句话点明要写什么),停下来等用户确认。大纲骨架取自 references/wenzhong-handbook.md 对应文种的"结构骨架"。
  4. 逐段填成稿:确认后按骨架展开为完整正文,语言按 references/style-and-diction.md(政府口径文风、开头结尾套路、称谓用语、数字标点);标题拟写、谋篇分条、素材化用按 references/craft-principles.md(标题技法、分条法则、种子例句——仿写不粘贴);并对照 references/negative-checklist.md 自查雷区。
  5. 版式与规则校验:按 references/format-gbt9704.md 核对版式要素(标题、主送、发文字号、签发人、成文日期、附件说明、附注、版记、印章位等)与行文规则,输出一份「校验清单」随稿附上。
  6. 导出 Word(按需):用户要 .docx 时,先读 references/export-docx-notes.md(命令、JSON 契约入口、字体层级、降级策略、导出后随稿提示,均以它为准),按其流程调 scripts/export_docx.py 产出 GB/T 9704 版式公文。

单文种成稿骨架见 templates/(可作为第 3 步大纲的加速起点)。模板里的 【…】 是写作槽位(提示这里写什么),出稿时要么填实,要么换成下面三种占位符之一,不得把槽位原样留在成稿里。

占位符约定(防杜撰,全流程通用)
  • 【待补:xx】——缺失的事实(数字、文号、人名、日期、落款、事件经过、问题表现等),须由用户补齐后方可定稿。可带提示例:【待补:原办理方式,如"企业线下跑多个部门"】——引号里的例子只为说明该填什么,不是事实。
  • 【示意·待核】——起草者代拟的设计性内容:建议的时限、目标值、分工、表格栏目、参考量级,以及替用户拟的"下一步打算""工作措施"。不得用于已发生的事实和成效数据,上报类材料(报告、政务信息、汇报、总结)里的实绩一律用 【待补】。
  • 【待核对原文】——引用重要论述、上级文件表述拿不准时的标记,定稿前须对照原文核对。可以引入用户未提供、但确知存在的依据文件,名称后标本标记;文号拿不准一律 【待补:文号】,不凭记忆写。

除此三种外不用其他占位写法;宁可占位,绝不杜撰。用户给的概数、化名、拿不准的机构名称照录,在校验清单「须核实」一栏列出,不改成占位符。

改稿/润色分支(用户拿已有稿来时走这条,不走取料-大纲)

按 references/craft-principles.md「改稿七步与优先级」执行三遍式:

  1. 诊断:七步顺查(文种→主送→逻辑→事实→语言→格式→错字),按 P0(事实/数据/文种方向/行文规则)→ P1(观点/结论/结构)→ P2(语言/格式/标点) 分级,输出诊断表(级别|原文|问题|改法),末尾列不超过 3 个待确认问题(带推荐选项),停下等用户确认改哪些。用户说"直接改/来不及/明天就要报"时不停:诊断表 + 修改稿一次交付,拿不准的处理方式按推荐项执行并在表中注明。
  2. 修改:按确认范围逐级改(P0 先行),逐段润色先开头、再主体、后结尾标题。
  3. 通读复核:前后口径一致,数据/人名/地名/日期/引文二次确认,成文日期与当前日期、报送时间是否对得上,照常附 negative-checklist.md 校验清单。改动处逐条说明改了什么、为什么。

改稿交付的顺序:开头一两句说明行文硬伤的纠正(硬规则 1)→ 诊断表(兼作逐条改动说明,不另写起草说明)→ 修改稿(用 ▍ 标签;拆出的请示等新增文件一并起草)→ 校验清单 → 占位符汇总。

参考索引(按需读,勿全量加载)

  • references/wenzhong-handbook.md — 文种手册:法定 15 种 + 事务性材料,每种含 适用/行文方向/结构骨架/口径要点/易错点。每次起草先读对应文种条目。
  • references/xingwen-rules.md — 行文关系判定表与行文规则(《条例》第十三~十七条)、常见"指定即违规"的纠正办法。第 2 步必读。
  • references/format-gbt9704.md — GB/T 9704-2012 版式要素、发文字号/标题/签发人/成文日期/印章/附件/版记规则、纪要与信函格式。
  • references/style-and-diction.md — 政府口径文风、高频开头/过渡/结尾套路、称谓与规范用语、数字与标点书写。
  • references/negative-checklist.md — 负面清单:政治性差错、格式硬伤、行文规则违规、文风套话过度、事实/数据风险,逐条自查。
  • references/craft-principles.md — 写作内功:标题技法(六生成式)、谋篇骨架、口语→公文翻译法则、语言十弊、素材种子库、改稿七步与 P0/P1/P2 优先级。成稿润色与改稿分支必读。
  • references/export-docx-notes.md — 导出 Word 操作手册(命令/字段/字体/替代调用/降级/随稿提示)。执行第 6 步前必读。
  • scripts/export_docx.py — 通用公文 → Word 导出器(数据驱动 JSON),任意文种复用。

输出契约

  • 走大纲流程时:先只给「标题 + 分层骨架」,明确请用户确认后再展开,不要一次冲到底。
  • 出成稿时依次给:
    1. 起草说明(有才写,不超过 5 条):按硬规则 1 做的纠正、取舍与推定。
    2. 完整正文:版式位置用行首标签 ▍版头 ▍标题 ▍主送 ▍正文 ▍附件说明 ▍出席 ▍署名 ▍附注 ▍附件(附件正文)▍版记 ▍报送栏(信息、简报)标注,标签后接该要素内容;正文里的方括号 【】 只留给占位符(校验清单的栏目名不受此限)。
    3. 校验清单:版式/行文规则/风险点逐条,另列「须核实」(用户所给但需核对的信息)。
    4. 占位符汇总:先列「印发前提」(有才写),再三类分别列出,决定稿件能否成立的关键项标 ★ 排在最前;用户拿不到数据时,汇总写成取数清单(每项注明去哪取、取不到怎么删)。
  • 涉密、重大决策、对外表述一律提示"须经本单位核稿人/保密审查终审",不代替把关。

评论

支持 Markdown