game-changing-features

game-changing-features スキルの概要

game-changing-features スキルは、10x級の機会を見つけるためのプロダクト戦略ワークフローであり、単なる機能ブレスト用テンプレートではありません。想定ユーザーは、起業家、PM、そしてプロダクト志向のビルダーです。たとえば「次に何を作るべきか」「これを10倍良くするには何が必要か」「採用率・継続率・防御力を実質的に変える一手はどれか」といった問いに、より鋭く答えを出したい場面で力を発揮します。

game-changing-features が実際にやること

game-changing-features は、長い要望リストを並べる代わりに、エージェントへ次の流れを強く促します。

• まず現在のプロダクト価値を理解する
• 異なるスケールで変革的な一手を探す
• アイデアを具体的なプロダクト基準で評価する
• 断片的な提案ではなく、優先順位付きの賭け筋を出す

そのため、通常のアイデア出しプロンプトよりも、Requirements Planning に向いています。特に、限られた時間をどこに投資するかをチームで決める場面で有効です。

向いているユーザーとユースケース

game-changing-features skill は、すでに評価対象となるプロダクト、プロダクト領域、またはワークフローがある場合に最も適しています。特に有用なのは次のようなケースです。

• ロードマップの見直し
• 機能優先順位づけワークショップ
• プロダクト差別化の検討
• 「クイックウィン vs 戦略的ベット」の議論
• 実装チケットを書く前段階の要件整理

汎用プロンプトと違う点

最大の違いは、進め方に規律があることです。このスキルは、次の2つの境界を明確にしています。

• No code: これは戦略作業であり、実装そのものではない
• Write to file: 出力はセッション文書として保存する前提で、チャットだけで終わらない再利用可能な計画資産を残しやすい

さらに、順序も固定されます。現在価値の理解、可能な飛躍の発想、厳しく評価、最後に優先順位づけ、という流れです。

game-changing-features が不向きなケース

次のものが必要なら、game-changing-features は使わないほうがよいです。

• 詳細なエンジニアリング仕様
• UIコピー
• 実装タスク
• バグトリアージ
• 手元にない実顧客データにもとづく検証

このスキルが強いのは、構造化された戦略探索です。機能の成功を証明するものではありません。

game-changing-features スキルの使い方

game-changing-features のインストール前提

リポジトリ内の SKILL.md には、単一の共通インストールコマンドは記載されていません。そのため、game-changing-features install の手順は、利用している skill runner に依存します。Skills 互換の環境では、一般的には softaworks/agent-toolkit リポジトリを追加し、その後に game-changing-features スキルを名前で呼び出す形になります。

典型的なインストールパターンは以下です。

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

別の skill loader を使っている場合でも、リポジトリ名と 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 は適合性をざっと確認するのには便利ですが、実行ガイドの本体ではありません。

このスキルが期待する入力

このスキルは、最初に次の3つを渡すと最も良く機能します。

• 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

後者は、やみくもに推測させるのではなく、どこにレバレッジがあるかを見つけるのに十分なプロダクト文脈を与えています。

実務でのおすすめワークフロー

良い game-changing-features guide セッションは、通常次の順で進めます。

1. プロダクト領域を狭く定義する
2. 現在のユーザー価値を要約する
3. 繰り返し起きる痛みや要望を挙げる
4. 厳しい制約条件を明示する
5. 複数スケールの 10x 機会を求める
6. 評価とスタックランキングを求める
7. 上位 2〜3 案を要件候補に落とし込む

これでよくある失敗、つまり現在価値や摩擦が曖昧なまま「ゲームチェンジする案」を先に求めてしまう流れを避けられます。

このスキルが目指している出力

リポジトリから読み取れるシグナルでは、このワークフローの中心は次の通りです。

• 現在価値を理解する
• 異なるスケールで機会を見つける
• アイデアをインパクトと実現可能性で評価する
• 最もレバレッジの高い一手を見つける
• 結果を優先順位づけする

つまり、目標は「もっと多くのアイデアを出すこと」ではありません。目標は「より良い意思決定をすること」です。

出力の扱い方

SKILL.md では、結果を .claude/docs/ai/<product-or-area>/10x/session-N.md 配下のセッションファイルに書き出すようエージェントへ指示しています。ファイル書き込み対応の環境なら、この挙動は維持したほうがよいです。戦略アウトプットをレビューしやすく、セッション間比較もしやすくなります。

環境上そのパスを使えない場合でも、同じ構造を保ったまま、自分たちの docs フォルダへ保存するよう依頼すると運用しやすいです。

Requirements Planning での使い方

game-changing-features for Requirements Planning は、仕様を書く前段のフィルターとして使うと最も効果的です。実務では次のパターンが生産的です。

• まずスキルを実行して 10x の打ち手を洗い出す
• その中から「Do Now」を1つ、「Strategic Bet」を1つ選ぶ
• その候補に対してのみ要件を書く

これにより、レバレッジの低い作業まで過剰に仕様化してしまうのを防げます。

導入時によくあるつまずき

チームがこのスキルで詰まりやすいのは、たいてい次のような場合です。

• 対象のプロダクト領域が広すぎる
• プロンプトにユーザー行動や痛みが入っていない
• すべてのアイデアを同列に扱ってしまう
• 「大きなアイデア」から即「作ろう」に飛んでしまう

戦略上の問いが狭く、運用上の制約が明確なほど、このスキルは良い結果を返します。

game-changing-features スキル FAQ

game-changing-features はスタートアップ向けだけですか？

