公文写作

概述

Official Docs Writer Skill — 新建公文

通过多角色串行协作，将用户需求转化为标准合规公文并导出 Word。

本 Skill 仅负责新建公文。若用户要优化/润色/审校已有公文，请提示用户改用 official-docs-optimize。

[!CAUTION]

🛑 ENTRY CHECK — 任何任务开始前必读

1. ✅ 读完整篇本 SKILL.md（尤其是下面的 Global Execution Discipline）
2. ✅ 确认这是"新建公文"需求（写/起草/拟稿/撰写）而非"优化"需求
3. ✅ 验证用户提供了充分需求（否则提问澄清）
4. ✅ 在到达对应阶段前，禁止生成正文内容

[!CAUTION]

🚨 Global Execution Discipline（强制）

本工作流是严格串行流水线，以下规则优先级最高，违反任一条即视为执行失败：

1. 串行执行 — 每个 Phase 必须按顺序执行，前一个 Phase 的输出是后一个 Phase 的输入
2. BLOCKING = 硬停 — 标记 ⛔ BLOCKING 的 Phase 必须停下等待用户明确回复，不得代用户决策
3. 禁止跨阶段打包 — Phase 间不得合并
4. 入门先过门禁 — 每个 Phase 顶部的 🚧 GATE 前置条件必须先验证
5. 禁止投机执行 — 禁止"提前预备"后续 Phase 的内容
6. 正文生成须留在主 Agent — 写手阶段的内容生成依赖完整上下文，必须由当前主 Agent 端到端完成，禁止委托给子 Agent
7. 逐段顺序生成 — 写手阶段确认全局写作参数后，必须一段接一段连续生成，禁止批量分组
8. 每段重读 spec_lock — 写手生成每个 section 前，必须 read_file <project_path>/spec_lock.md

[!IMPORTANT]

🌐 语言规则

• 回复语言：始终匹配用户输入语言
• 公文语言：默认简体中文，除非用户另行指定

脚本与资源说明

本 Skill 目录即脚本根目录。执行脚本时使用相对路径 scripts/xxx.py，Python 解释器统一使用 python3：

python3 scripts/<script>.py <args>

💡 若你的环境中 Python 位于虚拟环境（venv），请将 python3 替换为该虚拟环境的解释器路径。

数据源：references/standards.json（格式标准、文种信息、AI词表、结构要求的唯一配置源）。模板与参考：templates/（按文种分目录）、references/（角色定义与技术规范）。

工作流

本工作流为 7 个 Phase 的串行流水线。Phase 间禁止合并，BLOCKING 必须停下等待用户确认。

Phase 1：需求理解与澄清

🚧 GATE：用户提供了公文需求（口头描述、粗略笔记、参考材料，或"写一个关于 xxx 的通知"）。

1.1 需求分析

当用户提供模糊或不完整需求时，通过下表分类提问澄清：

1.2 信息充分性判断（内部）

关键信息 vs 细节信息：

• 关键信息：不可合理推断、必须由用户提供才能完成文档的信息
• 细节信息：可合理推断或后续打磨的具体措辞、小格式偏好

各文种关键信息清单见 references/genres/ 对应文种文件（确认文种后读取）。

• 信息不足：直接向用户提问补充（不等待确认分析方案），补充后进入 Phase 2
• 信息充足：直接进入 Phase 2，到 Phase 3 与分析方案一起打包确认

✅ Checkpoint — 关键信息已齐全，进入 Phase 2。

Phase 2：项目准备

🚧 GATE：Phase 1 完成；关键信息已齐全。

2.1 项目初始化

python3 scripts/project_manager.py init <project_name> --type <document_type>

若有源材料，导入：

python3 scripts/project_manager.py import-sources <project_path> <source_files...> --move

⚠️ 必须用 --move：所有源文件必须移动（而非复制）到 sources/ 归档。

2.2 文种与模板选择

文种分类：

模板推荐流程（仅当用户尚未决定时）：查询 templates/templates_index.json 列出该文种可用模板。

💬 询问用户：根据您的需求，我找到以下模板。您希望：

A) 用现有模板 — 指定模板名或 ID

B) 自由撰写 — 不用模板，按标准结构

用户确认 A 后，复制模板文件到项目目录：

