---
name: duyunzhoudyz-gongwen-draft
description: "起草和改写法定公文：通知（会议、转发、印发、部署）、请示、就一件事的报告、函、通报、批复、意见、签报，以及决定、通告、公告；先定文种、查行文规则，再按文种结构成稿，事实只用用户给的。用户说写个请示、给财政局发个函、发个会议通知、把上级文件转发下去、写表彰通报、回个批复、科室要写签报、这事用请示还是报告时使用。纪要交 gongwen-minutes，全面工作报告交 gongwen-report，拆任务的实施方案交 gongwen-implement，整改交 gongwen-rectify，讲话交 gongwen-speech；装有行业包时，本行业专用文书交对应行业包。"
license: "NOASSERTION"
metadata:
  decimalai-skill-id: "4f79632d-58aa-4ec8-bc80-564a6aeebbc3"
  decimalai-version-id: "8aff8df0-829c-4a27-b199-c8f405950517"
  decimalai-version: "1"
  decimalai-body-sha256: "bf2b11690a88bf191c08a3f8c502474d34e848c3a3952af1c296a6073c1b917f"
  decimalai-name: "duyunzhoudyz/gongwen-draft"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "documentation"
  decimalai-source: "https://app.decimal.ai/s/duyunzhoudyz-gongwen-draft@1/SKILL.md"
---
# 法定公文（gongwen-draft）

帮机关、事业单位、国企的文字工作者起草和改写法定公文。做法固定：先定文种，再查行文规则，然后按文种结构成稿，最后复查和机检。文种和行文规则的判断都写明《党政机关公文处理工作条例》条款；文号、日期、金额、依据文件、批复意见只用用户给的，缺的标【待补】。

## 适用范围

- 适用：
  - 全流程起草：通知（部署、会议、转发、批转、印发、事务性）、请示、报告（就一件事的情况报告、答复报告、交办事项报告、报送材料的报告）、函（商洽、询问、请批、复函）、通报（表彰、批评、情况）、批复、意见、签报。
  - 可以起草，先核发文权限：决定、通告、公告。
  - 只给结构说明和信息清单：决议、命令（令）、公报、议案。
  - 改写：已有稿子文种用错、行文规则有问题、结构要按文种重搭的，按模式二处理。
  - 判断文种：用户只问“这事用请示还是报告还是函”。
  - 民主生活会、组织生活会召开情况报告：只管报送用的公文格式（标题、主送、结构、结语），内容由 gongwen-party 提供。
- 不适用（转交）：
  - 会议纪要、会议记录 → gongwen-minutes（会议通知归本 skill）。
  - 年度、半年、专项的全面工作报告，总结、计划、汇报材料、自主制定的实施方案 → gongwen-report（报送这些材料的报告、印发它们的通知归本 skill）。
  - 以上级文件为依据拆任务的实施方案、贯彻落实方案、落实情况报告 → gongwen-implement（只转发、不拆任务的转发通知归本 skill）。
  - 整改方案、整改台账、整改报告、自查报告 → gongwen-rectify；讲话稿、主持词、致辞 → gongwen-speech；党建材料 → gongwen-party；政务信息、简报 → gongwen-brief。
  - 只要标题 → gongwen-title；压缩、扩写、调语气 → gongwen-polish；去 AI 腔 → gongwen-humanize；去防御腔 → gongwen-direct；核稿 → gongwen-review；排版 → gongwen-format；说不清要写什么 → gongwen。
  - 装有行业包的：高校校内事项“学校发还是部门发”的判断、学院和部门给校领导的校内签报（请示报告单）→ gongwen-university；居民通知、告知书、倡议书，乡镇（街道）发村（社区）的防汛防火应急通知 → gongwen-grassroots；要上党委会、董事会、总经理办公会的议题材料，董事会议案和决议 → gongwen-soe（部门向领导的签报归本 skill）；医院上会议题和评审、质量等专用文书 → gongwen-hospital；致家长的一封信 → gongwen-k12。对外的请示、函、通告，以单位名义的正式通知和就一件事的报告仍归本 skill；没装行业包的，上述签报和通知由本 skill 按单位画像和通用写法处理，不拒绝。
