game-changing-features

game-changing-features 技能總覽

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」討論，
• 以及在實作 ticket 尚未出現前，先做早期需求框定。

這個技能和一般 prompt 有什麼不同

最主要的差異在於紀律。這個 skill 明確劃了兩條界線：

• No code：這是策略工作，不是解法實作。
• Write to file：輸出結果預設是要存成工作階段文件；如果你想留下可重複使用的規劃產物，而不只是聊天建議，這點特別有幫助。

它也強制一個順序：先理解現有價值，再產生可能的躍升方向，接著嚴格評估，最後做優先排序。

什麼時候不適合用這個 skill

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

• 詳細的工程規格，
• UI 文案，
• 實作任務，
• bug triage，
• 或你目前手上並沒有的真實客戶資料驗證。

它最強的是有結構的策略探索，不是替某個功能會成功提供證明。

如何使用 game-changing-features skill

game-changing-features 的安裝脈絡

這個 repository 沒有在 SKILL.md 裡提供單一通用的安裝指令，所以 game-changing-features install 會取決於你使用的 skill runner。在相容 Skills 的環境中，常見做法是先加入 softaworks/agent-toolkit repository，再以名稱呼叫 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 技術上不是必填，但少了這兩項，輸出品質通常會很快下滑。

最低可用 prompt

一個可運作的 game-changing-features usage prompt 長這樣：

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.

這樣的資訊量已足以啟動預期中的工作流程，又不會讓模型一次背負過多上下文。

怎麼把模糊想法變成強 prompt

較弱的 prompt：

What features should we add to our support product?

較強的 prompt：

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 工作流程

一場好的 game-changing-features guide session，通常會照這個順序走：

1. 先把產品範圍定窄，
2. 摘要目前提供給使用者的價值，
3. 列出反覆出現的痛點或重複被提出的需求，
4. 說清楚硬性限制，
5. 要求在不同尺度上提出 10x 機會，
6. 再要求評估與 stack ranking，
7. 最後把前 2–3 個想法轉成需求候選項。

這能避開一個很常見的失敗模式：在現有價值與摩擦點都還沒釐清前，就直接要求「game-changing」點子。

這個 skill 想產出的結果是什麼

從 repository 透露出的訊號來看，這套流程的核心是：

• 理解目前的價值，
• 在不同尺度上尋找機會，
• 依影響力與可行性評估想法，
• 找出槓桿最高的動作，
• 並將結果排序。

換句話說，你的目標不應該是「更多點子」，而應該是「更好的決策」。

實際如何處理輸出結果

SKILL.md 指示 agent 把結果寫入 .claude/docs/ai/<product-or-area>/10x/session-N.md 這個 session file。若你的環境支援可寫檔的 skill，建議保留這個做法，因為它能讓策略輸出更容易被審閱，也更方便跨 session 比較。

如果你的環境不支援這個路徑，就要求 agent 在你慣用的文件資料夾中保留同樣的結構。

如何把 game-changing-features 用在 Requirements Planning

game-changing-features for Requirements Planning 最適合作為寫 spec 之前的前置篩選器。一個有效的用法是：

• 先跑一次 skill，找出 10x 動作，
• 選出一個「Do Now」和一個「Strategic Bet」，
• 然後只替這些入選選項撰寫 requirements。

這能避免團隊把大量時間花在過度規格化那些其實槓桿不高的工作上。

常見的導入阻礙

團隊通常會在以下情況下用不好這個 skill：

• 產品範圍拉得太大，
• prompt 裡沒有任何使用者行為或痛點資訊，
• 把每個想法都當成同樣成立，
• 或團隊從「大想法」直接跳到「開始做」。

當策略問題範圍夠聚焦，且操作限制講得夠明確時，這個 skill 的結果會好很多。

game-changing-features skill 常見問答

game-changing-features 只適合新創嗎？

不是。只要團隊需要做高槓桿的優先排序，game-changing-features 就有價值。新創會特別受益於它偏創辦人視角的 framing，但內部工具、SaaS 產品，以及成熟平台，也都可以用它在特定產品範圍內找出具不對稱報酬的下注方向。

它比一般 brainstorming prompt 更好嗎？

通常是，前提是你的問題在於優先排序品質，而不是點子數量。一般 prompt 可以生出很多功能，但當你需要模型判斷哪些想法真的可能有意義地改變使用者價值時，game-changing-features skill 的價值會更高。

