product-skills

product-skills skill の概要

product-skills は何のためのものか

product-skills は、曖昧で複雑なプロダクト業務を適切なプロダクト系サブスキルへ振り分け、その後も成果、ディスカバリーの根拠、測定可能な意思決定ゲートに結びつけて進めるための Product Management オーケストレーター skill です。PM、プロダクトリード、創業者、プロダクトトリオ、AI 支援を取り入れるプロダクトチームが、「何を作るべきか？」「どう優先順位を付けるべきか？」「この Opportunity Solution Tree は妥当か？」「ディスカバリーを実験計画にどう落とし込むか？」といった問いを扱う場面に向いています。

Product Management で特に向いているユースケース

product-skills skill は、プロダクト戦略、ディスカバリー、分析、優先順位付け、ロードマップ、UX リサーチ、実験、ユーザーストーリー、PRD、AI プロダクト評価、プロダクト運営モデルの意思決定など、依頼内容が複数領域にまたがるときに使います。主な価値は、見栄えのよい汎用 PM 文書を作ることではありません。作業を分類し、進むべきレーンを 1 つ選び、アウトプットよりアウトカムを重視すること、仮説検証、OST 構造、測定可能な品質ゲートといったプロダクト固有の制約を適用する点にあります。

汎用プロンプトとの違い

この skill には、決定論的なルーターである scripts/product_goal_router.py に加えて、実務向けの 2 つのゲートが含まれています。継続的ディスカバリーの健全性を確認する scripts/discovery_cadence_tracker.py と、Opportunity Solution Tree の構造を確認する scripts/ost_linter.py です。つまり product-skills は、助言するだけではありません。ディスカバリーの習慣が健全か、OST に機能案のように書かれた「機会」が混ざっていないか、対象機会に複数のソリューションとテストが紐づいているかを確認できます。

product-skills が向いていないケース

プロジェクトのデリバリー管理、スプリント調整、エンジニアリングタスクの実行だけが必要な場合、product-skills をインストールする必要はありません。このリポジトリでは、プロダクトの方向付けをプロジェクト管理や汎用エージェントループから明確に分けています。また、顧客からの根拠、分析データへのアクセス、ステークホルダーの判断を代替するものでもありません。実際の目標、指標、インタビュー、仮説、制約を提供したときに最も効果を発揮します。

product-skills skill の使い方

product-skills のインストールと最初に確認するファイル

親 GitHub skills リポジトリから次のコマンドでインストールします。

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

その後、product-team/skills/product-skills にある skill フォルダを確認します。まず SKILL.md を読み、トリガー、ルーティング、必須ルールを把握してください。次に references/product_operating_model.md、references/continuous_discovery_canon.md、references/ai_product_evals.md を確認し、プロンプトの背後にあるプロダクト上の考え方を理解します。スクリプトを使う予定がある場合は、自分のデータに合わせて調整する前に assets/sample_discovery_log.json と assets/sample_ost.json を開いておきましょう。

product-skills をうまく使うための入力

この skill は、プロンプトに 5 つの要素が含まれていると最もよく機能します。プロダクトアウトカム、現在の指標ベースライン、対象ユーザーまたはセグメント、利用できる根拠、そして必要な意思決定です。弱い入力は「機能の優先順位付けを手伝って」です。強い入力は次のようなものです。「Product Management に product-skills を使ってください。私たちは B2B SaaS のオンボーディングチームです。Outcome: week-4 retention を 22% から 30% に上げる。Evidence: セットアップの不確実性に関するサポートチケット 8 件、インタビュー 5 件、activation funnel の integration verification での離脱。Options: checklist、sample-data preview、concierge setup。適切なレーンを選び、次の意思決定に必要な成果物を作ってください。」

実際のプロダクト意思決定での推奨ワークフロー

まずは粗いプロダクト上の問いから始め、自分でフレームワークを無理に指定するのではなく、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