- 转交方式：能调用其他 skill 的环境直接调用；目标 skill 未安装或在网页环境的，按 `references/_shared/style/output-format.md` 第四部分转交：给交接卡、“新开对话粘贴 dist/prompts/<skill>.md 继续”的说明和安装命令。

## 开工检查

1. 保密（`references/_shared/guardrails.md` 第一条）：
   - 有 Python 时，先运行 `python scripts/secret_check.py <文件>` 检查保密标识（含页眉页脚），命中即停。
   - 材料出现敏感信号（个人敏感信息，“内部”“不公开”“暂不对外”等字样，未公开的人事任免或财务数据）时，才在起草说明末尾提示一句：“提示：涉密材料请勿输入联网 AI。”普通工作材料不提示，同一会话只说一次。
   - 材料带密级标识（“秘密★”“机密★”“绝密★”，或版头标注的密级和保密期限），或标注“内部资料”“工作秘密”“不得外传”“内部使用”的，立即停止，不复述、不摘录，告诉用户改用内网模型或删去相关内容后再发。正文中正常出现“保密工作”一类词语的不算。
   - 身份证号、手机号、病案号、学号、家庭住址、患者或学生的真实姓名，提醒用户脱敏，稿中写“张某”“138****0000”。
2. 单位画像：工作目录有 `.gongwen/单位画像.md` 的先读取，没有再找 `~/.gongwen/单位画像.md`，用户粘贴在对话开头的按粘贴内容；有 `.gongwen/领导偏好卡.md`、`.gongwen/禁用词.md`、`.gongwen/文风参数.md` 的一并读取。重点看可用文种、内部文种、发文机关标志、党政两套代字、决策程序。再读 `references/_shared/profiles/units/` 下对应文件和 `references/units.md`。没有画像按 `references/_shared/profiles/roles.md` 第九节“无画像降级”处理。
3. 角色模式：按 `references/_shared/profiles/roles.md` 第一节确定，本 skill 中的差异见“角色适配”。
4. 网页环境用户贴了交接卡的，按卡上的单位画像、当前模式、任务、本站和已确认事项开工，卡上有的不再问（`references/_shared/style/output-format.md` 第四部分）。
5. 不做的事，说明原因后其余照常：把正式文件改成便笺、“白头”来规避发文数量管理（`references/_shared/rules/jianfu.md` JF-15）；替用户决定批复同意与否、处理决定的轻重；起草党纪处分、政务处分决定。
6. 定工作模式：用户给的是素材或口头描述的，用新写模式；给的是已有稿子、要改文种或结构的，用模式二。
7. 定首轮交付（`references/_shared/profiles/roles.md` 第十节）：有题目，并且至少有一项具体事实（时间、主体、做法、数据之一）的，任何模式都首轮直接出稿，缺的且无法从上下文确定的才标【待补】。只有四种情形停下，在回复开头一句话说明属于哪一种：①需要本人经历的材料缺本人事例；②只有题目、没有任何具体事实，出结构说明和补料清单；③用户明确要求先看提纲、要点或一页纸，交一页纸（文种及理由、主送、各部分要点、待补清单）；④材料涉密，按第1条停止，提纲也不出。

## 工作流程

### 第一步　定文种

先定发文名义、写给谁、要办的事、文种、行文方向、篇幅（素材可支撑多少），只作内部判断，不原样输出；文种判断及条款、采用的默认值写成起草说明“假设”一行（教学模式可多讲一两句）。网页环境回复开头直接是正文，仅停在提纲时先一句话说明属于哪种情形（`references/_shared/style/output-format.md` 第三部分）。

```text
假设：以某县文化和旅游局名义写给县自然资源局（不相隶属），您说请示，已按函写（第八条第（十四）项）；约800字。
```

按四问定文种（细则见 `references/decision.md`）：以谁的名义发；写给谁；要办什么事；本单位能用哪些文种。用“写给谁”“要办什么事”查下表，再用另外两问过滤：

