mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-14 18:44:44 +08:00
142 lines
3.8 KiB
Markdown
142 lines
3.8 KiB
Markdown
---
|
||
name: product-capability
|
||
description: 将PRD意图、路线图需求或产品讨论转化为可实施的方案计划，在开始多服务工作之前暴露约束、不变性、接口和未解决的决策。当用户需要ECC原生的PRD到SRS通道，而不是模糊的规划文本时使用。
|
||
origin: ECC
|
||
---
|
||
|
||
# 产品能力
|
||
|
||
该技能将产品意图转化为明确的工程约束。
|
||
|
||
当问题不在于"我们应该构建什么？"，而在于"在开始实现之前，必须明确哪些条件？"时使用。
|
||
|
||
## 使用时机
|
||
|
||
* 存在PRD、路线图项、讨论或创始人笔记，但实现约束仍然隐式未明
|
||
* 某个功能跨越多个服务、仓库或团队，在编码前需要一份能力契约
|
||
* 产品意图明确，但架构、数据、生命周期或策略影响仍然模糊
|
||
* 高级工程师在评审中反复重申相同的隐藏假设
|
||
* 你需要一份可跨工具链和会话复用的持久化工件
|
||
|
||
## 规范工件
|
||
|
||
如果仓库中存在持久化的产品上下文文件，例如 `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`
|
||
|
||
## 输出格式
|
||
|
||
按以下顺序返回结果：
|
||
|
||
```text
|
||
能力
|
||
- 一段重新陈述
|
||
|
||
约束条件
|
||
- 固定规则、不变项和边界
|
||
|
||
实现契约
|
||
- 参与者
|
||
- 界面
|
||
- 状态与转换
|
||
- 接口/数据影响
|
||
|
||
非目标
|
||
- 该通道明确不负责的内容
|
||
|
||
待定问题
|
||
- 仍需解决的阻碍或产品决策
|
||
|
||
交接
|
||
- 下一步应执行的操作及应由哪个ECC通道负责
|
||
```
|
||
|
||
## 良好成果
|
||
|
||
* 产品意图已足够具体，无需在PR评审中重新发现隐藏约束即可实现。
|
||
* 工程评审拥有持久化工件，而非依赖记忆或Slack上下文。
|
||
* 生成的计划可在Claude Code、Codex、Cursor、OpenCode和ECC 2.0规划界面中复用。
|