Tender Response Writer

Purpose

Generate the service/technical proposal part of a bid response, not the complete commercial/legal bid package. The output must closely follow the tender document, especially the evaluation method, scoring criteria, technical requirements, service requirements, and mandatory response items.

Use formal Chinese bid language with consistent terms such as “我公司”, “采购人”, and “本项目”. Do not invent bidder credentials, staff names, certificates, awards, cases, equipment, or commitments unless supplied by the user or source documents.

When information is uncertain, missing, contradictory, or depends on bidder-specific facts, mark it inline using this exact format: 【需人工确认：具体需要确认的事项】.

Inputs

Use these inputs when available:

• 招标文件.doc or 招标文件.docx in the current workspace.
• Optional ReferenceDocuments/ folder. If it exists, read all available text content as supporting reference material. Ignore images. If it does not exist, continue without asking for it.
• Optional web search when purchaser background, project background, industry facts, or context is insufficient. Prefer official or authoritative sources.
• Bundled script scripts/build_bid_response_docx.py, used to merge dynamic modelN.md module files into the final formatted Word document.

If both .doc and .docx tender files exist, use the newest or most complete file unless the user specifies otherwise. If the file cannot be read directly, convert or extract text with an appropriate document-reading method before analysis.

Workflow

1. Extract Tender Key Points

Read the tender document and create KeyPointsOfTheTenderDocuments.md in the current workspace.

Capture all information needed for downstream service/technical proposal writing. Include, at minimum:

• 项目基本信息: 项目名称, 项目编号, 采购人, 代理机构, 预算金额或最高限价, 投标截止时间, 开标时间, 服务地点.
• 采购对象与项目背景: 采购人/服务对象背景, 项目建设背景, 目标, 使用场景, 业务痛点.
• 技术/服务要求: 服务范围, 工作内容, 技术指标, 质量要求, 成果要求, 交付物.
• 商务中与服务方案相关的要求: 服务期限, 进度要求, 验收要求, 售后服务, 知识产权, 保密, 安全, 培训, 运维.
• 资格和证明材料要求: 人员证书, 业绩, 社保, 资质, 案例, 合同, 承诺函等.
• 废标/否决性条款: 实质性响应条款, 不允许偏离条款, 无效投标情形, 签字盖章要求, 文件格式要求.
• 评分标准: 逐项记录评分项名称, 分值, 评分细则, 得满分条件, 扣分/不得分情形, 可响应方向, 证明材料.
• 服务/技术方案相关评分项: 单独汇总所有需要在方案正文中展开的评分点。
• 应答文件格式要求: 章节结构, 技术文件目录, 偏离表, 附件表格, 装订/电子文件要求.
• 必须逐点应答清单: 将招标文件中必须回应的要求列成清单。
• 需人工确认事项: 对原文不清晰、信息缺失、可能影响废标、报价、资质或真实性的事项单独列出，并统一使用 【需人工确认：...】 格式。

After KeyPointsOfTheTenderDocuments.md is written, use it as the main tender basis. Do not repeatedly reload the full tender document unless the key-points file is missing information, contains ambiguity, or conflicts with another source.

2. Plan Dynamic Proposal Modules

Create ModulePlan.md before generating any module content.

Do not assume the proposal always has six fixed sections. First analyze the tender’s evaluation method, procurement requirements, technical/service requirements, and required response-file structure. Then decide the necessary modules for the service/technical proposal.

Common modules may include, but are not limited to:

• 项目背景
• 需求理解/需求痛点分析
• 总体服务方案/总体技术方案
• 创意方案/策划方案（only when relevant）
• 实施方案/执行方案
• 项目进度计划
• 项目组织方案/人员配置
• 质量保障方案
• 售后服务方案
• 培训方案
• 运维服务方案
• 应急预案
• 安全保密方案
• 风险控制方案
• 验收与交付方案

For each planned module, record in ModulePlan.md:

• Module file name: model1.md, model2.md, ... modelN.md.
• Module title.
• Why this module is needed.
• The tender requirements and scoring items it responds to.
• Required subtopics.
• Suggested length or emphasis by score weight.
• Required source context, such as KeyPointsOfTheTenderDocuments.md, previous abstracts, and optional ReferenceDocuments/.

Keep modules aligned with scoring logic. High-score items and explicit scoring criteria should receive more detailed, targeted responses. Low-score or procedural items can be shorter but must still be complete.

3. Generate Modules One by One

Generate each module independently according to ModulePlan.md, in order, and write it to modelN.md.

After each module except the last, write modelNAbstract.md to preserve reusable context for later modules. The abstract should summarize only facts, commitments, creative direction, methods, constraints, risks, and cross-module dependencies that later modules need.

Use this writing logic for every module:

