product-skills

プロダクトチーム — ドメインオーケストレーターとディスカバリーループ

このオーケストレーターは2つの役割を担います。ルーティング： コンテキストを分岐し、scripts/product_goal_router.py を使って、16のプロダクトチームのレーン（バンドル済みの12個＋スタンドアロンプラグイン4個）すべてからプロダクトに関する問い合わせを分類し、該当するものを1つだけ実行して、要約を返します。ループ： 機械的に検証できるゲートを備えた、範囲を限定したエージェント型ループとしてプロダクト業務を進めます。具体的には、継続的なディスカバリーループ（discovery_cadence_tracker.py で週次の頻度を評価し、ost_linter.py でツリー構造を検証）と、リポジトリ全体のエージェントハーネスを使った目標規模の実行です。

呼び出すタイミング

症状	サブスキル
「機能の優先順位付け／RICE／PRD」	product-manager-toolkit
「OKR、戦略カスケード」	product-strategist
「ペルソナ、ユーザビリティ、調査の統合」	ux-researcher-designer
「デザイントークン、WCAG コントラスト」	ui-design-system
「競合マトリクス、ティアダウン」	competitive-teardown
「リテンション、コホート、ファネル、KPI」	product-analytics
「A/B テスト、サンプルサイズ、仮説」	experiment-designer
「ディスカバリー、前提条件、オポチュニティツリー」	product-discovery
「ロードマップの告知、リリースノート、変更履歴」	roadmap-communicator
「仕様 → 実行可能なリポジトリ」	spec-to-repo
「ランディングページ（Next.js/Tailwind）」	landing-page-generator
「SaaS のボイラープレート」	saas-scaffolder
「ユーザーストーリー、スプリントのキャパシティ」	agile-product-owner（スタンドアロン）
「Apple HIG 監査」	apple-hig-expert（スタンドアロン）
「既存のコードベースから PRD を作成」	code-to-prd（スタンドアロン）
「論文／記事の要約」	research-summarizer（スタンドアロン）

ルーティングのロジック（決定論的）

python3 scripts/product_goal_router.py --text "<the goal>" --output json

終了コード 0 → route_to にスキル名（スタンドアロンプラグインを含む skill_path 付き）が指定されます。そのスキルの SKILL.md を読み込み、ワークフローに従ってください。終了コード 2 → 列挙された候補名を示し、推奨する回答を添えて、確認の質問を1つだけしてください。終了コード 3 → シグナルなし：成果物を明示して目標を言い直すよう、ユーザーに依頼してください。黙って推測してはいけません。黙って連鎖させてはいけません。まず要約し、確認してから連鎖させてください。

ディスカバリーループ（このドメインで繰り返し行うエージェント型ループ）

現代のディスカバリーは、プロジェクトのフェーズではなく週次の習慣です（Torres）。2つの機械的なゲートを設け、範囲を限定したループとして実行します。

1. 観察 — discovery_log.json（インタビュー、前提条件のテスト。形式は assets/sample_discovery_log.json を参照）を維持し、頻度を評価します。

   python3 scripts/discovery_cadence_tracker.py --input discovery_log.json
   

   インタビューが2件未満の場合は拒否されます（終了コード 5）。まだ評価できる頻度がありません。出力：健全度 0～100、判定 HEALTHY/AT-RISK/DORMANT、具体的な不足項目、next_loop_action。
2. 選択 — トラッカーの next_loop_action がそのまま選択内容になります。タッチポイントを予約する、成果に基づいてガイドを再設定する、または未検証の前提条件のうち最も重要なものをテストします（優先順位付けのため、product-discovery の assumption_mapper にルーティングします）。
3. 実行 — ルーティング先のサブスキルのツールを使って、インタビュー／前提条件のテストを実施します。
4. 検証 — ロードマップの作成に使う前に、ツリーの構造が健全であることを確認します。

   python3 scripts/ost_linter.py --input ost.json    # exit 2 = NEEDS-REWORK, fix before citing the tree
   

   ルール：測定可能な成果を1つだけルートに置く（O1）、オポチュニティは機能ではなくニーズにする（O2）、対象となるオポチュニティでは2つ以上の解決策を比較する（O3）、すべての解決策に前提条件のテストを設ける（O4）、孤立した解決策を作らない（O5 — 機能ファクトリーの兆候）。
5. 記録／継続または停止 — ログを更新し、週次の連続記録を維持します。停止状態：HEALTHY かつ前提条件が検証済み → experiment-designer に進み（A/B ゲートを構築）、または product-manager-toolkit に進みます（PRD）。DORMANT が4週以上続く → プロダクトリードを名指ししてエスカレーションします。ディスカバリーをひそかに終わらせてはいけません。

ビルド規模の目標（「検証済みの仕様をリポジトリにして検証する」）では、代わりにリポジトリ全体のハーネスを通して処理します。

python3 engineering/agent-harness/skills/agent-harness/scripts/goal_compiler.py \
  --goal "<goal>" --manifest engineering/agent-harness/skills/agent-harness/assets/harnesses/product-team.json \
  --out .agent-harness/plan.json

このドメインで特に強力な、完了時の3つのゲートをタスクの検証に組み込みます。../spec-to-repo/scripts/validate_project.py（終了コード 0）、code-to-prd のゴールデン expected_outputs/、および research-summarizer の引用数チェックです。

厳守ルール

