game-changing-features

game-changing-features skill 概览

game-changing-features skill 是一套用于寻找 10x 机会的产品策略工作流，不是普通的功能脑暴模板。它面向创始人、PM 和有产品思维的建设者，适合那些需要更明确回答这类问题的人：“我们下一步该做什么？”、“什么改动能让它好 10 倍？”、“哪一步可能真正改变采用率、留存或防御性？”

game-changing-features 实际在做什么

game-changing-features 不会先产出一长串愿望清单，而是推动 agent 去：

• 先理解产品当前的价值，
• 在不同尺度上寻找具有颠覆性的动作，
• 按具体的产品判断标准评估这些想法，
• 最终输出一组排好优先级的赌注，而不是零散建议。

因此，相比普通的创意提示词，它在 Requirements Planning 中更有价值，尤其适合团队需要决定有限时间该投在哪里的时候。

最适合的用户与使用场景

当你已经有一个产品、某个产品模块，或一段明确的工作流需要评估时，game-changing-features skill 最合适。它尤其适用于：

• roadmap 重置，
• 功能优先级工作坊，
• 产品差异化分析，
• “quick wins vs strategic bets”的讨论，
• 以及在 implementation ticket 还没出现之前做早期需求框定。

这个 skill 与通用提示词的区别

它最核心的差异在于“纪律性”。这个 skill 明确设了两个边界：

• No code：这是策略工作，不是方案实现。
• Write to file：输出默认应该保存为会话文档；如果你想得到可复用的规划材料，而不是只停留在聊天记录里，这一点会非常有帮助。

它还强制了一条顺序：先理解当前价值，再提出可能的跃迁点，接着严格评估，最后做优先级排序。

什么情况下不适合用这个 skill

如果你需要的是以下内容，就不应该用 game-changing-features：

• 详细的工程规格，
• UI 文案，
• implementation tasks，
• bug triage，
• 或者你手头并没有、却又必须依赖的真实客户数据验证。

它最擅长的是结构化的战略探索，而不是证明某个功能一定会成功。

如何使用 game-changing-features skill

game-changing-features 的安装上下文

这个仓库没有在 SKILL.md 里提供统一的安装命令，所以 game-changing-features install 取决于你使用的 skill runner。在兼容 Skills 的环境里，常见模式是先添加 softaworks/agent-toolkit 仓库，再通过名字调用 game-changing-features skill。

一个典型的安装方式如下：

npx skills add softaworks/agent-toolkit --skill game-changing-features

如果你的环境使用的是别的 skill loader，也请保持相同的 repo 和 skill slug：

• repo: softaworks/agent-toolkit
• skill: game-changing-features

首次使用前建议先读哪些文件

如果你想快速上手，建议按这个顺序阅读：

1. skills/game-changing-features/SKILL.md
2. skills/game-changing-features/README.md

SKILL.md 才是实际的运行规则与工作流说明。README.md 更适合快速判断是否适配，但它不是主要的执行指南。

这个 skill 期望你提供哪些输入

想让这个 skill 发挥最好效果，建议一开始就给出三类输入：

• Product or area：你希望分析的对象
• Current state：当前已经存在什么
• Constraints：团队、时间、技术、市场或业务限制

其中 current state 和 constraints 虽然技术上是可选的，但如果缺失，输出质量通常会很快下滑。

最小可用提示词

一个可工作的 game-changing-features usage 提示词大致长这样：

Use game-changing-features for Requirements Planning.

Product/Area: Team inbox triage for support managers
Current state: Shared inbox, tags, macros, basic SLA reporting, high manual sorting
Constraints: 2 engineers, 1 designer, 8-week window, no model fine-tuning, must work inside existing Zendesk workflow
Goal: Identify the highest-leverage feature moves, then rank them into now/next/later.

这些信息已经足够触发它预期的工作流，同时又不会给模型塞入过多噪音。

如何把一个模糊想法变成高质量提示词

弱提示词：

What features should we add to our support product?

更强的提示词：

Use game-changing-features on our support platform.