cp templates/<document_type>/<template_name>/* <project_path>/templates/

✅ Checkpoint — 项目就绪、文种和模板已确认，进入 Phase 3。

Phase 3：分析师阶段（🚨 不可跳过）

🚧 GATE：Phase 2 完成；项目就绪、文种和模板已确认。

⛔ 阶段前验证：

ls -la <project_path>/

必须存在：project_info.json

先读角色定义：

Read references/roles/analyst.md

⛔ BLOCKING（合并确认）：分析师必须向用户一次性呈现以下内容并等待确认：

1. 信息确认 — 关键信息是否准确完整（发文机关、主送机关、事项等）
2. 文档结构确认 — 整体结构（章节层级）、预估篇幅、要包含的关键章节
3. 语气与风格确认 — 正式程度、要用/避用术语、政治正确要求
4. 内容要求确认 — 必备内容要素、所需数据/证据、所需引用

产出：

• <project_path>/spec_lock.md — 执行规范锁（含基本信息、语气约束、词汇约束、结构规划、要素清单，是 Writer 的唯一执行依据）

✅ Checkpoint — 阶段交付物完成，自动进入 Phase 4。

Phase 4：写手阶段

🚧 GATE：Phase 3 完成；分析交付物确认且用户已批准。

⛔ 阶段前验证：

ls -la <project_path>/
cat <project_path>/spec_lock.md | head -10

必须存在：spec_lock.md

读角色定义：

Read references/roles/writer.md

写作参数确认（强制）：动笔前，写手必须审阅并输出 spec_lock.md 中的关键写作参数以确保合规。

每段重读 spec_lock（强制）：写每个 section 前，必须 read_file <project_path>/spec_lock.md 并遵循其中的约束。

⚠️ 仅主 Agent：Phase 4 的内容生成必须留在当前主 Agent，禁止委托给子 Agent。

⚠️ 节奏：确认全局写作参数后，写手必须一段接一段连续生成，保持在同一主 Agent 上下文中。

内容生成阶段：

• 逐段顺序生成文档内容 → <project_path>/draft.md

✅ Checkpoint — 全部内容生成完毕，进入草稿预览确认。

📋 草稿预览确认（⛔ BLOCKING）

向用户呈现草稿，等待确认或修改意见：

1. 呈现草稿：展示 draft.md 完整内容
2. 引导反馈：

   📝 草稿已完成，请预览确认

   【草稿概览】
   - 文种：{文种}
   - 字数：{字数}
   - 结构：{主要部分}

   请检查以下方面是否符合预期：
   - 内容方向和侧重点
   - 详略程度
   - 措辞风格
   - 是否有遗漏的内容
   - 是否需要调整结构

   请回复：
   A. 确认通过，继续后续流程
   B. 需要调整（请说明调整意见）

1. ⛔ BLOCKING：等待用户回复

• 用户回复 A（确认）：进入 Phase 5 审核阶段
• 用户回复 B（需调整）：根据用户意见修改 draft.md，修改后重新呈现，再次 BLOCKING 等待确认，循环直到用户确认通过

✅ Checkpoint — 用户确认草稿，进入 Phase 5。

Phase 5：审核阶段（🚨 事实核查+合规审核，不可跳过）

🚧 GATE：Phase 4 完成；文档草稿（draft.md）已生成且用户已确认。

⛔ 阶段前验证：

ls -la <project_path>/draft.md
wc -l <project_path>/draft.md

必须存在 draft.md 且有内容（>50 行）

读角色定义：

Read references/roles/reviewer.md

审核步骤（详见 reviewer.md）：

1. 自动合规检查：运行验证器

   python3 scripts/content_validator.py check <project_path>/draft.md

自动检测包括：禁用词、语气、结构、字数、AI 写作痕迹（11类）

1. 事实核查（9类，AI 驱动）：按 reviewer.md 中的 9 类核查清单逐项核查，硬事实通过 Web 搜索官方来源（gov.cn、各部委官网、地方政府官网、人民日报/新华社）核实
2. 低置信项 BLOCKING：所有低置信事实项必须呈给用户等待确认
3. 问题修正：

   python3 scripts/content_validator.py fix <project_path>/draft.md

产出：

• <project_path>/draft_reviewed.md — 审核修正后的草稿
• <project_path>/review_报告.md — 审核报告（含事实核查结果）

⛔ BLOCKING：若发现政治红线、低置信事实项、重大合规问题，呈给用户并等待批准。

✅ Checkpoint — 审核完成，进入 Phase 6。

Phase 6：格式化与导出

🚧 GATE：Phase 5 完成；审核员阶段已完成并批准草稿。

⛔ 阶段前验证：

ls -la <project_path>/draft_reviewed.md
ls -la <project_path>/review_报告.md

必须存在：draft_reviewed.md、review_报告.md

读角色定义：

Read references/roles/formatter.md

6.1 格式说明

word_generator.py 直接从 draft_reviewed.md 生成符合公文格式的 Word，无需中间格式化层。格式标准统一由 references/standards.json 配置（字体/字号/页边距/行距）。

如需调整格式，修改 references/standards.json 的 format_standards 字段即可，无需改代码。

6.2 生成 Word 文档

⚠️ 以下命令必须逐条单独执行。每条确认成功后再跑下一条。

python3 scripts/word_generator.py generate <project_path> -o exports/
# 输出：exports/<document_name>_<timestamp>.docx

6.3 校验 Word 格式（推荐）

python3 scripts/format_checker.py validate exports/<document_name>_<timestamp>.docx

❌ 禁止跳过格式校验 — 原始 Markdown 导出不合规

❌ 禁止在格式校验前手动编辑 Word 文件

✅ Checkpoint — Word 文档生成并校验完成，工作流结束。

角色切换协议

切换角色前，必须先读对应 reference 文件 — 禁止跳读。输出标记：

## [Role Switch: <角色名>]
📖 Reading role definition: references/<filename>.md
📋 Current task: <简要描述>

工作流恢复

若工作流被中断（上下文丢失、报错、用户介入）：

1. 检查当前状态：ls -la <project_path>/
2. 通过检查哪些输出文件存在，识别最后完成的 Phase
3. 从对应 Phase 恢复

⚠️ 恢复规则：恢复时不得跳过 Phase；重读恢复 Phase 的角色定义；若输出不完整或不一致，从受影响 Phase 重启。

参考资源

references/ 采用三层架构：

• knowledge/（Layer 1）：跨角色共享知识，唯一数据源
• roles/（Layer 2）：角色执行手册，引用 Layer 1
• genres/（Layer 3）：文种专属规范，按需加载

Layer 1 · knowledge/（共享知识，唯一来源）

Layer 2 · roles/（角色执行手册）

Layer 3 · genres/（文种专属规范，按需加载）

索引见 references/genres/README.md。通用字段见 references/genres/_common-fields.md。每个文种文件含该文种的完整规范（字段+结构+专属表述+常见问题）。

其他