Run any Skill in Manus with one click

Get Started

bid

Stars0

Forks0

UpdatedMay 19, 2026 at 06:27

标书撰写技能。当处理 ~/Dev/Work/shared/bids/ 下的标书项目，需要解析招标文件、搭建章节框架、盘点参考资料、走四阶段写作管线时触发。

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

zengtianli

zengtianli/cc-configs

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

name	bid
description	标书撰写技能。当处理 ~/Dev/Work/shared/bids/ 下的标书项目，需要解析招标文件、搭建章节框架、盘点参考资料、走四阶段写作管线时触发。

bid — 标书撰写

标书项目集中在 ~/Dev/Work/shared/bids/，方法论沉淀在 ~/Dev/Work/shared/bids/CLAUDE.md。本 skill 是入口，告诉你做什么、按什么顺序、用哪个工具。

核心原则

三级优先级：脚本 > skill > CC 直接。能脚本化的不要 AI，能 skill 的不要裸写。
主会话不写正文：只做规划、调度、验证。正文一律交 subagent，并带 4 维度约束。
章节-评分硬绑定：每章顶部必须贴"得满分要求"原文，写作 subagent 必须逐项响应。
不问节奏：拿到任务直接按"把它做好"全力推进，不要问截止日期/紧不紧。

标书撰写的 6 个阶段

阶段 1 — 项目初始化

cp -r ~/Dev/Work/shared/bids/_template ~/Dev/Work/shared/bids/{slug}

把招标文件原件丢进 招标文件/，把所有参考资料丢进 参考/。填 _project.yaml（项目名、编号、采购人、预算、截止日期）。

阶段 2 — 招标文件解析

🚧 zbwj_parse.py 待立（未来合进 ~/Dev/tools/doctools/scripts/document/）。当前先用 bid_doc_parser.py 做 doc/docx → md，评分表手工提取。

python3 ~/Dev/tools/scripts/scripts/document/bid_doc_parser.py ~/Dev/Work/shared/bids/{slug}/招标文件/
# 输出 招标文件/*.md；scoring.json 需手工从 md 里抽评分表

产物目标：

