product-capability
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseProduct Capability
产品能力
This skill turns product intent into explicit engineering constraints.
Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"
该技能可将产品意图转化为明确的工程约束。
当问题不再是「我们应该构建什么?」,而是「启动实施前必须明确哪些确切的前提条件?」时使用它。
When to Use
适用场景
- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
- Senior engineers keep restating the same hidden assumptions during review
- You need a reusable artifact that can survive across harnesses and sessions
- 已有PRD、路线图事项、讨论记录或创始人笔记,但实施约束仍然不明确
- 功能涉及多个服务、代码仓库或团队,需要在编码前明确能力契约
- 产品意图清晰,但架构、数据、生命周期或政策层面的影响仍然模糊
- 高级工程师在评审过程中反复提及相同的隐含假设
- 你需要一份可跨工具、跨会话复用的标准化产出物
Canonical Artifact
标准产出物存储位置
If the repo has a durable product-context file such as , , or a program-spec directory, update it there.
PRODUCT.mddocs/product/If no capability manifest exists yet, create one using the template at:
docs/examples/product-capability-template.md
The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.
如果代码仓库有固定的产品上下文文件,例如 、 目录或项目规范目录,直接在对应位置更新即可。
PRODUCT.mddocs/product/如果还没有能力清单,可以使用以下路径的模板创建:
docs/examples/product-capability-template.md
我们的目标不是新增另一套规划体系,而是将隐含的能力约束明确固化、可复用。
Non-Negotiable Rules
不可违反的规则
- Do not invent product truth. Mark unresolved questions explicitly.
- Separate user-visible promises from implementation details.
- Call out what is fixed policy, what is architecture preference, and what is still open.
- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
- Prefer one reusable capability artifact over scattered ad hoc notes.
- 不要虚构产品事实,明确标记未解决的问题
- 将用户可见的承诺与实现细节分开
- 明确区分哪些是固定政策、哪些是架构偏好、哪些仍待确定
- 如果需求与现有仓库约束冲突,明确说明而非模糊处理
- 优先产出一份可复用的能力产出物,而非零散的临时笔记
Inputs
输入项
Read only what is needed:
- Product intent
- issue, discussion, PRD, roadmap note, founder message
- Current architecture
- relevant repo docs, contracts, schemas, routes, existing workflows
- Existing capability context
- , design docs, RFCs, migration notes, operating-model docs
PRODUCT.md
- Delivery constraints
- auth, billing, compliance, rollout, backwards compatibility, performance, review policy
仅读取必要的内容:
- 产品意图
- Issue、讨论记录、PRD、路线图笔记、创始人消息
- 当前架构
- 相关仓库文档、契约、Schema、路由、现有工作流
- 现有能力上下文
- 、设计文档、RFC、迁移笔记、运营模式文档
PRODUCT.md
- 交付约束
- 鉴权、计费、合规、灰度发布、向后兼容性、性能、评审政策
Core Workflow
核心工作流
1. Restate the capability
1. 重述能力
Compress the ask into one precise statement:
- who the user or operator is
- what new capability exists after this ships
- what outcome changes because of it
If this statement is weak, the implementation will drift.
将需求提炼为一句精准的描述:
- 目标用户或运营方是谁
- 发布后将新增什么能力
- 会带来什么业务结果变化
如果这句话不够清晰,后续实施就会出现偏差。
2. Resolve capability constraints
2. 梳理能力约束
Extract the constraints that must hold before implementation:
- business rules
- scope boundaries
- invariants
- trust boundaries
- data ownership
- lifecycle transitions
- rollout / migration requirements
- failure and recovery expectations
These are the things that often live only in senior-engineer memory.
提取实施前必须满足的约束:
- 业务规则
- 范围边界
- 不变量
- 信任边界
- 数据所有权
- 生命周期流转规则
- 灰度/迁移要求
- 故障与恢复预期
这些内容通常只存在于高级工程师的记忆中。
3. Define the implementation-facing contract
3. 定义面向实现的契约
Produce an SRS-style capability plan with:
- capability summary
- explicit non-goals
- actors and surfaces
- required states and transitions
- interfaces / inputs / outputs
- data model implications
- security / billing / policy constraints
- observability and operator requirements
- open questions blocking implementation
输出SRS风格的能力规划,包含:
- 能力概述
- 明确的非目标
- 参与角色和暴露面
- 要求的状态和流转规则
- 接口/输入/输出
- 数据模型影响
- 安全/计费/政策约束
- 可观测性和运营要求
- 阻塞实施的待解决问题
4. Translate into execution
4. 转化为执行步骤
End with the exact handoff:
- ready for direct implementation
- needs architecture review first
- needs product clarification first
If useful, point to the next ECC-native lane:
project-flow-opsworkspace-surface-auditapi-connector-builderdashboard-buildertdd-workflowverification-loop
最后给出明确的交接指引:
- 可直接进入实施阶段
- 需要先进行架构评审
- 需要先澄清产品需求
如果适用,可以指向后续的ECC原生流程:
project-flow-opsworkspace-surface-auditapi-connector-builderdashboard-buildertdd-workflowverification-loop
Output Format
输出格式
Return the result in this order:
text
CAPABILITY
- one-paragraph restatement
CONSTRAINTS
- fixed rules, invariants, and boundaries
IMPLEMENTATION CONTRACT
- actors
- surfaces
- states and transitions
- interface/data implications
NON-GOALS
- what this lane explicitly does not own
OPEN QUESTIONS
- blockers or product decisions still required
HANDOFF
- what should happen next and which ECC lane should take it按以下顺序返回结果:
text
CAPABILITY
- one-paragraph restatement
CONSTRAINTS
- fixed rules, invariants, and boundaries
IMPLEMENTATION CONTRACT
- actors
- surfaces
- states and transitions
- interface/data implications
NON-GOALS
- what this lane explicitly does not own
OPEN QUESTIONS
- blockers or product decisions still required
HANDOFF
- what should happen next and which ECC lane should take itGood Outcomes
预期收益
- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
- Engineering review has a durable artifact instead of relying on memory or Slack context.
- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.
- 产品意图足够具体,可直接实施,无需在PR提交过程中再反复挖掘隐含约束
- 工程评审有固定的产出物可参考,无需依赖记忆或Slack上下文
- 最终生成的规划可在Claude Code、Codex、Cursor、OpenCode和ECC 2.0规划平台中复用