product-capability

产品能力技能概览

product-capability 是一个从规划到规格说明的技能，用来把模糊的产品意图转成可落地、可直接进入实现阶段的能力方案。它最适合你已经知道功能目标，但在开始编码前，团队仍需要厘清约束、接口、生命周期规则、数据影响以及尚未定案的决策。

最适合的场景：PRD 还不够具体时

当已经有 PRD、路线图条目、创始人备注或产品讨论串，但工程实现形态仍然只是隐含存在时，就很适合使用 product-capability 技能。对于多服务协作、跨团队依赖，或者评审总会追问“在真正开始做之前，哪些条件必须先满足”的功能，它尤其有用。

它比普通提示词多给你的价值

和泛泛的“帮我写个 spec”提示词不同，product-capability 更强调稳定、可复用的能力契约。它会帮助你把产品承诺和实现约束分开，把未解决的问题明确暴露出来，而不是靠猜；同时生成的产物也能跨会话复用，不会只埋在聊天记录里。

什么时候值得安装

如果你的团队在评审周期里经常反复挖出隐藏假设，那么安装 product-capability install 很可能是值得的。若你的工作大多是单文件、低风险，或者已经被成熟的架构文档清晰定义，那么这个技能的价值可能不如一个轻量提示词来得高。

如何使用 product-capability 技能

在工作区中安装并加载它

使用下面的命令安装该技能：

npx skills add affaan-m/everything-claude-code --skill product-capability

然后先打开 SKILL.md。如果要使用 product-capability usage，还要顺手检查仓库期望的任何持久化产品上下文文件，尤其是 PRODUCT.md、docs/product/，或者一个 program-spec 目录。如果这些都不存在，就使用技能里引用的模板路径。

把粗略需求转成高质量输入

这个技能最适合输入“产品目标 + 背景”，而不是只给一个功能名。像“加个团队共享”这样的弱需求，会留下太多空白。更强的输入应该是：“为 Web 和 API 设计一个团队共享能力方案，包含权限、审计事件、邀请生命周期，以及工作区降级时会发生什么。”

用于需求规划的 product-capability 推荐流程

先从产品陈述开始，然后让它输出能力边界、不变量、假设、未决问题和实现影响。最好的 product-capability guide 输出，通常描述的是在开始工作前必须成立什么，而不只是列功能清单。如果需求横跨多个服务或团队，记得要求它明确写出 ownership 和 contract 边界。

先读，再扩展

这个仓库刻意做得很精简，所以最值得先读的是 SKILL.md。先用它理解规则集和目标产物，再根据自己的仓库结构做适配，而不是逐字照搬示例。如果你的环境已经有统一的产品文档位置，就把输出对齐到那个路径，避免再新建一套平行的规划文件。

product-capability 技能常见问题

product-capability 只适用于 PRD 吗？

不是。product-capability 技能同样适用于路线图条目、讨论记录和创始人方向，只要真实问题是把意图翻译成一个可构建的契约。关键是你需要提供足够的产品信号，来定义约束，而不是凭空补出来。

它和普通提示词写作有什么不同？

普通提示词可能生成一段总结或草案计划。product-capability 的范围更窄：它试图保留工程相关的真实信息，把未知项显式化，并产出可复用的工件。对于漏掉一个约束就可能付出高成本的场景，它会更合适。

对新手友好吗？

可以，只要你能描述功能及其上下文，就能用。使用 product-capability 不需要架构专家级知识，但你确实需要尽量提供手头最准确的事实。如果你漏掉了关键输入，输出仍然需要人工复核。

什么时候不该用它？

不要把 product-capability 用在琐碎任务、孤立的 UI 微调，或者已经被详细规格书严格约束的工作上。如果你想要的是打磨后的营销文案或实现代码，而不是 Requirements Planning 材料，它也不是合适选择。

如何改进 product-capability 技能

先把最重要的事实给全

质量提升最大的一步，是一开始就把用户可见行为、系统边界和已知约束说清楚。把数据流、访问规则、回滚预期、依赖系统，以及任何会影响实现的政策或合规要求都写进去。

把未知项明确写出来，不要靠暗示

高质量的 product-capability 输入，会把已确认需求和待决问题分开。如果团队还没决定某个动作是不是同步、是否需要审计日志、或者由哪个服务作为事实源，就直接写明。这样可以避免技能把不确定性“抹平”。

要一个可直接决策的产物

如果第一版范围太大，就让技能收紧范围、列出不可妥协项，并标出会阻碍设计决策的权衡点。这样迭代，通常比到处要求补更多细节，更能提升 product-capability usage 的输出质量。

复用同一套能力框架

对于重复出现的产品工作，尽量在不同会话里保持相同的能力结构，这样评审者才能稳定对比各个方案。你的输入越贴近团队真实的运作方式，product-capability 技能产出的就越会是有用的指导，而不是泛泛的规划式表述。