| 写给谁＼要办的事 | 请求批准 | 汇报、答复询问 | 部署 | 告知、表彰、批评 | 商洽、询问 | 答复来文 |
|---|---|---|---|---|---|---|
| 有隶属关系的上级 | 请示 | 报告 | 不适用 | 报告 | 请示 | 报告 |
| 下级 | 不适用 | 不适用 | 通知；重大事项用决定；一套政策措施用意见 | 通知；通报 | 函 | 批复（答复请示） |
| 不相隶属单位 | 函 | 函 | 不得部署 | 函 | 函 | 复函 |
| 本单位领导（内设部门报送） | 签报 | 签报 | 不适用 | 签报 | 签报 | 签报 |
| 社会公众 | 不适用 | 不适用 | 不适用 | 通告（有职权的机关）；通知、温馨提示 | 不适用 | 不适用 |

易混的几组，一句话判断（依据均为《党政机关公文处理工作条例》）：
- 请示与报告：有一项需要上级表态，这一项就单独写请示；报告不夹带请示（第十五条第（四）项）。
- 请示与函：对方有隶属关系用请示；不相隶属，即使是审批部门，也用函（第八条第（十一）（十四）项）。
- 请示与签报：以本单位名义向上级机关用请示；内设部门向本单位领导，有签报制度的用签报。
- 通知、通告与公告：有受文机关用通知；面向公众、有遵守要求用通告；向国内外宣布重要或法定事项用公告。
- 通报、通知与决定：重在“发生了什么、怎么看”用通报；重在“要做什么”用通知；授予称号、正式奖惩用决定。
- 批复与复函：来文是下级的请示用批复；来文是函用复函。
- 意见与通知：一整套政策措施用意见；一项具体工作用通知。

提问：最多 3 个，放在回复末尾，不阻塞起草；按此顺序取舍：写给谁、与本单位什么关系 → 要办成什么（请求事项、批复意见、会议时间地点） → 金额、时间等核心事实。其余取默认值写进“所作假设”；缺的数据不靠追问补齐，必须由用户提供的要素在正文标【待补】（一篇一般不超过 3 处，更多时先交付再集中提问）。用户说“直接写”的不再提问。用户答复后，在已交付的稿子上修改。

用户指定的文种不当时：先指出并写明条款，再按正确文种起草，起草说明写明改动理由；用户坚持的，按用户要求写，保留提示（`references/decision.md` 第四部分）。

### 第二步　查行文规则

起草前查一遍，成稿后再查一遍。完整检查表和正误对照见 `references/rules-check.md`。

| 检查项 | 发现问题怎么办 | 依据 |
|---|---|---|
| 主送唯一（请示、上行意见） | 只留一个主送，其他上级列抄送 | 第十五条第（一）项 |
| 不越级 | 主送直接上级；确需越级的同时抄送被越过的机关 | 第十四条 |
| 不抄送下级、不送领导个人（上行文） | 删去下级；领导个人改为机关（签报主送一位领导职务，不在此列） | 第十五条第（一）（五）项 |
| 一文一事（请示、签报） | 拆成几份分别起草；用户不同意的在起草说明中提示 | 第十五条第（四）项 |
| 报告不夹带请示 | 请求事项抽出另写请示 | 第十五条第（四）项 |
| 转报下级请示有本机关意见 | 用户没给的标【待补：本机关倾向性意见】 | 第十五条第（三）项 |
| 部门不向下级党委政府发指令；需经政府同意的注明 | 提示改由办公厅（室）行文或改为商洽口吻；写“经某某人民政府同意” | 第十六条第（二）项 |
| 内设机构不对外正式行文 | 改以本单位或办公室名义 | 第十七条第三款 |
| 涉及其他部门职权 | 起草说明写“附：需会签部门”，用户列出的部门全部列入 | 第十六条第（四）项、第十九条第（六）项 |
| 签报一签一事、只报一位领导 | 拆分；多位领导改为一位，由办公室流转 | 本单位签报制度 |

### 第三步　按文种起草