終了コードはワークフロー上のシグナルとして使います。たとえば OST linter が失敗した場合、そのツリーを根拠にしたロードマップは止めるべきです。ツリーの中に、孤立したソリューション、機能のように表現された機会、未検証のソリューション案が含まれている可能性があるためです。

product-skills skill FAQ

product-skills はシニア PM 向けだけですか？

いいえ。ただし初心者ほど具体的な文脈を提供する必要があります。product-skills guide は、アウトプットの約束だらけのロードマップ、実態としては出荷リストになっている OKR、アウトカムに紐づかないディスカバリーといった、よくある落とし穴を避ける助けになります。シニア PM は、ルーティング、評価、ゲートのパターンを既存の運営リズムに組み込めるため、より大きな価値を得やすいでしょう。

product-skills は RICE や OKR テンプレートとどう違いますか？

RICE や OKR は、product-skills のより広いシステムの中にあるレーンであり、システム全体ではありません。このオーケストレーターが役立つのは、次に取るべき行動が優先順位付けなのか、ディスカバリーなのか、分析なのか、実験設計なのか、ロードマップの整理なのか、PRD 作成なのか、AI 評価設計なのかが不明なときです。本当の不足が根拠の弱さや無効なアウトカムにあるにもかかわらず、あらゆるプロダクト意思決定に RICE を当てはめてしまう事態を避けられます。

product-skills は Claude Code 以外でも使えますか？

skill のメタデータでは、claude-code、codex-cli、cursor、antigravity、opencode、gemini-cli などのツールとの互換性が示されています。実務上、Markdown のガイダンスは持ち運びやすく、Python スクリプトは Python が使える環境であれば実行できます。インストール方法や呼び出し方法はホストツールによって異なる場合があるため、利用しているエージェント基盤が外部 skill をどのように読み込むか確認してください。

インストール前に何を準備すべきですか？

少なくとも 1 つの実際のプロダクト課題、指標または望ましいアウトカム、利用可能な顧客の声や分析上の根拠を準備してください。決定論的な部分を試したい場合は、assets/sample_discovery_log.json に対応する discovery log、または assets/sample_ost.json に対応する OST を用意します。実データがなくても skill は構造を生成できますが、推奨内容の信頼性は下がります。

product-skills skill を改善する方法

より明確なプロンプトで product-skills の結果を改善する

必要な成果物と、それが支えるべき意思決定を明記します。「PRD を書いて」と頼むのではなく、次のように依頼します。「これを product-skills でルーティングし、不足している作業が discovery、analytics、prioritization、spec writing のどれかを特定したうえで、次の一手を決めるために必要な成果物だけを作ってください。」こうすることで、時期尚早な文書生成を防ぎ、ルーターが適切なプロダクトレーンを選べるようになります。

推奨を求める前に根拠を追加する

最大の失敗パターンは、薄い文脈から自信満々のプロダクト戦略を求めることです。インタビューの抜粋、ファネル数値、セグメント差、サポートで繰り返し出ているテーマ、過去の実験履歴、既知の制約を追加してください。AI プロダクトの場合は、サンプル入力、悪い出力例、安全性の懸念、品質期待を含めることで、曖昧な受け入れ基準ではなく評価設計まで含む回答にできます。

最初の出力後に反復する

最初の回答は診断用のドラフトとして扱います。どの仮説に根拠がないか、どの指標が変われば推奨が変わるか、どの根拠があれば計画を無効化できるかを質問してください。出力が早すぎる段階でソリューションを提案している場合は、OST に戻します。outcome、opportunities、multiple solutions、assumption tests の順に整理し直します。変更後は linter や cadence tracker を再実行してください。

注意すべきよくある失敗パターン

機能案の形をした opportunities、単一ソリューション前提の思考、見栄えだけの vanity metrics、週次リズムのない discovery log、golden sets や rubrics のない AI 機能 PRD に注意してください。product-skills が最も力を発揮するのは、洗練された PM 文章を作るためだけに使うのではなく、その制約によって弱いプロダクト作業を止めるときです。