product-skills

product-skills skill 概览

product-skills 适合解决什么问题

product-skills 是一个面向 Product Management 的编排型 skill，用来把混乱的产品工作路由到合适的产品子 skill，并持续把工作锚定在业务结果、探索证据和可衡量的决策关口上。它最适合 PM、产品负责人、创业者、产品三人组，以及使用 AI 辅助产品工作的团队，用来处理诸如“我们应该做什么？”“应该如何排序优先级？”“这个 Opportunity Solution Tree 是否站得住脚？”或“如何把用户探索转化为实验计划？”这类问题。

最适合 product-skills 的产品管理场景

当你的请求涉及产品战略、用户探索、数据分析、优先级排序、路线图、UX research、实验、用户故事、PRD、AI product evals，或产品运营模型决策时，适合使用 product-skills skill。它的主要价值不是把一份通用 PM 文档写得更好看，而是帮助你判断工作类型、选择正确路径，并应用产品工作中的关键约束，例如重结果而不是重产出、假设验证、OST 结构，以及可衡量的质量门槛。

它和通用 prompt 有什么不同

这个 skill 包含一个确定性的路由器 scripts/product_goal_router.py，以及两个实用关口：用于检查持续探索健康度的 scripts/discovery_cadence_tracker.py，和用于检查 Opportunity Solution Tree 结构的 scripts/ost_linter.py。这意味着 product-skills 不只是给建议：它还能检查探索节奏是否健康、OST 中是否存在被写成“功能”的 opportunity，以及被重点关注的 opportunity 是否拥有多个 solution 和 test。

什么时候不适合使用 product-skills

如果你只需要项目交付跟踪、sprint 协调或工程任务执行，就不应该安装 product-skills。这个仓库明确把产品方向判断与项目管理、通用 agent loop 区分开来。它也不能替代真实客户证据、数据分析权限或干系人判断；当你提供真实目标、指标、访谈、假设和约束时，它的效果最好。

如何使用 product-skills skill

product-skills 安装与首次应查看的文件

从父级 GitHub skills 仓库安装：

npx skills add alirezarezvani/claude-skills --skill product-skills

然后查看 skill 文件夹 product-team/skills/product-skills。先阅读 SKILL.md，了解触发条件、路由逻辑和硬性规则。接着查看 references/product_operating_model.md、references/continuous_discovery_canon.md 和 references/ai_product_evals.md，理解 prompt 背后的产品逻辑。如果计划使用脚本，先打开 assets/sample_discovery_log.json 和 assets/sample_ost.json，再改造成你自己的数据。

哪些输入能让 product-skills 更好用

当你的 prompt 包含五类信息时，这个 skill 表现最好：产品 outcome、当前指标基线、目标用户或细分人群、已有证据，以及你需要做出的决策。较弱的输入是：“帮我给功能排优先级。”更强的输入是：“Use product-skills for Product Management. We are a B2B SaaS onboarding team. Outcome: raise week-4 retention from 22% to 30%. Evidence: 8 support tickets about setup uncertainty, 5 interviews, activation funnel drop at integration verification. Options: checklist, sample-data preview, concierge setup. Help choose the right lane and produce the next decision artifact.”

面向真实产品决策的建议工作流

先从一个粗略的产品问题开始，请 agent 使用 product-skills 进行路由，而不是你自己强行套用某个框架。如果问题还不清楚，先要求它提出澄清问题，再输出结果。对于探索占比较高的工作，可以创建或改造一个 OST JSON，并运行 ost_linter.py 做结构检查。对于持续探索，维护一份 discovery log，并每周运行 discovery_cadence_tracker.py。对于 AI 功能，在把 PRD 视为完成之前，应使用 references/ai_product_evals.md 要求包含 golden set、rubric 和 guardrail metrics。

实用的命令行检查

这些 Python 脚本采用标准库模式，设计目标是提供确定性的工作流关口。典型用法是先保存你的 JSON 输入，然后运行：

python scripts/ost_linter.py path/to/ost.json

python scripts/discovery_cadence_tracker.py path/to/discovery_log.json

把 exit codes 当作工作流信号来使用。例如，如果 OST linter 失败，那么引用这棵树的 roadmap 就应该被阻断，因为这棵树可能包含孤立的 solution、被写成功能的 opportunity，或尚未测试的 solution idea。

product-skills skill 常见问题

product-skills 只适合资深 PM 吗？

不是，但初学者需要提供具体上下文。product-skills 指南可以帮助新手 PM 避免常见陷阱，例如充满产出承诺的 roadmap、实际上只是发版清单的 OKR，以及没有绑定 outcome 的 discovery。资深 PM 通常能从路由、eval 和 gating 模式中获得更多价值，因为他们可以把这些模式接入已有的运营节奏。

product-skills 和 RICE 或 OKR 模板有什么不同？

RICE 和 OKR 是 product-skills 更大系统中的具体路径，而不是整个系统本身。当你不确定下一步应该做优先级排序、用户探索、数据分析、实验设计、roadmap framing、PRD 工作，还是 AI evaluation design 时，这个 orchestrator 会很有用。它能帮助你避免把 RICE 套到每一个产品决策上，因为真正的缺口可能是证据薄弱，或 outcome 本身无效。

product-skills 可以在 Claude Code 之外使用吗？

skill metadata 列出了与 claude-code、codex-cli、cursor、antigravity、opencode 和 gemini-cli 等工具的兼容性。实际使用中，markdown 指南是可迁移的，Python 脚本也可以在任何可运行 Python 的地方执行。安装和调用细节会因宿主工具而异，因此需要确认你的 agent 平台如何加载外部 skills。

安装前应该准备什么？

至少准备一个真实的产品问题、一个指标或期望 outcome，以及任何可用的客户证据或数据分析证据。如果想测试确定性部分，准备一份匹配 assets/sample_discovery_log.json 的 discovery log，或一份匹配 assets/sample_ost.json 的 OST。没有真实输入时，这个 skill 仍然可以生成结构，但它给出的建议可信度会更低。

如何改进 product-skills skill 的使用效果

用更清晰的 prompt 提升 product-skills 输出质量

明确你想要的 artifact，以及它需要支持的决策。不要只问“写一份 PRD”，而是问：“Route this with product-skills, identify whether the missing work is discovery, analytics, prioritization, or spec writing, then produce only the artifact needed to decide the next step.” 这样可以避免过早生成文档，并让路由器选择正确的产品工作路径。

先补充证据，再要求给建议

最大的失败模式，是在上下文很薄的情况下要求它给出很有把握的产品战略。应补充访谈摘录、漏斗数据、细分人群差异、支持工单主题、实验历史和已知约束。对于 AI 产品工作，还应提供 sample inputs、bad outputs、安全顾虑和质量预期，这样回答才能包含 eval design，而不是停留在模糊的验收标准上。

在第一版输出后继续迭代

把第一版回答视为诊断草稿。追问哪些假设没有证据支持、哪个指标会改变推荐方向、什么证据会推翻当前计划。如果输出过早提出 solution，把它重新放回 OST：outcome、opportunities、multiple solutions 和 assumption tests。修改后重新运行 linter 或 cadence tracker。

需要警惕的常见失败模式

注意那些被写成功能的 opportunity、只考虑单一 solution 的思维、vanity metrics、没有周节奏的 discovery log，以及缺少 golden sets 或 rubrics 的 AI feature PRD。product-skills 最强的地方，是让它的约束阻断薄弱的产品工作，而不是只把它当成生成精美 PM 文案的工具。