goodbuddy/resources/skills/product-feature-catalog/SKILL.md

name, version, description, allowed-tools, compatibility

name	version	description	allowed-tools	compatibility
product-feature-catalog	1.0.0	基于产品事实与证据生成结构化功能列表、模块树和版本能力矩阵。用于产品规划、 售前交流、招标附件或交付范围梳理；重点回答产品有什么功能、谁使用、产生什么 结果，不负责撰写技术参数或长篇方案。	Read Grep Glob	Markdown；建议配合 product-evidence

产品功能列表

必要输入

• product-evidence.json，至少包含 product、features、limitations。
• 输出用途：内部全量、公开产品、指定版本或投标范围。
• 目标受众和所需粒度：模块、功能或子功能。

没有事实清单时不要自行拼凑：先用 product-evidence 建立并校验清单，或输出输入 缺口清单等待补齐；任何情况下都不得根据产品名称猜测功能。

生成流程

1. 按版本、公开级别和用途筛选功能。
2. 建立“产品域 → 一级模块 → 功能 → 子功能”层级，层级只服务导航，不凑数量。
3. 每条功能写清用户角色、触发动作、系统行为和可观察结果。
4. 标注 released、beta、planned、deprecated，规划能力不能混入现有功能。
5. 补充版本范围、依赖、限制和证据 ID。
6. 合并同义功能，拆开一行中包含多个独立用户动作的复合功能。

输出

复制并填写 templates/feature-catalog.md。默认输出两部分：

1. 面向读者的功能目录，只保留必要列。
2. 追溯附表，保留功能 ID、状态、证据和限制，供内部审核。

写作规则

• 功能名使用“对象 + 动作”或稳定名词，不用“强大、智能、高效、全方位”。
• 功能说明写能力边界，不写架构实现、性能参数和竞争结论。
• “支持”后必须接具体对象或动作，避免“全面支持”“灵活支持”。
• 同一功能在不同版本有差异时拆行或使用版本矩阵，不能用模糊脚注掩盖。
• 公开清单不得带出 restricted、internal 证据内容。

完成标准

• 每条功能可追溯到事实清单 ID。
• 当前能力、试用能力和规划能力明确分开。
• 模块树无重复、孤立节点和伪造层级。
• 功能粒度基本一致，名称、术语和版本范围统一。
• 限制条件没有因表格精简而丢失。