Product/Area: Agent workflow and queue management
Who uses it: Support managers and frontline agents at B2B SaaS companies
Current value: Helps teams process tickets, collaborate, and track SLAs
Core user action: Sort, assign, and resolve inbound issues
Pain points: Repetitive triage, poor prioritization, hard handoffs, weak visibility into urgent revenue-risk tickets
Constraints: We need something shippable in one quarter, must fit our existing UI, and should differentiate us from help desk competitors
Output needed: 10x opportunities, scoring rationale, and ranked recommendations for Requirements Planning

更强的版本为这个 skill 提供了足够的产品上下文，让它去寻找真正的杠杆点，而不是靠猜。

实战中推荐的工作流

一个好的 game-changing-features guide 会话通常按这个顺序推进：

1. 先把产品范围定义得更窄，
2. 概括当前给用户带来的价值，
3. 列出反复出现的痛点或重复请求，
4. 明确写出硬约束，
5. 要求它在多个尺度上寻找 10x 机会，
6. 再要求评估与 stack ranking，
7. 最后把前 2–3 个想法转成 requirements candidates。

这样可以避开一个常见失败模式：在当前价值和使用摩擦都还没讲清楚之前，就直接让它产出“game-changing”的想法。

这个 skill 的目标产出是什么

从仓库给出的信号看，这个工作流的重点是：

• 理解当前价值，
• 在不同尺度上寻找机会，
• 按影响力和可行性评估想法，
• 找出杠杆最高的动作，
• 并完成优先级排序。

这意味着你的目标不应该是“要更多想法”，而应该是“做出更好的决策”。

实际输出该如何处理

SKILL.md 要求 agent 把结果写入 .claude/docs/ai/<product-or-area>/10x/session-N.md 这样的 session file。如果你的环境支持 file-writing skills，建议保留这个行为，因为这样策略输出更便于回看，也更容易做跨 session 对比。

如果你的环境不支持这一路径，也可以要求 agent 在你常用的 docs 目录里保留相同的结构。

如何把它用于 Requirements Planning

game-changing-features for Requirements Planning 最适合作为写规格之前的一层前置筛选。一个高效的模式是：

• 先运行这个 skill，找出 10x 级别的动作，
• 选一个 “Do Now” 和一个 “Strategic Bet”，
• 然后只为这些 shortlist 选项编写 requirements。

这样能避免团队把太多精力花在低杠杆工作上，过早写出过度细化的规格。

常见采用阻碍

团队在使用这个 skill 时，通常会卡在这些地方：

• 产品范围给得太大，
• 提示词里没有用户行为或痛点，
• 把每个想法都当成同样成立，
• 或者从“big idea”直接跳到“build it”。

当战略问题更聚焦、操作约束写得更明确时，这个 skill 的结果会明显更好。

game-changing-features skill 常见问题

game-changing-features 只适合创业公司吗？

不是。只要团队需要做高杠杆优先级判断，game-changing-features 就有用。创业公司会特别受益于它偏 founder 风格的思考框架，但内部工具、SaaS 产品和成熟平台，同样可以用它来挖掘某个具体产品区域里的超额机会。

它真的比普通 brainstorming 提示词更好吗？

通常是的，前提是你的问题在于“优先级质量”，而不是“想法数量”。普通提示词可以生成很多功能点子；而 game-changing-features skill 的价值在于，它会进一步判断哪些想法才有可能真正改变用户价值，而不是只是看起来新鲜。

它会直接产出产品需求吗？

不完全会。它本质上是一个 strategy-first 的 skill。它帮助你判断“下一步什么值得进入 requirements 阶段”，而不是直接替你完成 PRD、spec drafting 或 implementation planning。

新手能用 game-changing-features 吗？

可以，但新手需要提供比资深 PM 更多的上下文。如果你对产品策略还不熟，建议补充这些信息：

• 用户是谁，
• 他们今天是怎么做事的，
• 主要痛点是什么，
• 哪些约束是真实存在的。

否则输出可能看起来很有气势，但内容仍然会停留在泛泛而谈的层面。

什么情况下不该使用 game-changing-features？

