product-capability

name	product-capability
description	将 PRD 意图、路线图请求或产品讨论转化为实现就绪的能力计划，在多服务工作开始之前暴露约束、不变量、接口和未解决决策。当用户需要 ECC 原生 PRD 到 SRS 通道而非模糊的规划散文时使用。

产品能力

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

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

何时使用

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

规范工件

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

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

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

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

不可协商的规则

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

输入

仅读取所需内容：

1. 产品意图
   • issue、讨论、PRD、路线图笔记、创始人消息
2. 当前架构
   • 相关仓库文档、契约、schema、路由、现有工作流
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 规划表面间重用。