通用规则：
1. 正文从标题写起：标题、主送、正文、附件说明、署名、成文日期，需要时加附注（联系人）；通知的联系人写在正文末段、落款之前。请示、报告在标题前另起两行写“发文字号：”“签发人：”（未知写【待补】）；份号、发文机关标志属于版头，不写进正文。
2. 以下内容只用用户给的，缺的必要要素标【待补：说明】，说法不一的正文采用材料中最可靠的写法、起草说明“待核实”一行说明：文号、金额、数量、依据文件名称和文号、来文标题、会议决定、表彰决定、处理决定、联系人；成文日期未给的默认写当天日期（起草说明提示按实际印发日期调整），发文机关、主送机关能从材料和用户身份确定的直接写，确定不了的标【待补：发文机关】，不省略。程序承诺（“研究前不实施”）、请求事项、前置条件、时限同样只写用户给的。任务措施属工作性表述，按上级要求和文种常规写出，责任主体只用材料已有的单位，不夹带新数字、项目名，时间节点、负责人等须用户定的才标【待补】；工作方案、实施方案的阶段起止日期，材料给了的照用，材料没有的标【待补：阶段日期】，不自拟任何日期节点。用户说的“周五”“下周一”等相对日期按今天推算为具体日期（`references/_shared/guardrails.md` 第二条第7款）。
3. 三类判断由用户定，工具不替用户拿主意：批复同意与否、请示的本单位倾向、通报的处理决定。用户没给的，正文标【待补】，在回复末尾问一次；用户说“直接写”的只标不问。其余照常起草。
4. 开门见山：通知、请示、函、批复、通报等第一段写目的、依据或事项，不写形势背景和重要意义（JF-02）；其他文种按惯例可写不超过一段的简短背景。
5. 措辞按方向：下行用“要”“应当”“于×月×日前”，不用商量口吻；上行的打算用“拟”，请求用“恳请”；平行用“商请”“请予支持”，不用“务必”（`references/_shared/style/defensive.md` 第五、七部分）。
6. 篇幅：除部署综合性工作外，一般不超过5000字；部署专项工作或具体任务的一般不超过4000字（减负规定第2条）；医院、学校、国企内部发文超限只作提示。细则中的字数只是上限，事实少的写短。用户指定字数的，按 `references/_shared/guardrails.md` 第四条第2款处理。用户未指定字数时，按文种的典型篇幅写，不一律写到上限；各文种典型篇幅见下表（素材不足写短，素材充足且用户要求写足的可接近上限）：

   | 文种 | 典型篇幅 | 说明 |
   |---|---|---|
   | 通知（部署） | 800～2000字 | 事项多、涉及单位多时可到上限 |
   | 通知（会议） | 500～1000字 | 五项要素齐全即可，不长篇 |
   | 通知（转发、印发） | 300～800字 | 转发语加本级要求，不复述原文 |
   | 请示 | 800～1500字 | 一文一事，缘由充分但不展开论证 |
   | 报告 | 1500～3000字 | 情况复杂或答复多项时可到上限 |
   | 函 | 500～1500字 | 商请事项写清，不铺陈 |
   | 通报 | 800～1500字 | 事实+评价+决定+要求，事实部分最长 |
   | 批复 | 300～800字 | 引叙+表态+要求，简短为主 |
   | 意见 | 2000～4000字 | 任务分条展开，篇幅相对长 |
   | 签报 | 500～1000字 | 内部文书，一签一事 |
   | 决定 | 1000～3000字 | 重大事项，决定事项可分条 |
   | 通告 | 500～1500字 | 范围、行为、罚则依据、施行日期 |
   | 公告 | 300～800字 | 事项简明 |
7. 默认不写：报送贯彻落实情况、制定配套文件、纳入考核、一票否决、签订责任状、上传照片留痕（JF-05～JF-08、JF-12）。用户坚持的照写，起草说明提示。
8. 政治性提法只用用户提供原文中的表述，没有的用通用稳定的表述，起草说明“待核实”一行请用户对照最新原文。用户材料中加引号的做法名称、本单位提法原样照写，不换近义词；确需改写的，列入提法核对清单请用户确认（`references/_shared/guardrails.md` 第二条第8款）。
9. 下行文主送机关：材料列明的收文单位全部写入，可用“各××、××”概括，不遗漏；成稿后逐项核对。

按文种查下表，动笔前读对应细则：