• Read KeyPointsOfTheTenderDocuments.md.
• Read ModulePlan.md.
• Read previous modelNAbstract.md files when relevant.
• If ReferenceDocuments/ exists, read its text content only when the module can benefit from it. Treat it as supporting material, never as superior to the tender document.
• If ReferenceDocuments/ does not exist, continue based on the tender document and available context.
• Analyze the scoring items mapped to the module and write toward full-score conditions.
• Explicitly address every relevant tender requirement. Do not omit mandatory response items.
• Prefer concrete, executable, project-specific writing over generic slogans.
• Avoid decorative Markdown in module prose. Use Markdown only for heading levels (#, ##, ###, etc.) needed by the merge script, optional image placeholders, and simple pipe tables when tabular comparison is genuinely useful. Do not use horizontal rules such as ---, decorative separators, HTML, or block quotes unless the user explicitly asks for them.
• Avoid Markdown emphasis markers in prose when possible. If emphasis is needed, keep it sparse; the Word merge script will convert **加粗** to real Word bold text, but the preferred source text is clean formal prose.
• If a diagram or image should be inserted later, write a clear image placeholder using Markdown image syntax with descriptive alt text, such as ![服务体系示意：前期策划 → 执行服务 → 后期制作 → 数据复盘]. Do not invent an image file path unless an actual image file exists. The merge script will convert this into a visible Word placeholder for later manual or automated image insertion.
• If a flowchart, organization chart, framework diagram, or other text diagram is easier to express as a fenced code block, use a nearby heading that names the diagram type, such as ### 组织架构图 or ### 质量控制流程. The merge script will infer the diagram type from the heading and content, then convert the code block into a visible Word image placeholder, such as [图片占位：组织架构图：...] or [图片占位：流程图：...], rather than leaving code formatting in the document.
• If content is naturally tabular, such as schedule, role division, service response levels, risk matrix, or scoring-response mapping, a simple Markdown pipe table may be used. Keep cells concise. The merge script will convert the pipe table into a real Word table.
• If actual bidder information is unknown, use cautious language such as “我公司将”“我公司拟”“我公司可根据采购人要求”, and list missing facts as items requiring user confirmation.
• For any uncertain, missing, contradictory, or bidder-specific information, write an explicit marker in the exact format 【需人工确认：...】. Examples: 【需人工确认：投标单位需补充项目负责人姓名及导演证编号】, 【需人工确认：招标文件第一章投标截止时间需以原文为准】. Do not hide uncertainty in vague wording.

When useful during drafting, a module may end with an internal section named “本章响应招标文件要求/评分项”. The final Word merge script will remove this section automatically, so it can be used for traceability during drafting.

4. Merge Modules Into Final Word Document

After all modelN.md files are complete, run the bundled script scripts/build_bid_response_docx.py from this skill to generate the final Word document.

Recommended command pattern:

python path/to/tender-response-writer/scripts/build_bid_response_docx.py --workspace . --output 投标文件技术应答整合稿.docx

The script uses ModulePlan.md when present to determine module order by reading modelN.md references. If no module order is found in ModulePlan.md, it automatically merges all modelN.md files in numeric order.

Default output:

• 投标文件技术应答整合稿.docx

The script must:

• Merge dynamic modules in planned/numeric order.
• Exclude each module’s “本章响应招标文件要求/评分项” section from the final document.
• Remove standalone Markdown horizontal rules such as ---, ***, and ___.
• Convert inline Markdown bold syntax such as **重点内容** into real Word bold text instead of leaving ** characters in the document.
• Convert Markdown image placeholder syntax such as ![服务体系示意：...] or ![服务体系示意：...](image.png) into a centered bold Word placeholder like [图片占位：服务体系示意：...].
• Convert fenced code blocks that contain flowchart-like, organization-chart-like, framework-like, or other diagram content into centered bold Word image placeholders. Infer the placeholder type from the nearest heading and code block content, using labels such as 流程图, 组织架构图, 体系框架图, or 示意图. Do not leave triple backticks or ASCII diagram text in the final document.
• Convert simple Markdown pipe tables into real Word tables. Do not leave raw | 阶段 | 时间 | or separator rows such as |---|---| in the final document.
• Convert every 【需人工确认：...】 marker into red bold Word text so review items are highly visible.
• Clean obvious leftover Markdown emphasis markers so raw Markdown syntax does not appear in the final Word正文.
• Set module titles as Word Heading 2.
• Set the next heading level as Word Heading 3, then deeper levels as Heading 4 and Heading 5 when present.
• Apply heading numbering by Word heading level:
• Heading 2: （一）
• Heading 3: 1.
• Heading 4: （1）
• Heading 5: ①
• Strip existing manual heading numbers before adding normalized numbering.
• Set Chinese font to 宋体, English font to Times New Roman.
• Set body font size to 小四（12 pt）.
• Set body paragraphs to first-line indent of two Chinese characters.
• Set body line spacing to 1.5.
• Set paragraph spacing before and after to 0.
• Insert page breaks between major modules.

Quality Checklist

Before finishing, verify:

• KeyPointsOfTheTenderDocuments.md exists and covers project information, scoring criteria, mandatory response items, risk items, personnel, progress, after-sales/service, and file-format requirements.
• ModulePlan.md exists and maps every modelN.md module to tender requirements and scoring items.
• All planned modelN.md files exist.
• Abstract files exist for all generated modules except the last, unless a specific module has no downstream relevance.
• 投标文件技术应答整合稿.docx exists after the merge step.
• Every relevant tender requirement and scoring item has a response path in at least one module.
• Formal terms are consistent: “我公司”, “采购人”, “本项目”.
• No unsupported company credentials, named staff, certifications, awards, or past projects are fabricated.
• Optional reference documents are used only as supporting material and never override tender requirements.
• Open questions or missing facts that require user confirmation are clearly listed.
• Every uncertain, missing, contradictory, or bidder-specific item is marked as 【需人工确认：...】.
• The final Word document does not contain “本章响应招标文件要求/评分项”.
• The final Word document does not contain raw Markdown artifacts such as standalone --- separators, visible **加粗** markers, raw ![图片说明] syntax, triple-backtick code blocks, or raw pipe table separator rows like |---|---|. Needed images and flowcharts should appear as [图片占位：...] placeholders, and simple tables should appear as real Word tables.
• All 【需人工确认：...】 text in the final Word document is red and bold.
• The final Word document uses the required heading levels and numbering: Heading 2 （一）, Heading 3 1., Heading 4 （1）, Heading 5 ①.
• The final Word document uses 宋体 for Chinese text, Times New Roman for English text, 小四正文, first-line indent, 1.5 line spacing, and 0 paragraph spacing before/after.