1. 確信する前に証拠を確認する：ost_linter.py が終了コード 0 を返さない限り、ロードマップ項目で OST を引用してはいけません。また、単一の参加者から得たものはインサイトとして断言せず、逸話として扱います。
2. 成果を第一にする：すべてのループは、測定可能な単一の成果に紐づけます。リンターの O1 ルールがインテークのゲートです。
3. 実験は計算に基づいて実施する：サンプルサイズは ../experiment-designer/scripts/sample_size_calculator.py で算出し、勘に頼ってはいけません。判定とともに MDE を報告します。
4. 優先順位付けではフレームワークを明示する：平常時は RICE、時間的な切迫度が優先される場合は WSJF／遅延コスト、満たされていないニーズには機会スコアリングを使い、どれを使うか、またその理由を明記します（references/product_operating_model.md を参照）。
5. AI 機能には評価を付けてリリースする：ゴールデンセットと評価基準は、確率的な機能に対する PRD の品質契約です（references/ai_product_evals.md）。
6. 自分が評価されるゲートを変更してはいけません。予算を使い切った場合は、名前を明示した担当者にエスカレーションし、決して成功として報告してはいけません。

質問ライブラリ（ドキュメントを使って深掘りするパターン）

1 ターンにつき 1 つ、推奨回答と典拠を提示します。レーンを決定づける判断が確定するまで、サブスキルを実行したりループを開始したりしてはいけません。

• DISCOVERY レーン：「このディスカバリーが目指す単一の成果は何ですか？ 数値で表してください。推奨：まず OST のルートとして記述します。成果を伴わない機会は、機能を量産するだけです。典拠：Torres 著『Continuous Discovery Habits』、Opportunity Solution Tree（producttalk.org）。」
• PRIORITIZE レーン：「時間的な切迫度によってこの順位は変わりますか？ いずれかの項目を四半期遅らせると、その価値は損なわれますか？ 推奨：はいの場合は、RICE と併せて WSJF／遅延コストを算出して順位を比較し、1 段階の見積もり変更で順位が入れ替わる項目に印を付けます。典拠：Reinertsen 著『Principles of Product Development Flow』、SAFe の WSJF における偽の精密さへの批判。」
• EXPERIMENT レーン：「このテストの実施期間を正当化するベースライン率と MDE は何ですか？ 推奨：まず n を算出します。4 週間以内に到達できないなら、より大きな効果をもたらす施策をテストします。典拠：統計的検出力分析（experiment-designer）。」
• ANALYTICS レーン：「North Star は価値交換の先行指標ですか、それとも収益や見せかけの指標ですか？ 推奨：インプットツリーを備えた先行価値指標を使います。典拠：Amplitude 著『The North Star Playbook』。」
• STRATEGY レーン：「これらの OKR は成果ですか、それともリリース項目の一覧ですか？ 推奨：成果です。アウトプットを基準とする OKR は、オペレーティングモデルにおける最大の失敗要因です。典拠：Cagan 著『Transformed』（SVPG、2024）。」
• BUILD レーン（spec-to-repo / saas-scaffolder）：「そもそもこれを構築すべきだという、検証済みの仮説は何ですか？ 推奨：検証を通過した OST テストに紐づけます。構築はアイデアを検証する最もコストの高い方法です。典拠：Torres 著、Bland 著『Testing Business Ideas』。」

前提条件

1. ユーザーは、プロダクトの意思決定に責任を持つ（またはその責任者に助言する）立場です。
2. ディスカバリーデータはワークスペース内に JSON ログとして保存されます。ループはファイルベースで再開可能です。すべてのツールには、まずデータ構造を確認できる --sample が用意されています。
3. 4 つのスタンドアロンプラグインはバンドルと併せてインストールされています（インストールされていない場合でも、ルーターはパス経由でそれらにルーティングします）。

対象外

• デリバリーループではありません。スプリント／フロー／Jira の作業は project-management にルーティングします。
• 汎用ループエンジンではありません。それは engineering/agent-harness が担います。このオーケストレーターはプロダクト領域向けのアダプター（ルーター＋ディスカバリーゲート）です。
• キャンペーンマーケティングではありません。marketing/landing はゼロからマーケティングページを構築します。ここでの landing-page-generator は、プロダクトの Next.js／TSX ページをひな形から生成します。

出力成果物

モード	成果物
ルート	サブスキル固有の成果物＋典拠を 1 つ引用した、200 語以内の要約
ディスカバリーループ	discovery_log.json ＋定期レポート＋リンターを通した ost.json
ハーネス実行	.agent-harness/plan.json ＋ state.json ＋終了時の引き継ぎ

アンチパターン（避けてください）

• ❌ 念のために16レーンすべてを実行する — 1つにルーティングし、要約して、確認後に連鎖させます
• ❌ リンターに不合格となったOSTを引用する、または1人の参加者の逸話をインサイトに格上げする
• ❌ 評価（ゴールデンセット＋ルーブリック）のないPRDでAI機能をリリースする
• ❌ ディスカバリーの連続記録がいつの間にか途切れるのを放置する — DORMANTは明示的にエスカレーションします
• ❌ 締め切りが優先される状況で、RICEだけを優先順位付けの基準にする

参考資料

• references/continuous_discovery_canon.md — Torres、OST、仮説検証、JTBD切り替えインタビュー、ストーリーマッピング
• references/product_operating_model.md — Cagan Transformed、North Starフレームワーク、PLGベンチマーク、WSJF/ODIとRICEの比較
• references/ai_product_evals.md — PRDとしての評価、モデルカード、評価者とオプティマイザーのループ
• ループエンジン：engineering/agent-harness · ループ用語集：loop-library