| 文种 | 标题 | 骨架 | 结语 | 必查 | 细则 |
|---|---|---|---|---|---|
| 通知（部署） | 某某关于做好……工作的通知 | 目的依据 → 事项（谁、做什么、何时） → 要求 | 特此通知。（可省） | 任务有主体和时限；主送不漏收文单位 | `references/doc-types/tongzhi.md` |
| 通知（会议） | 某某关于召开……会议的通知 | 名称、时间、地点、参会人员、内容、回执、要求、联系人 | 无 | 前五项必备 | 同上第三部分 |
| 通知（转发、印发） | 见下文 | 转发语或印发语 → 本级要求（用户给的） | 无 | 不复述原文 | 同上第四、五部分 |
| 请示 | 某某关于……的请示 | 缘由 → 事项 → 本单位意见 | 妥否，请批示。 | 一文一事；主送唯一；打算用“拟”；附注联系人 | `references/doc-types/qingshi.md` |
| 报告 | 某某关于……情况的报告 | 情况 → 处置 → 原因 → 下一步；答复报告逐项答 | 特此报告。 | 不夹带请示；原因只写已查明的 | `references/doc-types/baogao.md` |
| 函 | 某某关于商请……的函；……的复函 | 缘由 → 事项 → 希望；复函先给结论 | 请予支持。特此函复。 | 对象不相隶属；语气平和 | `references/doc-types/han.md` |
| 通报 | 某某关于表彰……的通报 | 事实 → 评价 → 决定 → 要求 | 特此通报。 | 决定来自用户；评价与事实相称 | `references/doc-types/tongbao.md` |
| 批复 | 某某关于（同意）……的批复 | 引叙来文 → 表态 → 条件或理由 → 要求 | 此复。 | 表态来自用户且明确；逐项回应 | `references/doc-types/pifu.md` |
| 意见 | 某某关于……的意见 | 总体要求（从简） → 主要任务 → 保障 | 无 | 下行用“要”；篇幅 | `references/doc-types/yijian.md` |
| 签报 | 关于……的请示（内部文书，可省发文机关） | 缘由 → 事项 → 部门意见 → 会签情况 | 妥否，请批示。 | 一签一事；一位领导；稿首单列“签报”表头 | `references/doc-types/qianbao.md` |
| 决定 | 某某关于……的决定 | 缘由 → 决定事项 → 执行要求 | 无 | 权限；研究的会议和时间来自用户 | `references/doc-types/jueding.md` |
| 通告 | 某某关于……的通告 | 依据 → 范围、时间、对象、行为 → 罚则依据 → 施行日期 | 特此通告。 | 主体有职权；不自设处罚 | `references/doc-types/tonggao.md` |
| 公告 | 某某公告 | 事项 | 特此公告。 | 局部事项不用公告 | `references/doc-types/gonggao.md` |
| 决议、命令、公报、议案 | 只给结构说明和信息清单 | | | | `references/doc-types/p2.md` |

三处容易写错的地方：
1. 会议通知：名称、时间、地点、参会人员、会议内容五项缺一不可，名称按用户的称呼写、内容按会议名称概括，时间、地点、参会范围确定不了的标【待补】并排在“待补”一行最前；不编议程，不另加报送材料要求。用户只说“下周三”的，按今天推算为具体日期。
   - 误：定于近期召开全校教学质量分析会。
   - 正：定于【待补：会议时间】在行政楼2楼会议室召开全校教学质量分析会。
2. 转发通知标题：先追到最初的文件，中间机关只加了转发语的省略中间层次；中间层是“批转”，或是政府、办公厅（室）转发部门文件的，这一层赋予文件效力，保留并转发这一层的文件。标题写本机关名称的，写“本机关转发……”，不加“关于”；不写本机关名称的，写“关于转发……的通知”，并省去被转发标题中的“关于”。全标题只留一个“关于”、一个“的通知”。被转发的是意见、办法的，写“……关于……实施意见的通知”。本单位制度另有明文规定的从其规定，起草说明写明。
   - 误：某区教育局关于转发某市教育局关于转发省教育厅关于做好冬季校园安全工作的通知的通知的通知
   - 正：某区教育局转发省教育厅关于做好冬季校园安全工作的通知
3. 面向群众的通告、通知：不自设罚款、拘留、查封、强制拆除、断水断电、取消低保等（《行政处罚法》第十六条，《行政强制法》第十条、第十三条、第四十三条第二款）；罚则只写“由某某机关依照《……》处理”，依据来自用户，没有的写“依法处理”并在起草说明请用户补依据。社区、学校、医院不发约束公众的通告，改用通知或温馨提示。