它會直接產出產品需求嗎？

不太會。它本質上是 strategy-first 的 skill，重點是幫你決定下一步哪些方向值得進入 requirements 工作。適合用在 PRD、spec drafting 或 implementation planning 之前。

新手可以用 game-changing-features 嗎？

可以，但新手通常要比有經驗的 PM 提供更多脈絡。如果你對產品策略還不熟，建議至少補上：

• 使用者是誰，
• 他們今天怎麼做事，
• 主要痛點是什麼，
• 以及哪些限制是真的存在。

否則輸出可能看起來很厲害，但內容仍然會偏空泛。

什麼時候不該使用 game-changing-features？

當你需要以下內容時，不要把 game-changing-features 當成主要工具：

• 客戶研究彙整，
• 精確的市場規模估算，
• 交付時程預估，
• 或工程師可直接接手的功能規格。

它是這些工作的補充，不是替代品。

這個 skill 需要存取我的 codebase 嗎？

不一定，但有會更好。這套流程明確從理解目前價值開始，而 repository 或產品層級的證據能強化這一步。如果手上沒有 codebase 或文件可看，就要用更精準的產品描述與已知使用者痛點來補足。

如何改善 game-changing-features skill 的效果

把 game-changing-features 的產品範圍收得更窄

想提升 game-changing-features 輸出品質，最快的方法就是把 session 範圍收緊。「我們的產品」太大；「首次建立 workspace 的 admin 的 onboarding activation」就好得多。範圍越窄，找出的槓桿點越銳利，灌水內容也越少。

提供證據，不要只有意見

好的輸入包括：

• 使用者最常抱怨的問題，
• 一再出現的功能需求，
• churn 原因，
• support 主題，
• 使用瓶頸，
• 以及已知的競品弱點。

這個 skill 雖然是為策略思考而設計，但只要能建立在觀察到的行為之上，可信度會高很多。

盡早且具體地說明限制條件

限制條件能改善輸出，因為它會迫使模型做取捨。建議明確寫出：

• 團隊規模，
• 交付時程，
• 平台限制，
• 合規顧慮，
• 定價模式，
• 以及整合邊界。

如果你完全不寫 constraints，agent 很可能會過度推薦一些看起來很酷、實際上卻派不上用場的 moonshot 想法。

要求輸出包含排序準則

如果想讓這個 skill 更可執行，可以要求模型依 repository 工作流程中已隱含的準則為每個想法打分，例如：

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

這會把一場創意 session 轉成產品團隊可以具體討論的決策材料。

把 quick wins 和 strategic bets 分開

很常見的失敗模式，是把「幾週內可上線」的點子和「足以改變產品類別」的想法混在一起。要改善 game-changing-features usage，可直接要求三個 bucket：

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

這樣最後的輸出會更容易轉進 roadmap 規劃。

第一版之後，強迫它做更紮實的推理

第一輪結果出來後，可以接著追問：

• 哪個想法最能改變使用者行為？
• 哪個想法最難被競爭對手複製？
• 哪個想法提升的是留存，而不只是拉新？
• 哪個選項在我們的限制下最實際？

第一輪輸出通常只是把可能性攤開；真正提升決策品質，往往是在第二輪。

把最佳想法轉成可進 requirements 的輸入

當 game-changing-features 找出勝出方案後，不要停在那裡。接著要求它補上：

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

這樣就能從策略自然銜接到 Requirements Planning，同時又不會把這個 skill 硬逼成 implementation spec writer。

留意常見失敗模式

最常見的輸出問題包括：

• 很泛的「AI-powered」建議，
• 想法和目前使用者價值脫節，
• 功能太多但排序很弱，
• 建議忽略商業限制。

如果你看到這些情況，通常修正方式就是：提供更好的輸入、縮小範圍、並更嚴格要求評估準則。

用比較型 prompt 提升 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.

比較會逼出取捨思考，而這正是這個 skill 最有用的地方。

當策略方向改變後，重新跑一次 skill

只要你的市場、定位，或產品成熟度改變，就應該重新檢視 game-changing-features。某個功能在某個階段可能是 game-changing，到了下一階段卻只剩基本配備。這個 skill 最有價值的地方，在於它能成為可重複使用的策略視角，而不是一次性的 brainstorming。