当你需要以下内容时，不要把 game-changing-features 当成主工具：

• customer research synthesis，
• 精确的市场规模测算，
• 交付工期预估，
• 或者工程师可直接开工的 feature specs。

它能补充这些工作，但不能替代它们。

这个 skill 一定需要访问我的代码库吗？

不是硬性要求，但有会更好。因为它的工作流明确要求先理解当前价值，而仓库信息或产品证据能帮助它把这一步做扎实。如果没有 codebase 或文档可用，那就需要用更精确的产品描述和已知用户痛点来补足。

如何改进 game-changing-features skill 的使用效果

把产品分析范围收得更窄

想提升 game-changing-features 输出质量，最快的方法就是缩小分析范围。“Our product” 太大了；“首次使用的 workspace admin 的 onboarding activation” 就好得多。范围越窄，找到的杠杆点越尖锐，废话也越少。

提供证据，而不只是观点

高质量输入通常包括：

• 用户最高频的抱怨，
• 被反复提到的 feature requests，
• churn 原因，
• support 主题归类，
• usage bottlenecks，
• 以及已知的竞品短板。

这个 skill 的设计目标是战略思考，但如果能建立在真实观察到的行为上，它的结论会可信得多。

尽早、具体地写出约束条件

约束之所以能提升输出质量，是因为它会强迫模型做取舍。建议直接写出：

• 团队规模，
• 交付窗口，
• 平台限制，
• 合规顾虑，
• 定价模式，
• 以及集成边界。

如果不写约束，agent 很容易推荐一些听起来很激动人心、但实际并不适用的 moonshot。

要求输出里包含排序标准

如果你想让这个 skill 更可执行，可以明确要求模型按仓库工作流里已经隐含的标准给每个想法打分，比如：

• impact，
• reach，
• frequency，
• differentiation，
• defensibility，
• feasibility。

这样一来，原本偏创意的会话就会变成产品团队可以具体讨论的判断材料。

把 quick wins 和 strategic bets 分开

一个常见失败模式，是把“几周内能上线的想法”和“会改变产品类别的想法”混在一起。想改进 game-changing-features usage，可以强制它按三个桶输出：

• quick wins，
• medium-term bets，
• compounding strategic moves。

这样最终结果会更容易转进 roadmap planning。

第一轮之后，强制它做更严格的推理

第一轮输出完成后，继续追问这类问题：

• 哪个想法最能改变用户行为？
• 哪个想法最难被竞争对手复制？
• 哪个想法提升的是留存，而不只是获客？
• 哪个选项在我们的约束内最现实？

第一轮往往只能把可能性摊开；真正提升决策质量，通常发生在第二轮。

把最优想法转成可进入 requirements 的输入

当 game-changing-features 已经找出一个明显赢家后，不要停在那。继续让它给出：

• target user，
• triggering problem，
• desired behavior change，
• success metrics，
• risks，
• dependencies。

这样就能在不把这个 skill 变成 implementation spec writer 的前提下，顺畅地从策略衔接到 Requirements Planning。

留意常见失败模式

最常见的输出问题包括：

• 泛泛的 “AI-powered” 建议，
• 想法与当前用户价值脱节，
• 功能太多但排序很弱，
• 建议忽视业务约束。

如果你看到这些模式，通常说明问题不在 skill 本身，而在于输入不够好、范围太大，或评估标准要求得还不够严格。

用对比型提示词提升 game-changing-features

一种高价值用法，是不要只让它给想法，而是让它做对比。例如：

Use game-changing-features and compare:
1. the best 10x move for retention,
2. the best 10x move for expansion revenue,
3. the best 10x move for user delight.
Then recommend only one to prioritize this quarter and explain why.

对比会强迫它进入 tradeoff thinking，而这正是这个 skill 最有价值的部分。

当策略发生变化时，重新运行这个 skill

当你的市场、定位或产品成熟度发生变化时，都应该重新使用 game-changing-features。一个在某个阶段足以改变局面的功能，到了后期可能只剩下 table stakes。这个 skill 最有价值的地方，不是一次性脑暴，而是作为一种可重复使用的战略视角。