### 第四步　复查与机检

1. 按第二步的表再查一遍行文规则，再核对标题文种与正文结语是否一致（请示配“妥否，请批示”，报告配“特此报告”，函不用“请批示”）。篇幅、层次、开头结语可对照 `references/_shared/style/baseline.md` 中该文种的典型参数（参照，不是硬规则；用户指定篇幅时以用户为准）；机检加 `--baseline` 会对偏离基线的篇幅、一级标题数、“一是”组数、顿号密度给 P2 提示，只作参照。
2. 有 Python 环境时运行两个脚本：
   - `python scripts/gongwen_lint.py 正文.txt --doc-type 请示 --json`，文书类型按实际文种填，签报填“签报”。P0 必改，P1 逐条判断，P2 酌情；命中白名单写法的保留（`references/_shared/style/ai-tone.md` 第二部分）。ELM 要素缺失的，能确定的补写，不能确定的标【待补】；EVD 强评价缺数据的，补用户材料中的数据或改用不带强评价的写法，不得编造数据。
   - `python scripts/draft_check.py 正文.txt --doc-type 请示 --json`：查标题叠用、会议通知要素、批复表态、请示一文多事、函的语气、通告主体、停水停电等强制表述等本 skill 专项。
   - 【待补】标记机检报 P2，是起草阶段的正当产物，保留并汇总进起草说明。
3. 没有 Python、脚本报错或输出“未执行检查”的，按 `references/checklist.md` 逐项人工检查，在起草说明写“未运行机检，已按人工清单检查”。

### 第五步　交付

按 `references/_shared/style/output-format.md` 交付：
1. 能写文件的，在当前工作目录建 `公文/<YYYYMMDD>-<简短标题>/`，写入只含正文的 `正文.txt`。拆成几份的写 `正文-报告.txt`、`正文-请示.txt`；模式二另存 `原稿.txt`。同名文件已存在时加 -v2、-v3，不覆盖。对话中报文件位置和一句话概述，并给出起草说明，不写过程说明。
2. 网页环境：依次输出正文、`【起草说明】`，正文前不加引导语。路线还有下一站的，在起草说明之后输出更新后的交接卡，告诉用户新开对话，先粘贴下一站的提示词文件，再粘贴交接卡和本站产出。
3. 起草说明只在对话中，不超过 5 行、每行一句：假设（文种判断及条款、采用的默认值）、待补（汇总一行，版头要素列在最后）、待核实（汇总一行）、修改说明、保密提示；教学模式另附写作要点。涉及其他部门职权的必须附“附：需会签部门”，用户列出的全部列入；需要时附“附：提法核对清单”“附：素材台账”。
4. 在对话中（不在正文里）提示下一步，用描述性说法，不写 skill 名：送签前可以继续让我核稿，再排成国标 Word。

## 模式二　改写已有稿件

用户拿来已有稿子，要改文种、按行文规则调整或重搭结构时：
1. 原稿存为 `原稿.txt`（网页环境略过），读到 `【起草说明】` 为止。
2. 先诊断，列出问题、依据和改法：文种、行文规则（第二步的表）、结构是否符合文种骨架。高效模式下诊断合并进修改说明，不单列，每条仍写问题类型和依据条款。
3. 按正确文种重写。原稿中的事实、数字、日期、文号照用，不新增；需要拆分的拆分；原稿缺的标【待补】。标题去掉“（初稿）”“（征求意见稿）”等草稿标记（用户要求保留的除外）；原稿内部矛盾（数字、时间、条数不一致）按最合理的一致写法处理，修改说明写明处理方式，请用户确认。
4. 有 Python 环境时运行 `python scripts/fact_diff.py 原稿.txt 正文.txt --json`：两稿差异都要能对上修改说明；“改稿新增”中有用户本轮没给的数字，退回原稿写法。不能运行时人工核对数字、日期、文号、书名号内容。
5. 修改说明在起草说明中占一行；逐条的原文、改后、理由附表列在起草说明之后（高效模式不超过 5 条）。
6. 只是文字压缩、调语气的转 gongwen-polish；只要挑问题、不要改稿的转 gongwen-review。

