goodbuddy/resources/skills/technical-proposal/SKILL.md

name, version, description, allowed-tools, compatibility

name	version	description	allowed-tools	compatibility
technical-proposal	1.0.0	基于客户需求、产品事实和项目约束编制完整技术方案，覆盖需求分析、总体架构、 详细设计、实施、交付、质量、安全、风险和验收。用于投标技术方案或客户解决 方案；不负责制定招标参数，也不替代逐条招标响应矩阵。	Read Grep Glob Execute	Markdown；可配合 longdoc-docx 导出 Word（PDF 仅用于核验）

技术方案

必要输入

• 客户需求原文及编号、评分点或验收目标。
• 产品事实与证据、功能状态、参数和限制。
• 部署环境、现有系统、接口、数据、安全和合规约束。
• 项目范围、责任边界、计划、交付物和非范围项。

不确定内容进入“假设与待确认事项”，不能默认为客户已具备或产品已支持。

编制顺序

1. 建立需求追溯表，为每项需求分配稳定编号。招标场景下 tender-response-matrix 是需求编号、响应状态和偏离结论的唯一权威来源， 本技能只派生视图，不得另建一套编号或改写其状态。
2. 区分业务目标、功能需求、非功能需求、接口约束和验收要求。
3. 先确定范围、假设和总体架构，再展开模块设计。
4. 对每个设计说明采用的产品能力、依赖条件和限制。
5. 将设计落实到实施任务、交付物、质量措施和验收方法。
6. 最后编制摘要，不能先写宣传性摘要再反推正文。

章节建议

复制 templates/technical-proposal.md，按项目裁剪：

• 方案摘要
• 项目理解与需求分析
• 范围、假设与责任边界
• 总体技术架构与数据流
• 详细功能和接口设计
• 部署、安全、性能和运维设计
• 实施计划、组织和质量保证
• 交付物、培训和知识转移
• 验收方法、风险和偏离说明
• 需求追溯矩阵

写作门禁

• 需求 → 设计 → 产品能力 → 交付物 → 验收方法必须可追溯。
• 规划能力必须使用将来时，并说明是否属于本项目交付范围。
• 架构图与正文必须使用相同组件名称和边界。
• 不把客户责任、第三方依赖或人工复核要求隐藏在脚注中。
• 不编造团队人数、工期、性能、案例、资质或承诺。
• 方案正文以系统和动作陈述为主，减少“我方/我们”堆叠。

导出与审校

如已安装相关技能：

1. 用 deai-writing 扫描并定向改写 Markdown。
2. 用 longdoc-docx 生成 DOCX，并借助临时 PDF 做空白页、乱码和 300 DPI 视觉复核。

未安装时仍应交付结构完整、可追溯的 Markdown。

完成标准

需求无遗漏；架构、功能、实施、交付和验收闭合；事实与产品版本一致；图表和编号 连续；假设、偏离、风险和非范围项明确；所有数字和承诺可定位到输入依据。