Skill-BidCreater/SKILL.md

name	description
cn-it-bid-writer	面向中文 IT/系统集成类投标项目的投标文件生成与交付 skill，负责基于当前项目目录内的招标文件和项目资料完成拆标、目录定稿、双产物正文填写与最终交付。当用户需要对招标文件进行操作的时候，可以启用这个skill。

cn-it-bid-writer

这是什么

这是一个由AI驱动， 用中文撰写标书的skill

目标

• outline 产出技术标书和商务(包含其它部分除技术标)标书目录；默认交付顺序是先技术目录，后商务目录
• outline+business 通过产出的商务把标书目录，生成完整商务(包含除技术标)之外的标书。
• outline+technical 通过产出的技术把标书目录，生成完整技术标书。

成品导向原则

门禁、脚本检查和渲染校验都只是基础门槛，不是完成定义。 本 skill 的最终目标是生成可直接用于投标的中文标书；无论目录、标题、正文、图表、附件还是最终 Word 排版，都必须服务“可直接交付给评委或采购人阅读”的成品标准。

默认文档格式基线如下，若招标文件或正式模板另有明确要求，则以后者优先：

1. 标题编号默认使用 1 / 1.1 / 1.1.1 / 1.1.1.1。
2. 一级标题默认黑体、小三；二级标题黑体、四号；三级标题黑体、小四；四级标题默认楷体或黑体小四，并在同一项目内保持统一。
3. 正文默认宋体、小四，首行缩进 2 字符，1.5 倍行距。
4. 表格默认宋体，五号或小五，表头加粗。
5. 图、表、附件标题统一编号，默认采用 图3-1 XXX / 表4-2 XXX / 附件5-1 XXX。
6. 占位内容必须显式标明“占位/待替换/待补充”，不得伪装成正式材料。

执行规则，严格遵守

1. 必须按照规定workflow执行。
2. 所有输出只能写到和用户提供的目录下的 work/、reports/、final/。所有创建的文件也只能在用户提供的这个目录下。
3. 不能补充任何脚本，只能用项目现有脚本，所有脚本在scripts目录下。
4. 脚本执行需要使用本 skill 内 .venv/作为虚拟环境来执行，脚本启动命令是虚拟环境的python，不是python3。记住是本skill当前文件夹下.venv/目录，不是你现在的工作目录，是本skill的目录。
5. 所有操作word脚本使用本skill提供的工具脚本

现有工具

以下脚本属于本 skill 当前可用工具：

• scripts/docx_index.py 用途：读取并索引现有 Word 标书或模板结构，提取标题、段落、列表、表格等节点信息，供 AI 先理解文档结构再决定写入位置。

• scripts/docx_query.py 用途：按标题、正文文本、锚点等方式查询 Word 中的目标位置，供 AI 在写标书前精确定位章节、段落或表格。

• scripts/docx_create.py 用途：根据结构化输入直接创建新的 Word 文档，适合生成目录版 DOCX、占位稿或空白章节骨架。

• scripts/outline_check.py 用途：对目录阶段的结构化结果做门禁检查，重点检查目录深度、抽象标题下钻、对象化节点、重复切面和商务中的技术占位。

• scripts/outline_export.py 用途：在目录门禁通过后导出结构化 JSON，并生成最终目录版 DOCX。

• scripts/docx_patch.py 用途：对现有 Word 标书执行插入、替换、删除等修改操作，把已经生成好的标书内容准确写入指定位置。

• scripts/render_docx.py 用途：对写入后的 Word 标书做渲染校验，尝试导出 PDF 和页面图，检查文档是否损坏或排版异常。

• scripts/docx_cli.py 用途：统一调用 DOCX 索引、查询、写入和渲染能力。

具体操作方式、参数说明和示例见 references/docx-ops.md。

References

• 理解招标：references/understandbid.md
• 目录阶段：references/outline-stage.md
• DOCX 脚本接口：references/docx-ops.md
• DOCX 渲染与交付：references/docx-assembly.md

非 outline 阶段规则

business

