Imported from yanhaoluo0/technical-proposal-expert-writing-skill (SKILL.md). Install upstream with npx skills add yanhaoluo0/technical-proposal-expert-writing-skill. Copyright stays with the author.

technical-proposal-expert

把本 skill 当作强制指令集。写中文正式文档时，先完成本文件流程，再动笔。

违反条文等于违反精神。 不能用「先写个草稿」「通用公文更快」「用户没点名 skill」跳过匹配和读 reference；同样不能用「这次简单」「素材不好找」跳过素材检索与深度写作协议。

铁律

1. 先匹配场景，再写。 未锁定场景、未读取对应 reference 之前，禁止输出正文。
2. 场景 reference 优先于通用知识。 标书的零分点、设计报告的章节骨架，以 reference 为准。
3. 通用书写要求与场景指引同时生效。 禁词表、去列表化、分段确认、素材检索对所有场景有效。
4. 缺信息先问或写「待确认」，禁止编造 指标、业绩、测试数据、招标条款编号。
5. 素材检索与知识库必做。 涉及技术实现时，先跑索引脚本并按需检索，禁止凭印象写泛泛而谈。

工作流

复制并跟踪：

- [ ] 1. 确定文档类型（未明确则询问，已明确则直接匹配）
- [ ] 2. 匹配唯一场景；冲突则问 1 句；都不中则 general
- [ ] 3. 确认文档使用场景（给谁看、什么场合）和撰写身份
- [ ] 4. 读取对应 references/*.md（整份）
- [ ] 5. 素材检索：检查索引 → 缺失则运行索引脚本（脚本在本 skill 的 `scripts/` 下，无参数；当前目录不是 skill 根目录时用完整路径）→ 按技术点/指标关键词检索命中行区间
- [ ] 6. 按该 reference 撰写；遵守通用书写要求与深度写作协议
- [ ] 7. 当前小节写完后自检禁词与列表；长文按约 1000 字暂停
- [ ] 8. 交付前跑复核清单（见「交付前复核」）

行业用语为可选项：用户明确需要时，再生成临时词表（如 writing-glossary-temp.txt），只在上下文合适时自然带入，禁止堆砌。

素材检索与知识库

两份内容来源：

• knowledge/：内置默认知识文档（技术卡片）。按需检索：写作每个功能点/技术点前，提取技术点与指标关键词 → 在 knowledge/.index.json 中匹配 chunk（先看 preview）→ 用 start/end 行区间读取源文件命中部分，只读命中内容
• 素材库/：写作工作目录下的用户素材（仅 md/txt），不设全局素材库。把招标文件摘编、技术规范、历史标书等放入当前写作目录的 素材库/；命中相关即全文读取（用户素材通常体量小且直接相关）。项目写完素材随项目保留或清理，不跨项目混用

流程：

1. 若 knowledge/.index.json 或 素材库/.index.json 不存在，或素材有新增/变更，先运行索引脚本（无参数，自动生成两个索引）：python scripts/index_materials.py。脚本位于本 skill 的 scripts/ 目录；当前工作目录不是 skill 根目录时，用该脚本的完整路径运行（仍无参数）。脚本只索引「skill 的 knowledge/」与「当前工作目录的 素材库/」
2. 读取两份索引，确认素材清单与结构
3. 写作前按技术点/指标关键词检索 knowledge 索引；用户素材全部读取
4. 把「素材使用清单」记入 plan.md 或草稿：功能点 → 使用了哪份素材的哪一节（保留来源以便核验）
5. 规则：项目素材与内置知识冲突时以项目素材为准；索引只指向行区间，检索后必须回到源文件读原文，禁止凭索引编造内容；交付正文不出现「参考了某文档」痕迹（除非用户要求）

技术路由（knowledge/）

未命中则跳过，不强行套用。目录内文件按「技术卡片」格式组织，见 knowledge/README.md。

深度写作协议（技术点必答六问）

每个关键技术点（选型、算法、架构决策）写作前强制回答，正文据此展开：

1. 解决什么问题：对应哪个需求/指标/招标条款
2. 为什么这么选：备选方案与取舍（禁止用「业界主流」「成熟稳定」搪塞）
3. 关键机制与数据流：组件、协议、时序、核心算法
4. 工程化落地：配置、部署、监控、灰度、回滚等可执行细节
5. 如何验证：指标、测试方法、验收方式
6. 风险与降级：失败模式、边界与应对

写完后自查：若一段话去掉修饰词后没有实质技术内容（组件、机制、数据流、数字），即为泛泛而谈，重写。

场景路由

歧义：只说「技术方案」、未提投标/设计时，问一句是「投标技术标」还是「方案设计报告」，不要两套一起写。

同一对话锁定场景后不要中途更换，除非用户明确要求切换。

未说明类型时，用下面这段询问（不要先写正文）：

已加载 technical-proposal-expert。支持：技术标书、方案设计报告、测试报告、周报；其他按常规文档处理。本次要写哪类文档？

撰写前必确认

• 使用场景：给谁看、什么场合（对外投标、内部汇报、甲方验收、留档等）
• 身份：撰写者或代表方（乙方技术负责人、项目经理、测试负责人等）

据此调整语气、详略与称谓。用户没给就简短追问，不要默认成空泛「我司」。

通用文本书写要求

禁词

「可以/能够」指技术能力时改写；若表示允许性或条件成立（如「在X前提下可以…」）则保留，不机械替换。

去列表化

正文避免纯分点。优先叙述或「总—分—总」。表格、接口、参数、库表、清单可用列表或表。场景若规定「零分点」（标书），以该场景为准。

逻辑

段落用「基于上述分析」「在…前提下」「针对…场景」衔接。层级是否强制（一、 / 1.1）看场景 reference。

输出

• 每次输出完整小节或模块，不写半截；若小节自然结束时不足约 1000 字，先交付完整小节，不强行灌水
• 长文档约每 1000 个中文字符暂停，等用户确认再继续
• 写入文件时增量追加，不一次写完全文

交付前复核（每次交付前必做）

1. 待确认清零：所有「待确认/待确认条款」从交付正文收敛为一份问题清单（单独文件或 plan.md 附录），正文清零后再交付；交付时附问题清单
2. 禁词扫描：全文检查禁词表
3. 需求/条款响应核对：标书逐条核对招标需求，设计报告核对需求与指标
4. 指标一致性：指标数值与支撑设计一一对应，不允许「写了指标没写实现」或「写了实现没写指标」
5. 素材来源核验：正文关键事实能在素材使用清单中找到来源；无来源内容已标「待确认」
6. 完整性：章节骨架无缺漏（设计报告不合并删章）

找借口对照

红旗 — 停下重来

• 还没读对应 reference 就开始写
• 标书正文出现 - / * 分点（招标文件明确要求除外）
• 编造招标条款号、通过率、性能指标
• 没跑索引脚本就写技术实现，或技术点只有概念词没有机制与数据流
• 正文残留「待确认」就交付
• 长文一次倒出数千字且不暂停

最小示例

用户：「写一份政务监管平台的技术标书，模块有一张图和告警。」

1. 路由 → technical-proposal → 读 references/technical-proposal.md
2. 确认场合=对外投标、身份=乙方技术负责人（若未说则问）
3. 跑索引脚本（若索引缺失；脚本在 skill 的 scripts/ 下，无参数）→ 读两份索引；若工作目录有 素材库/ 则用户素材全文读取；涉及视频/图像技术点检索 knowledge 对应卡片
4. 默认大文本模式：建 plan.md，先收架构与需求清单，再按模块叙述撰写
5. 每个功能点按六问协议展开（机制、数据流、指标支撑），正文零分点，并响应招标条款
6. 交付前跑复核清单（待确认清零等）