招标文件/*.md（doc/docx → md，pandoc）
招标文件/scoring.json（提取的评分表：序号 / 评分项 / 分值 / 得满分要求）
技术标框架.md（按评分项生成章节骨架，每章贴好"得满分要求"）

人工复核 scoring.json，确保没漏分项。

阶段 3 — 参考资料盘点

让 Claude 读 参考/ 下所有文档，生成 参考/_index.md：

| 文件 | 涵盖章节 | 可复用内容 | 是否最新 |

重点：标出"可直接复用 / 需更新数据 / 需新写"三类。对延续项目，老中标稿是金矿，模板章（业绩、组织、质量、售后）几乎可以整段搬。

阶段 4 — 写作（subagent + 4 维度约束）

按 技术标框架.md 逐章派 subagent 写作，输出到 成果/md/。每个 subagent prompt 必须包含：

该章的"得满分要求"
D1-D4 维度约束（见 ~/Dev/Work/shared/bids/CLAUDE.md）
参考资料盘点结果（告诉它哪段抄哪里）
当前章节的数据来源约束

阶段 5 — 管线脚本（部分已立 / 部分 🚧）

已立（~/Dev/tools/doctools/scripts/document/）：report_quality_check.py / md_docx_template.py / chart.py

🚧 待立：bid_standardize.py（已归档 _archive/scripts-archive/，待重立到 doctools） / chart_insert.py / md_merge.py（只有 raycast .sh 包装）

cd ~/Dev/Work/shared/bids/{slug}/成果/

# 5.1 质量修复（禁用词、数据来源标注）
python3 ~/Dev/tools/doctools/scripts/document/report_quality_check.py md/ --bid --fix --output-dir md_clean/

# 5.2 🚧 结构标准化（bid_standardize.py 归档在 _archive/scripts-archive，待重立到 doctools）
#     暂时：手工过一遍评分引用 / 标题编号 / 加粗

# 5.3 生成图表 PNG（统一走 chart.py + JSON 配置）
python3 ~/Dev/tools/doctools/scripts/document/chart.py charts/*_config.json

# 5.4 🚧 ASCII art → PNG 引用（chart_insert.py 未立，先手工替换）

# 5.5 合并 + 转 docx
bash ~/Dev/tools/doctools/raycast/commands/md_merge.sh md_final/ -o merged.md  # md_merge.py 未立，用 .sh 包装
python3 ~/Dev/tools/doctools/scripts/document/md_docx_template.py merged.md -o 技术标.docx

阶段 6 — 终审

跑 report_quality_check.py --check 看残留问题
自审：每章是否都响应了"得满分要求"每一条
D3 预判：扮演评审专家，能不能问倒自己

4 维度写作约束（subagent 必带）

维度	检查要点
D1 溯源链	每个结论有推导过程，筛选链条完整不跳步
D2 立场措辞	站乙方立场，委婉表达，风险抛给甲方/政策
D3 预判评审	写完假装审查专家，能否问倒自己
D4 数据纵深	总量→结构→趋势→对比，先全貌后细节

模板章（跨项目高复用）

下列章节高度模板化，新项目可从老项目搬：

质量保证措施（评分常 3 分）
售后服务方案（注意各地"当天到现场"得满分的要求）
进度保障措施
组织架构与人员配置
业绩与资质

参考：~/Dev/Work/shared/bids/qiantang-monitoring-2026/成果/md_final/11.md 12.md

不要做的事

❌ 不要问用户"截止日期紧不紧 / 项目什么状态 / 今天做到哪一步"
❌ 主会话不要直接写正文，一定派 subagent
❌ 不要跳过 4 维度约束
❌ 不要手画图表，所有图走 chart_*.py + JSON 配置
❌ 不要在 md_final 之后再手动改文字（改 md_clean，重跑管线）

More from this repository

same repository

dispatch

zengtianli/cc-configs

并行 agent team 处理多目标任务，每个 agent goal-loop 自闭环；产出 HTML 报告给用户看。用户说 "dispatch / 派 agent / agent team 做 / 多并行 / 一次性处理 N 个 / 全部一次性 / 不留尾巴 / 目标驱动并发 / P1=N 直接" 等触发。

2026-05-230

dws

zengtianli/cc-configs

管理钉钉产品能力(AI表格/日历/通讯录/群聊与机器人/待办/审批/考勤/日志/DING消息/开放平台文档/钉钉文档/钉钉云盘/AI听记/邮箱/在线电子表格/知识库等)。当用户需要操作表格数据、管理日程会议、查询通讯录、管理群聊、机器人发消息、创建待办、提交审批、查看考勤、提交日报周报（钉钉日志模版）、读写钉钉文档、上传下载云盘文件、查询听记纪要、收发邮件、读写在线电子表格(axls)、管理钉钉知识库时使用。

2026-05-230

html-fig

zengtianli/cc-configs

作图默认方法 — 自包含 HTML/SVG 所见即所得预览（多样式）→ 用户批准 → 导出 SVG+PNG+PDF 多格式 + 带下载/复制按钮的 HTML。任何"作图/可视化/改样式/好看点/热图/出图/preview"触发；尤其投稿级、需反复调样式、用户给旧图截图要复刻的场景。

2026-05-230

sessions

zengtianli/cc-configs

一条命令出 session 现状 + ROI 全景 HTML（包装 cc_sessions.py index + regen_dev_roi.py，输出规范 /debrief 风 HTML，含 vault nav + KPI clickable + per-project 表）。用户说「列会话 / session 现状 / 会话 ROI / sessions / /sessions / 看下 session / 清理候选」时触发

2026-05-230

file-cleanup

zengtianli/cc-configs

文件清理族 — downloads 子命令把 ~/Downloads 顶层 entry 按规则派送到 ~/Dev / personal-vault；zip 子命令把 ~/Dev 下 raw 归档（.zip/.rar/.7z）外挪到 ~/zip/<Dev 镜像>，原位置留 _ZIP-INDEX.md 指针。触发：整理下载目录 / Downloads 太乱 / 下载里的东西归一下 / zip 外挪 / 归档外挪 / Dev 太臃肿 / 把压缩包挪走 / raw 归档清理。

2026-05-220

retro-digest

zengtianli/cc-configs

把一批散落的 retro/会话记录按主题线合并成少数 HTML 知识节点（起因→迭代→现状），原文归档到 _archive，织入 wiki 知识网。用户说"4月所有会话讲了啥+修到哪""合并/整合 retro 不要思维负担""摘要这些 retro/会话"时触发。

2026-05-220

name	bid
description	标书撰写技能。当处理 ~/Dev/Work/shared/bids/ 下的标书项目，需要解析招标文件、搭建章节框架、盘点参考资料、走四阶段写作管线时触发。

bid — 标书撰写

标书项目集中在 ~/Dev/Work/shared/bids/，方法论沉淀在 ~/Dev/Work/shared/bids/CLAUDE.md。本 skill 是入口，告诉你做什么、按什么顺序、用哪个工具。

核心原则

三级优先级：脚本 > skill > CC 直接。能脚本化的不要 AI，能 skill 的不要裸写。
主会话不写正文：只做规划、调度、验证。正文一律交 subagent，并带 4 维度约束。
章节-评分硬绑定：每章顶部必须贴"得满分要求"原文，写作 subagent 必须逐项响应。
不问节奏：拿到任务直接按"把它做好"全力推进，不要问截止日期/紧不紧。

标书撰写的 6 个阶段

阶段 1 — 项目初始化

cp -r ~/Dev/Work/shared/bids/_template ~/Dev/Work/shared/bids/{slug}

把招标文件原件丢进 招标文件/，把所有参考资料丢进 参考/。填 _project.yaml（项目名、编号、采购人、预算、截止日期）。

阶段 2 — 招标文件解析

🚧 zbwj_parse.py 待立（未来合进 ~/Dev/tools/doctools/scripts/document/）。当前先用 bid_doc_parser.py 做 doc/docx → md，评分表手工提取。

python3 ~/Dev/tools/scripts/scripts/document/bid_doc_parser.py ~/Dev/Work/shared/bids/{slug}/招标文件/
# 输出 招标文件/*.md；scoring.json 需手工从 md 里抽评分表

产物目标：

招标文件/*.md（doc/docx → md，pandoc）
招标文件/scoring.json（提取的评分表：序号 / 评分项 / 分值 / 得满分要求）
技术标框架.md（按评分项生成章节骨架，每章贴好"得满分要求"）

人工复核 scoring.json，确保没漏分项。

阶段 3 — 参考资料盘点

让 Claude 读 参考/ 下所有文档，生成 参考/_index.md：

| 文件 | 涵盖章节 | 可复用内容 | 是否最新 |

重点：标出"可直接复用 / 需更新数据 / 需新写"三类。对延续项目，老中标稿是金矿，模板章（业绩、组织、质量、售后）几乎可以整段搬。

阶段 4 — 写作（subagent + 4 维度约束）

按 技术标框架.md 逐章派 subagent 写作，输出到 成果/md/。每个 subagent prompt 必须包含：

该章的"得满分要求"
D1-D4 维度约束（见 ~/Dev/Work/shared/bids/CLAUDE.md）
参考资料盘点结果（告诉它哪段抄哪里）
当前章节的数据来源约束

阶段 5 — 管线脚本（部分已立 / 部分 🚧）

已立（~/Dev/tools/doctools/scripts/document/）：report_quality_check.py / md_docx_template.py / chart.py

🚧 待立：bid_standardize.py（已归档 _archive/scripts-archive/，待重立到 doctools） / chart_insert.py / md_merge.py（只有 raycast .sh 包装）

cd ~/Dev/Work/shared/bids/{slug}/成果/

# 5.1 质量修复（禁用词、数据来源标注）
python3 ~/Dev/tools/doctools/scripts/document/report_quality_check.py md/ --bid --fix --output-dir md_clean/

# 5.2 🚧 结构标准化（bid_standardize.py 归档在 _archive/scripts-archive，待重立到 doctools）
#     暂时：手工过一遍评分引用 / 标题编号 / 加粗

# 5.3 生成图表 PNG（统一走 chart.py + JSON 配置）
python3 ~/Dev/tools/doctools/scripts/document/chart.py charts/*_config.json

# 5.4 🚧 ASCII art → PNG 引用（chart_insert.py 未立，先手工替换）

# 5.5 合并 + 转 docx
bash ~/Dev/tools/doctools/raycast/commands/md_merge.sh md_final/ -o merged.md  # md_merge.py 未立，用 .sh 包装
python3 ~/Dev/tools/doctools/scripts/document/md_docx_template.py merged.md -o 技术标.docx

阶段 6 — 终审

跑 report_quality_check.py --check 看残留问题
自审：每章是否都响应了"得满分要求"每一条
D3 预判：扮演评审专家，能不能问倒自己

4 维度写作约束（subagent 必带）

维度	检查要点
D1 溯源链	每个结论有推导过程，筛选链条完整不跳步
D2 立场措辞	站乙方立场，委婉表达，风险抛给甲方/政策
D3 预判评审	写完假装审查专家，能否问倒自己
D4 数据纵深	总量→结构→趋势→对比，先全貌后细节

模板章（跨项目高复用）

下列章节高度模板化，新项目可从老项目搬：

质量保证措施（评分常 3 分）
售后服务方案（注意各地"当天到现场"得满分的要求）
进度保障措施
组织架构与人员配置
业绩与资质

参考：~/Dev/Work/shared/bids/qiantang-monitoring-2026/成果/md_final/11.md 12.md

不要做的事

❌ 不要问用户"截止日期紧不紧 / 项目什么状态 / 今天做到哪一步"
❌ 主会话不要直接写正文，一定派 subagent
❌ 不要跳过 4 维度约束
❌ 不要手画图表，所有图走 chart_*.py + JSON 配置
❌ 不要在 md_final 之后再手动改文字（改 md_clean，重跑管线）