产品能力

产品能力 是做什么的？

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

当问题不在于“我们应该构建什么？”而在于“在开始实现之前，哪些条件必须明确成立？”时使用。

使用场景

• 存在PRD、路线图事项、讨论或创始人笔记，但实现约束仍隐晦不明
• 某个特性跨越多个服务、仓库或团队，需要在编码前定义能力契约
• 产品意图清晰，但架构、数据、生命周期或策略影响仍模糊
• 高级工程师在评审中反复重申相同的隐藏假设
• 你需要一个可跨工具链和会话复用的持久化工件

规范工件

如果仓库中存在持久的产品上下文文件（如PRODUCT.md、docs/product/或程序规范目录），请在其中更新。

如果尚未存在能力清单，请使用以下位置的模板创建一个：

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

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

不可协商的规则

• 不要编造产品事实。明确标记未解决的疑问。
• 将用户可见的承诺与实现细节区分开。
• 明确指出哪些是固定策略、哪些是架构偏好、哪些仍待解决。
• 如果请求与现有仓库约束冲突，请明确说明，而不是粉饰太平。
• 优先选择单个可复用的能力工件，而非零散的临时笔记。

输入

只读取所需内容：

1. 产品意图
   • 事项、讨论、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

输出格式

按以下顺序返回结果：

CAPABILITY
- 一段重述

CONSTRAINTS
- 固定规则、不变性和边界

IMPLEMENTATION CONTRACT
- 行为体
- 界面
- 状态和转换
- 接口/数据影响

NON-GOALS
- 此工作流明确不负责的内容

OPEN QUESTIONS
- 阻碍实施或仍需产品决策的问题

HANDOFF
- 下一步应执行的操作以及应由哪个ECC工作流接管

良好结果

• 产品意图现在足够具体，无需在PR中间重新发现隐藏约束即可实现。
• 工程评审拥有持久的工件，而非依赖记忆或Slack上下文。
• 生成的计划可在Claude Code、Codex、Cursor、OpenCode和ECC 2.0规划界面间复用。