## 单位差异

先读单位画像，再按 `references/units.md` 调整。要点：

| 单位类型 | 本 skill 的主要调整 |
|---|---|
| 党政机关 | 部门不向下级党委政府发指令；部门报重大事项须经本级同意；篇幅超限报 P1 |
| 基层 | 乡镇向县政府请示，向县直部门用函；面向群众的通知逐句查法律表述 |
| 社区 | 一般不用红头；对上报“申请”、情况报告；对居民用通知、温馨提示，不发通告 |
| 公立医院 | 科室向院领导用签报；医院与医保部门用函；“三重一大”写明院长办公会、党委会程序；患者信息脱敏 |
| 高校 | 校级与部门两级发文；学院向学校用校内请示报告单或签报，不直接向校外上级请示 |
| 中小学 | 向主管教育部门请示，不越过它找编制、财政部门；致家长的通知语言通俗 |
| 国有企业 | 本部部门向公司领导用签报；重大事项写明党委前置研究；董事会议案交 gongwen-soe 或只给结构 |

医院、高校、国企和机关的党委、行政两套发文，按事项归属定名义：党建、干部、纪检、意识形态用党委（党组）名义；业务、运营、医疗、教学科研用行政名义；属于各自职权的分别发文，不联合发文（第十七条第一款，细则见 `references/units.md` 第二部分）。

## 输出规范

- 正文、起草说明、交付位置按 `references/_shared/style/output-format.md`：纯文本，不用 Markdown；层次序数依次为 一、（一）1.（1）；数字按 `references/_shared/rules/gbt15835.md`，成文日期用阿拉伯数字、不编虚位。
- 正文中只允许【待补：说明】一种提示。
- 标题末尾不加标点；标题中除法规、规章和规范性文件名称外一般不用书名号。

## 自检清单

- [ ] 要素行按文种齐全并写在正文里（不放进起草说明）：标题、主送机关、落款、成文日期、附件说明、结语（如请示“妥否，请批示”）；请示、报告另有发文字号、签发人；确定不了的已标【待补】。
- [ ] 首轮已出稿，回复开头直接是正文；停在提纲的属于开工检查第7条四种情形之一，回复开头已说明；提问不超过 3 个，放在回复末尾。
- [ ] 文种与“写给谁、要办什么事”一致，起草说明写了判断依据和条款。
- [ ] 行文规则逐项查过：主送、越级、抄送、一文一事、报告不夹带请示、内设机构对外行文、涉及其他部门的会签部门。
- [ ] 标题有发文机关（内部签报可省）、事由、文种；发文机关从材料或用户身份确定，确定不了的标【待补：发文机关】，不省略；没有”关于关于””的通知的通知””请示报告”，发文机关之后没有接”关于转发”。
- [ ] 结语与文种对应。
- [ ] 文号、日期、金额、依据文件、来文标题、各类决定全部来自用户，缺的已标【待补】；程序承诺、请求事项、时限没有自拟，任务措施没有夹带新数字、项目名；工作方案/实施方案的阶段日期，材料没给的已标【待补：阶段日期】，没有自拟。经费请示：材料同时给出总预算和已安排经费的，申请金额已按缺口算式写出，与材料口头估计数字有出入的已在起草说明中注明。
- [ ] 用户说的“周五”“下周一”等相对日期，已知当天日期的已推算为具体日期并在起草说明注明；“年底前”等期限原样保留。
- [ ] 用户材料中加引号的做法名称、本单位提法原样保留；确需改写的已列入提法核对清单请用户确认。
- [ ] 通知等下行文的主送机关与材料列明的收文单位一致，没有遗漏。
- [ ] 批复意见、请示倾向、处理决定没有替用户拿主意。
- [ ] 会议通知五项必备要素齐全或已标【待补】。
- [ ] 面向群众的文书没有自设处罚和强制措施，没有个人信息。
- [ ] 没有形势背景铺垫，没有自加层层报送、考核、留痕要求。
- [ ] 用户指定篇幅的，正文在目标±10%内，素材不足处已用工作性表述补足，起草说明已说明；没有注水。
- [ ] 正文没有 Markdown、免责声明、AI 自述、【待核实】；【待补】一般不超过 3 处，已在起草说明汇总一行；起草说明不超过 5 行。

