https://github.com/yanhaoluo0/technical-proposal-expert-writing-skill
软件项目最容易缺的，往往不是代码，而是文档。
项目开工时要有可行性分析和实施方案，开发前要写需求与设计，测试阶段要准备测试计划和报告，最后还要交竣工报告、维护手册和培训材料。每份都不算难，但临时从空白文档开始，很容易漏项。
technical-proposal-expert-writing-skill 这个仓库，正是把这些软件工程文档按项目阶段整理到了一起。
不过，仓库名称和 GitHub 项目介绍有点容易让人误会。它并不是一套专门写投标技术方案的“技术标专家”，实际 Skill 名叫 software-engineering-docs，核心是一套软件项目全生命周期模板索引。
它更像一间整理好的项目文档室
仓库把资料分成计划、需求、设计、开发、测试和验收几个阶段。
计划阶段有可行性分析、项目信息表、实施方案和进度计划；需求阶段提供需求规格说明书；设计阶段有功能设计和数据库设计；测试阶段包括测试用例、测试计划和测试报告；验收阶段则准备了竣工报告、安装维护手册、培训文档和使用手册。
除了空白模板，多数目录还放了示例文件。格式不只 Word，也有 Excel 和 PowerPoint。周报、月报、工时统计和会议纪要等日常材料也一起收进来了。
对于平时不常写工程文档的人，这种“按阶段找模板”比给 AI 一句“帮我写项目文档”更可靠。至少先知道这个阶段应该交什么，以及一份合格文档大致长什么样。
Skill 做的是导航和写作约束
SKILL.md 没有复杂脚本，也不会自动分析代码仓库。它告诉 Agent 在不同阶段应该使用哪类模板、文档要覆盖哪些内容，并强调完整性、格式统一、术语一致和版本可追溯。
例如需求规格说明书要写功能、性能、接口、数据和安全要求；测试计划要交代测试内容、进度、条件、人员和通过标准；安装维护手册则要说明系统模块、运行环境和维护过程。
配套的写作规范还规定了封面信息、标题编号、图表编号以及“编写、审核、批准”的流程。它的价值不是让 AI 突然变成项目经理，而是给 AI 一份文档清单，减少凭空发挥。
真正好用的是仓库，单独安装 Skill 反而不完整
项目提供了一个 software-engineering-docs.skill 文件，看上去可以直接导入支持 Skill 的客户端。
我检查了这个压缩包，里面只有一份 SKILL.md。仓库里的 Word、Excel、PPT 模板和示例并没有一起打包。
而 Skill 的说明又要求 Agent 按相对路径查找这些模板。因此，只安装这个 .skill 文件，Agent 能得到写作指导，却拿不到真正的模板。想完整使用，最好克隆整个仓库，或者把“文档示例”和写作规范一起放进 Agent 可以访问的工作目录。
这也说明它目前更像“模板仓库附带一个 Skill”，而不是安装完成就能自动生成所有交付物的产品。
它并没有实现项目介绍里的全部能力
GitHub 项目描述把它称为政府和企业软件项目的技术标书写作 Skill，并提到 GB/T 8567-2006。
但当前 README、SKILL.md 和写作规范中，没有看到针对招标评分标准、废标项、商务资质或技术偏离表的专门流程，也没有检索到 GB/T 8567-2006 的具体条款映射。
因此，把它当作软件工程文档助手比较准确；如果拿去写正式投标文件，还需要另补招标文件解析、评分点响应、企业资质和合规检查。
模板不是标准答案
这些示例文件能解决“从哪里开始”，却不能证明模板适合所有项目。
政府项目、企业内部项目、等保相关系统和行业专用软件，对文档名称、审批流程与技术内容的要求都可能不同。历史模板里的格式和术语也未必符合甲方当前要求。
更稳妥的做法，是先以合同、招标文件和本单位制度为准，再让 AI 参考模板补齐结构。涉及项目进度、性能指标、人员职责和验收结果的内容，必须来自真实记录，不能让模型自动编。
适合谁使用
如果团队缺少统一的项目文档体系，这个仓库很适合拿来做起点。
它尤其适合中小软件团队、项目经理和实施人员：先复制对应阶段的模板，再把真实项目信息交给 Agent 填充，最后由负责人审核。
它的优势不在“会写一篇漂亮长文”，而在于把散落的文档按生命周期摆回正确位置。代码之外的项目交付，终于不必每次都从搜索旧文件开始。
仓库使用 MIT 许可证。需要注意的是，具体 Word、Excel 和 PPT 模板中可能包含示例内容，正式使用前仍要清理占位信息、旧项目名称和无关数据。
