goodbuddy/resources/skills/tender-technical-spec/SKILL.md

name, version, description, allowed-tools, compatibility

name	version	description	allowed-tools	compatibility
tender-technical-spec	1.0.0	将已核验产品能力转写为可采购、可测试、可验收的招标技术规格和参数表。用于编制 招标文件技术要求、采购参数或技术规格书；不负责判断投标方是否符合，也不负责 撰写整篇投标技术方案。	Read Grep Glob	Markdown；建议配合 product-evidence

招标技术参数

必要输入

• 产品事实与证据清单，尤其是功能、参数、限制、部署和兼容性。
• 本次采购范围、部署规模、适用环境和验收阶段。
• 强制项、推荐项和可选项的标记规则。
• 是否允许品牌、专利或特定实现方式出现在参数中。

编制原则

1. 参数描述采购目标和可验证结果，避免锁定非必要的内部实现。
2. 每项只表达一个可判定要求，不能把多个条件塞入一行。
3. 数值必须包含单位、适用版本、测试条件和统计口径。
4. 使用“应、须、不得”表示强制要求，“宜、可”表示推荐或可选要求。
5. 为每项定义验收方法和所需证据，避免“支持、具备、先进”等无法判定的表述。
6. 无证据或需采购方确认的内容进入待确认表，不得补造门槛值。
7. 安全、兼容性、部署和服务要求分别成组，不能混入功能参数。

参数分类

• 总体与部署
• 功能能力
• 接口与集成
• 性能与容量
• 安全与审计
• 兼容性与信创环境
• 运维、备份与升级
• 服务、培训与交付
• 验收与材料

只保留与本次采购目标有关的分类。

输出

复制 templates/tender-technical-spec.md，生成：

1. 技术规格正文。
2. 可机读或可复制到表格的参数明细。
3. 待确认参数与风险清单。
4. 参数到事实证据的内部追溯表。

风险检查

• 是否把规划能力写成强制现有参数。
• 是否为体现“先进”而编造性能阈值。
• 是否把特定品牌或架构写成唯一实现路径，造成不必要排他性。
• 是否存在无法复现的“高、快、强、稳定”等主观指标。
• 是否遗漏测试数据、环境、并发模型、持续时间或误差范围。

完成标准

每项要求具备唯一编号、级别、参数内容、适用条件、验收方法和证据；全文无互相 冲突的阈值；待确认项没有混入正式参数；公开与保密边界符合输入约束。