有 Python 环境时运行 `python scripts/gongwen_lint.py 正文.txt --doc-type <文种>` 和 `python scripts/draft_check.py 正文.txt --doc-type <文种>`；无法运行时按 `references/checklist.md` 人工检查。

## 角色适配

- 教学模式：首轮成稿（开工检查第7条），文种判断按第一步的位置写进起草说明，不放在正文前。写作要点讲四件事：为什么是这个文种；结构为什么这样搭（提纲作结构说明写在这里）；这类文种最常见的一个错误（用本稿的正误对照）；每项【待补】一般到哪里找（来文、预算批复、会议纪要、单位画像）。
- 高效模式：信息够就不问，直接成稿；拆分出的几份一次交付；转发通知标题可另给不写本机关名称的一种写法；起草说明只写假设、待补、待核实，不展开讲解，文种更正和行文规则问题合并成一行，写问题和条款。
- 转译模式：接受口头描述和业务材料，用一句话说明把“要办的事”写成了什么文种、请求什么（写在起草说明“假设”行，不放在正文前）；只问业务事实（金额、数量、时间、对象），不问公文术语；说明所选文种与最相近的文种差在哪里，一两句即可（如“函写给管不着我们的单位，请示只报直接管我们的上级”）；模式二的诊断和修改理由，在条款之外各附一句不用术语的白话解释；起草说明之后附三五条“业务说法 → 公文表述”对照。情况报告、请示、签报等数字多的文种，再附简表素材台账（事实、数值、出处），涉及计算的写出算式；会议通知等事实少的短文种可以不附。
- 审稿模式：被要求起草的，同样首轮成稿；用户明确要先看一页纸或要点的（开工检查第7条情形③），交一页纸（文种及理由、主送、要点、待补清单），回复开头说明；用户给的是成稿、要挑问题的，转 gongwen-review。
- 严谨模式：党委名义的文件、含政治性提法的意见和决定、表彰决定、面向社会的通告叠加本模式。政治性提法只用用户原文，没有的用通用稳定的表述，起草说明“待核实”一行请用户对照最新原文；法律依据逐条注明出处；起草说明附提法核对清单（提法、位置、出处、是否已对照原文）。

## 参考资料

没有文件系统（网页版、内网提示词版）时，读不到的文件按本文和附录执行，不向用户索要这些文件。网页提示词版的附录只收共享规则、文种速查卡和人工自检清单；文种决策、行文规则的要点已写进本文和速查卡。

| 文件 | 何时读取 |
|---|---|
| `references/quick-ref.md` | 网页环境的文种速查卡；Agent 环境可代替细则快速查阅 |
| `references/decision.md` | 第一步定文种；判断是否归本 skill |
| `references/rules-check.md` | 第二步、第四步查行文规则；拆分和抽出请示 |
| `references/doc-types/` 下 12 个文件 | 第三步动笔前，读对应文种 |
| `references/units.md` | 读完单位画像后；党政两套代字、两级发文、签报流转 |
| `references/checklist.md` | 第四步无法运行机检时 |
| `references/_shared/guardrails.md` | 开工前；与用户要求冲突时 |
| `references/_shared/style/output-format.md` | 第五步交付；交接卡；转交和未安装兜底 |
| `references/_shared/style/ai-tone.md`、`references/_shared/style/defensive.md` | 成稿措辞；处理机检结果 |
| `references/_shared/rules/tiaoli.md` | 写条款依据；行文规则原文要点 |
| `references/_shared/rules/doc-types.md` | 文种通用要点、决策表、易混辨析 |
| `references/_shared/rules/gbt9704.md`、`references/_shared/rules/gbt15834.md`、`references/_shared/rules/gbt15835.md` | 格式要素、标点、数字 |
| `references/_shared/rules/jianfu.md` | 定篇幅；部署性文件的减负要求 |
| `references/_shared/profiles/roles.md`、`references/_shared/profiles/units/` | 定角色模式；无画像降级；首轮交付；单位类型细节 |
| `scripts/gongwen_lint.py`、`scripts/draft_check.py`、`scripts/fact_diff.py` | 第四步机检；模式二核对事实 |