- 先判断是不是法定公文 15 种；不属于法定公文时，再判断是否属于常见正式材料，如工作方案、总结、简报、专报、讲话稿、汇报材料。
- 判断行文方向：上行、下行、平行或公开发布；避免把“报告”写成“请示”，把“函”写成“通知”。
- 判断发文主体、主送对象、事项性质、时间要求，以及是否需要请求批准、答复请示、公开告知或形成会议纪要。
- 目标文种确定后，先应用共享的防编造约束
prompts/core/doc-type-guardrails.md，再读取对应文种目录中的spec.md，按其中的“写作规则”“版式要求”“模板”章节处理，并按meta.toml中的font_profile读取字体方案、按layout_profile读取版式参数；如存在examples.md，可按需读取。 - 如果没有独立文种模板，退回
prompts/core/fallback-template.md的骨架。
- 需要请求上级批准：优先用“请示”
- 需要回复下级请示：优先用“批复”
- 需要部署安排工作：优先用“通知”
- 需要提出原则性指导办法：优先用“意见”
- 需要作出重要处理、奖惩、调整：优先用“决定”
- 需要公开告知重大事项：优先用“公告”或“通告”
- 需要向上级汇报情况：优先用“报告”
- 需要平行沟通商洽或答复：优先用“函”
- 需要形成会议议定事项：优先用“纪要”
- 需要整理新闻动态或专题情况：优先用“简报”或“专报”
- 先保证“文种正确”，再追求文风和修辞。
- 法定公文优先使用法定文种名称，不混用、不自造文种。
- 高频文种优先套用独立模板；结构不完整时使用占位符补齐，而不是删掉关键章节。
- 未明确要求“压缩、简写、提纲化、只保留核心部分”时，默认优先采用目标文种较完整的常见结构，尽量保留该文种常见的组成元素、可选板块和执行信息，再由用户后续删减。
- 解读各文种规则时，应区分
必备、常见、条件项、地方或系统样式、项目自定义五类口径；地方或系统样式和项目自定义只能按用户模板或本项目约定使用，不得误写成全国通行必备要素。 - 进入具体文种后，要按对应
spec.md中各板块职责起草，逐段自检“这一部分是否回答了它本来该回答的问题”；不能只保留标题框架而用空泛套话填充。 - 起草完成后，应反向核对各层次是否分工清楚：背景段回答“为什么写”，进展段回答“做到哪里”，问题段回答“卡在哪里”，建议或要求段回答“下一步怎么做、由谁做、何时做”。
- 对目标文种通常应包含的结构项，如主送单位、落款、日期等，若用户已提供对应信息，则据实填入；若用户未提供，则保留对应占位符，不得因信息缺失而省略该结构。
- 对需要设置附注的文稿，如用户已提供联系人、固定电话、手机或公开属性等信息，则在附注处据实写入；未提供时保留对应占位符，不擅自省略或虚构。
- 本项目默认将
请示、报告、通知、函、回复函、公告、通告设为保留附注联系人信息的文种；除非用户明确要求删除，否则起草时默认保留（联系人：[联系人] 联系电话：[固定电话]，[手机号]）。 - 对涉及其他部门、其他地区、其他单位职责的事项，如材料未明确写明已协商一致、联合行文或共同决定，不得直接写成“经研究同意”“联合决定”“共同推进”等确定口径。
- 长篇方案、办法、细则、名单、表格、台账、清单等实体内容，如更适合作为附件承载，应优先在正文中做提要式交代，再通过附件承接，不把附件全文机械重复进正文。
- 需要承载图片、流程图、示意图、截图、现场照片时，普通公文和内部材料默认优先使用
附件、附图或附表；只有当前文种明确属于技术说明、操作指南、标准性资料，或用户明确要求时，才使用附录结构。 - 图片类附件应写清编号、标题和说明文字；如图片来源、拍摄时间、数据截止时点、适用范围或“仅供示意、以正式图件为准”等提示对理解结果有影响，应一并保留。
- 对目标文种通常不设置的结构项，不要机械补齐；是否设置主送单位、落款、日期，应以当前文种
spec.md和模板为准。 - 是否设置附注，应以当前文种
spec.md和模板为准；请示类公文优先保留附注结构。 - 是否设置版记，应以当前文种
spec.md、用户模板或系统样式为准；标准公文版记常见要素通常是抄送机关、印发机关、印发日期，分送、主送移入版记等做法属于地方或系统样式，审核属本项目内部模板字段。 - 用户要求保存文件但未指定路径时，默认在
~/official-document-drafting-output/下按任务类型建立子目录。 - 用户要求保存文稿但未指定文件名时，默认采用
YYYYMMDD-标题-vNN命名；同一次任务如需同时保存离线提示词、附带说明等辅助生成文件，则在版本号后追加产物类型后缀，如YYYYMMDD-标题-v01-提示词.md、YYYYMMDD-标题-v01-说明.md，避免与最终成稿重名。