product-capability

产品能力

此技能将产品意图转化为显式的工程约束。

当差距不是"我们应该构建什么？"而是"实现开始之前必须确切成立什么？"时使用它。

何时使用

• 存在 PRD、路线图项、讨论或创始人笔记，但实现约束仍然是隐式的
• 一个特性跨越多个服务、仓库或团队，在编码前需要能力契约
• 产品意图清晰，但架构、数据、生命周期或策略影响仍然模糊
• 高级工程师在审查期间不断重述相同的隐藏假设
• 你需要一个可以在 harness 和会话间生存的可重用产物

规范产物

如果仓库有持久的产品上下文文件，如 PRODUCT.md、docs/product/ 或程序规范目录，在那里更新它。

如果尚不存在能力清单，使用以下模板创建一个：

• docs/examples/product-capability-template.md

目标不是创建另一个规划栈。目标是使隐藏的能力约束持久且可重用。

不可协商的规则

• 不要编造产品真相。显式标记未解决的问题。
• 将用户可见的承诺与实现细节分开。
• 指出什么是固定策略、什么是架构偏好、什么仍然开放。
• 如果请求与现有仓库约束冲突，明确说明，而不是搪塞过去。
• 优先使用一个可重用的能力产物，而非分散的临时笔记。

输入

只读取需要的内容：

1. 产品意图
   • issue、讨论、PRD、路线图笔记、创始人消息
2. 当前架构
   • 相关的仓库文档、契约、模式、路由、现有工作流
3. 现有能力上下文
   • PRODUCT.md、设计文档、RFC、迁移笔记、运营模型文档
4. 交付约束
   • 认证、计费、合规、发布、向后兼容性、性能、审查策略

核心工作流

1. 重述能力

将需求压缩为一个精确的陈述：

• 用户或操作者是谁
• 发布后存在什么新能力
• 什么结果因此改变

如果这个陈述薄弱，实现就会漂移。

2. 解析能力约束

提取实现前必须成立的约束：

• 业务规则
• 范围边界
• 不变量
• 信任边界
• 数据所有权
• 生命周期转换
• 发布 / 迁移需求
• 失败和恢复预期

这些是通常只存在于高级工程师记忆中的东西。

3. 定义面向实现的契约

生成一个 SRS 风格的能力计划，包含：

• 能力摘要
• 显式非目标
• 参与者和接触面
• 必需的状态和转换
• 接口 / 输入 / 输出
• 数据模型影响
• 安全 / 计费 / 策略约束
• 可观测性和操作者需求
• 阻塞实现的开放问题

4. 转化为执行

以确切的交接结束：

• 可直接实现
• 需要先进行架构审查
• 需要先进行产品澄清

如果有用，指向下一个 ECC 原生通道：

• project-flow-ops
• workspace-surface-audit
• api-connector-builder
• dashboard-builder
• tdd-workflow
• verification-loop

输出格式

按以下顺序返回结果：

能力
- 一段话的重述

约束
- 固定规则、不变量和边界

实现契约
- 参与者
- 接触面
- 状态和转换
- 接口/数据影响

非目标
- 此通道明确不拥有的内容

开放问题
- 仍需要的阻塞因素或产品决策

交接
- 接下来应该发生什么以及哪个 ECC 通道应该处理

好的结果

• 产品意图现在足够具体，可以在 PR 中途不重新发现隐藏约束的情况下实现。
• 工程审查有一个持久的产物，而不是依赖记忆或 Slack 上下文。
• 结果计划可在 Claude Code、Codex、Cursor、OpenCode 和 ECC 2.0 规划表面上重用。