いいえ。game-changing-features は、チームが高レバレッジな優先順位づけを必要とするなら、どこでも有効です。創業者的な問いの立て方と相性が良いためスタートアップで恩恵を受けやすい一方、社内ツール、SaaS プロダクト、成熟したプラットフォームでも、特定領域の大きな賭け筋を見つけるために活用できます。

普通のブレインストーミング用プロンプトより優れていますか？

多くの場合ははいです。特に問題が「アイデアの量」ではなく「優先順位づけの質」にあるなら有効です。通常のプロンプトでも大量の機能案は出せますが、game-changing-features skill の価値は、どの案が本当にユーザー価値を意味のある形で変えうるかをモデルに判断させられる点にあります。

そのままプロダクト要件を生成できますか？

そこまではしません。これは戦略先行のスキルです。次に何を要件化すべきかを選ぶための支援に向いています。PRD、仕様ドラフト、実装計画の前に使うのが適切です。

初心者でも game-changing-features を使えますか？

はい。ただし初心者ほど、経験ある PM より多めに文脈を渡したほうがよいです。プロダクト戦略に不慣れなら、少なくとも次を入れてください。

• ユーザーは誰か
• その人は今何をしているか
• 主な痛みは何か
• 何が本当の制約か

これがないと、出力はもっともらしく見えても、内容は抽象的なままになりがちです。

game-changing-features を使わないほうがいいのはいつですか？

次が必要な場面で、game-changing-features を主力ツールにするべきではありません。

• 顧客調査の統合
• 正確な市場規模推定
• デリバリー見積もり
• エンジニア向けにそのまま渡せる機能仕様

これらを置き換えるものではなく、あくまで補完するものです。

このスキルはコードベースへのアクセスが必要ですか？

必須ではありませんが、あると有利です。ワークフローは「現在価値を理解する」ことから明示的に始まるため、リポジトリやプロダクトの実証材料があるほど精度が上がります。コードベースや文書がない場合は、そのぶん、プロダクト説明と既知のユーザーペインを具体的に渡して補ってください。

game-changing-features スキルを改善する方法

game-changing-features では対象のプロダクト面をもっと狭くする

game-changing-features の出力を最短で改善する方法は、セッションのスコープを強く絞ることです。「私たちのプロダクト」では広すぎます。「初めてワークスペースを管理する管理者向けのオンボーディング活性化」くらいまで絞るほうがずっと良いです。スコープが狭いほど、レバレッジのある論点が鋭くなり、埋め草の提案も減ります。

意見だけでなく、根拠も渡す

良い入力の例は次の通りです。

• 主要なユーザー不満
• 繰り返し来る機能要望
• 解約理由
• サポート問い合わせの傾向
• 利用上のボトルネック
• 競合に対する既知の弱み

このスキルは戦略思考向けに設計されていますが、観測された行動や事実に根ざしているほど、提案の信頼性は大きく上がります。

制約は早めに、具体的に書く

制約を書くと出力が良くなるのは、優先順位づけを強制できるからです。たとえば次のようなものを含めます。

• チーム規模
• 提供までの期間
• プラットフォーム上の制限
• コンプライアンス上の懸念
• 価格モデル
• 連携の境界条件

制約を書かないと、エージェントは面白いけれど使えないムーンショット案を勧めすぎることがあります。

出力に順位づけ基準を含めてもらう

このスキルをより実務的にするには、各アイデアを、リポジトリのワークフローが示唆している基準で採点するよう依頼すると効果的です。たとえば次のような基準です。

• impact
• reach
• frequency
• differentiation
• defensibility
• feasibility

こうすることで、創造的なセッションが、プロダクトチームで具体的に議論できる材料に変わります。

クイックウィンと戦略的ベットを分ける

よくある失敗は、「数週間で出せる案」と「プロダクトカテゴリ自体を変える案」が同じレイヤーで混ざることです。game-changing-features usage を改善するには、次の3つのバケットを必須にするとよいです。

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

これにより、最終出力をロードマップ計画へ変換しやすくなります。

初稿のあとに、より強い理由づけを求める

1回目の出力のあとで、次のようなフォローアップを投げてください。

• Which idea changes user behavior the most?
• Which idea is hardest for competitors to copy?
• Which idea increases retention rather than just acquisition?
• Which option is realistic inside our constraints?

最初の出力は可能性の棚出しに寄りがちで、意思決定の質が上がるのはむしろ2巡目以降です。

最上位案を要件化しやすい入力へ変換する

game-changing-features で勝ち筋が見えたら、そこで止めないでください。次を追加で求めます。

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

これで、戦略から Requirements Planning への橋渡しがきれいにできます。実装仕様書ライターとしてこのスキルに無理をさせる必要はありません。

よくある失敗パターンを監視する

最も多い出力上の問題は次の通りです。

• generic “AI-powered” suggestions
• 現在のユーザー価値と切り離されたアイデア
• ランキングが弱いまま機能数だけ多い案
• 事業制約を無視した提案

こうしたパターンが出たら、たいていの修正策は同じです。入力を良くすること、スコープを狭めること、評価基準をより厳密に要求することです。

比較プロンプトで 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.

比較を入れるとトレードオフ思考が強制され、このスキルの強みが最も出やすくなります。

戦略が変わったら game-changing-features を再実行する

市場、ポジショニング、プロダクト成熟度が変わったら、game-changing-features を見直してください。ある段階ではゲームチェンジャーだった機能が、後では単なる必須条件になることがあります。このスキルは、一度きりのブレストではなく、繰り返し使える戦略レンズとして使うと最も価値があります。