1. 只写商务及其他文件中的 workflow_bucket=business，并配合 workflow_bucket=other 文件中的技术占位。
2. 商务事实只认招标文件明示内容和用户真实材料。
3. 缺件时只允许占位、缺件说明、附件索引空位或阻塞说明。
4. 不得在商务及其他中补写任何技术正文。
5. 只能写 final_outline_business_other.json 中的叶子节点；若节点仍过于抽象，必须回退目录阶段。

商务材料必须进一步分桶组织，至少按以下业务桶判断归属、缺件和证据：

1. 资格与准入

• 营业执照、资质证书、许可证、注册登记、法定代表人身份证明、授权委托等。

2. 合规声明与承诺

• 无重大违法声明、联合体声明、原厂承诺、保密承诺、售后承诺、真实性声明等。

3. 商务响应

• 商务条款响应、工期/服务期、交付地点、付款条件、质保期、偏离表、响应表等。

4. 业绩与团队

• 类似业绩、项目负责人、实施团队、履历、证书、服务能力证明等。

5. 财务与纳税社保

• 财务报表、审计报告、纳税证明、社保证明、开户信息等。

6. 附件与索引

• 招标文件要求附后的证明材料、附件目录、盖章页、扫描件索引、技术转引占位等。

处理要求：

1. 每个商务节点都应先判断属于哪个业务桶，再决定承载内容和缺件策略。
2. 资格与准入、合规声明与承诺 中的硬门槛缺失，应优先标记为高风险或阻塞。
3. 业绩与团队、财务与纳税社保 不得用通用表述冒充真实材料。
4. 附件与索引 只负责承载证据入口和材料定位，不替代正文判断。

technical

1. 只写 work/final_bid_content_technical.json 中的 workflow_bucket=technical。
2. 技术正文开始前，必须先明确总目标、建设主线、分系统主次和评委检索路径。
3. 技术材料不足时，可以补专业技术方案，但不能伪造既有事实，必须保证技术框架和方案前后一致。
4. 技术正文必须展开到架构、模块、实施、培训、验收、运维、风险控制等承载位。
5. 图表必须服务具体评审主题，不能为了看起来专业而堆砌。
6. 技术方案必须按章节填充，不允许一次性生成全部技术方案内容。最高允许一次性填充三级子标题。
7. 只能对 final_outline_technical.json 中的叶子节点写正文，不允许直接用父节点概述代替其全部子节点。
8. 若叶子节点仍然是抽象标题，必须先回退目录阶段继续下钻，不得硬写正文。

other/finalize

3. 不额外创造默认“报价子 workflow”。
4. 通过总体验收前，不得对外宣称“完整投标文件”。

final

生成：

• final/技术标.docx
• final/商务及其他.docx

最终验收

导出前必须同时检查：

1. 废标/否决项 是否已有明确承载位、证据位或阻塞说明。
2. 合规项 是否完整进入正式目录和交付物。
3. 评分项 是否已得到优先展开，且目录深度与正文强度匹配评分重点。
4. 技术标目录是否合法。
5. 商务及其他目录是否合法，且技术占位位置正确。
6. 技术正文深度是否匹配项目复杂度。
7. 图表是否真的承载评审主题。
8. 证据链是否完整。

除上述业务验收外，还必须满足文档成品验收：

1. 标题命名自然、专业、适合直接作为投标 Word 目录使用，不允许出现只为通过门禁而生的生硬标题。
2. 标题编号连续，标题层级、字体、字号、段落格式符合默认标书格式或模板格式。
3. 图表编号、附件编号连续且可追溯。
4. 目录、正文、图表、附件、占位提示在文档中的位置关系正确，不错位、不跳号、不混册。
5. 最终 DOCX 渲染校验、格式校验、编号校验、占位扫描应共同通过后，才可视为“可交付”。

任一项不过，不得汇报“已完成”，但可以生成完整的占位草稿。占位内容仅限于资质、商务、声明、索引、技术转引等非技术实质内容；技术部分必须完整呈现于技术标，不得用占位代替。