ln-230-story-prioritizer

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリを基準とします。

ストーリーの優先順位付け

タイプ： L3 ワーカー カテゴリ： 2XX 計画

市場調査を用いた RICE スコアリングでストーリーを評価します。エピック向けの統合された優先順位付けテーブルを生成します。

目的と範囲

• ln-220 によるストーリー作成後に優先順位を付けます
• 詳細な調査を行う前に、すべてのストーリーを低コストでトリアージします
• 優先順位の確信度に影響する場合に限り、市場規模と競合を調査します
• 各ストーリーの RICE スコアを算出します
• 優先順位付けテーブル（P0/P1/P2/P3）を生成します
• 出力先：docs/market/[epic-slug]/prioritization.md

使用するタイミング

このスキルを使用する場合：

• ln-220 でストーリーが作成され、ビジネス上の優先順位付けが必要な場合
• キャパシティが限られた状態でスプリントを計画する場合（どのストーリーから着手するか）
• ステークホルダーのレビューで、データに基づいた優先順位が必要な場合
• 実装前に機能の ROI を評価する場合

次の場合は使用しないでください：

• エピックにストーリーがまだない場合（先に ln-220 を実行してください）
• ストーリーが純粋に技術的な内容の場合（インフラストラクチャ、リファクタリング）
• docs/market/ にすでに優先順位付けが存在する場合

---

入力パラメーター

パラメーター	必須	説明	デフォルト
epic	はい	エピック ID、または「Epic N」形式	-
stories	いいえ	優先順位を付ける特定のストーリー ID	エピック内のすべて
depth	いいえ	調査の深さ（quick/standard/deep）	"standard"

depth のオプション：

• quick - ストーリーあたり 2～3 分、種類ごとに WebSearch 1 回
• standard - ストーリーあたり 5～7 分、種類ごとに WebSearch 2～3 回
• deep - ストーリーあたり 8～10 分、包括的な調査

---

出力構成

docs/market/[epic-slug]/
└── prioritization.md    # Consolidated table + RICE details + sources

実行時コントラクト

必須読み込み： references/planning_worker_runtime_contract.md、references/coordinator_summary_contract.md を読み込みます 必須読み込み： ストーリーに H/G/run ID の参照がある場合、またはプロジェクトの researchgraph の証拠が優先順位の確信度に影響する可能性がある場合は、references/researchgraph_mcp_usage.md を読み込みます。

実行時ファミリー：planning-worker-runtime

識別子：

• epic-{epicId}

フェーズ：

1. PHASE_0_CONFIG
2. PHASE_1_DISCOVERY
3. PHASE_2_LOAD_STORY_METADATA
4. PHASE_3_ANALYZE_STORIES
5. PHASE_4_GENERATE_PRIORITIZATION
6. PHASE_5_WRITE_SUMMARY
7. PHASE_6_SELF_CHECK

サマリーコントラクト：

• summary_kind=story-prioritization-worker
• ペイロードには epic_id、depth、stories_analyzed、priority_distribution、top_story_ids、prioritization_path、warnings を含めます
• 管理モードでは、呼び出し元から指定された summaryArtifactPath に書き込みます
• 管理モードのデフォルトの成果物パスのパターン：.hex-skills/runtime-artifacts/runs/{parent_run_id}/story-prioritization-worker/ln-230--{identifier}.json

テーブルの列（ユーザー要件に基づく）：

優先度	顧客の課題	機能	ソリューション	根拠	影響	市場	出典	競合
P0	ユーザーの悩み	ストーリーのタイトル	技術的なアプローチ	重要な理由	ビジネスへの影響	$XB	[リンク]	Blue 1-3 / Red 4-5

---

入力

入力	必須	ソース	説明
epicId	はい	args、kanban、ユーザー	処理するエピック

解決方法： エピック解決チェーン。 ステータスフィルター： アクティブ（planned/started）

ツール設定

必須読み込み： references/environment_state_contract.md、references/storage_mode_detection.md、references/input_resolution_pattern.md を読み込みます

抽出：task_provider = Task Management → Provider

調査ツール

ツール	用途	クエリ例
WebSearch	市場規模、競合他社	"[domain] market size {current_year}"
mcp__Ref	業界レポート	"[domain] market analysis report"
hex-research	ローカルの仮説、目標、ベンチマークの証拠	明示的な H/G/run のコンテキストには find_hypotheses、inspect_goal、find_runs
Task provider	ストーリーの読み込み	linear の場合：list_issues／それ以外：Glob story.md
Glob	既存の項目を確認	"docs/market/[epic]/*"

---

ワークフロー

フェーズ 1：発見（2 分）

目的： 入力を検証し、コンテキストを準備します。

プロセス：

1. epicId を解決する： ガイドに従って Epic Resolution Chain を実行します。

2. Epic の詳細を読み込む：

   • IF task_provider == "linear": get_project(query=epicId)
   • ELSE IF task_provider == "github": gh issue view {epicId} -R {REPO} --json number,title,body
   • ELSE: Read("docs/tasks/epics/epic-{N}-*/epic.md")
   • 抽出項目：Epic ID、タイトル、説明

3. 設定を自動検出する：

   • docs/tasks/kanban_board.md を読み込み、Team ID を取得します
   • Epic のタイトルをスラッグ化して出力パスにします

4. 既存の優先順位付けを確認する：

   Glob: docs/market/[epic-slug]/prioritization.md
   

   • 存在する場合：「既存のものを更新しますか、それとも新規作成しますか？」と尋ねます
   • 新規の場合：続行します

5. 出力ディレクトリを作成する：

   mkdir -p docs/market/[epic-slug]/
   

出力： Epic メタデータ、出力パス、既存確認の結果

---

フェーズ 2：ストーリーのメタデータを読み込む（3 分）

目的： メタデータのみでストーリーのキューを作成し、すべてのストーリーについて大まかなスコアリングの入力情報を準備します。

プロセス：

1. Epic からストーリーを取得する： IF task_provider == "linear":

   list_issues(project=Epic.id, label="user-story")
   

   ELSE IF task_provider == "github":

   gh api /repos/{O}/{R}/issues/{epic_num}/sub_issues --jq '.[].number'
   → for each: gh issue view {num} -R {REPO} --json number,title,state,labels
   → filter: label "user-story"
   

   ELSE (file mode):

   Glob("docs/tasks/epics/epic-{N}-*/stories/*/story.md")
   

2. メタデータのみを抽出する：

   • ストーリー ID、タイトル、ステータス
   • 利用可能な場合は最小限の Epic コンテキスト
   • DO NOT 説明全体をまだ読み込まないでください

3. ストーリーをフィルタリングする：

   • 除外：Done、Cancelled、Archived
   • 含める：Backlog、Todo、In Progress

4. 処理キューを作成する：

   • 順序：既存の優先順位（ある場合）、次に ID
   • 件数：処理する N 件のストーリー

出力： ストーリーキュー（ID + タイトル + 最小限のコンテキスト）、1 ストーリーあたり約 50～80 トークン

---

フェーズ 3：2 パスのストーリー分析

目的： まずすべてのストーリーを低コストでスコアリングし、判断が変わる可能性がある候補にのみ、詳細な調査を行います。

重要： 詳細な調査中も、コンテキストに含める完全なストーリーは常に 1 件までにしてください。

researchgraph レイアウトが存在する場合は、優先順位が仮説のステータス、目標のカバレッジ、ベンチマークの証拠、または実装の準備状況に左右されるストーリーに限り、ローカルのグラフチェックを実行します。ローカルのグラフ証拠は RICE の信頼度とリスクを変える可能性がありますが、市場規模や競合の調査に代わるものではありません。

パス A：すべてのストーリーを低コストでトリアージする

各ストーリーについて、以下を推定するのに必要な詳細のみを読み込みます。

• 顧客の課題
• おおまかなソリューションの形
• 想定されるリーチ
• 想定されるインパクト
• 想定される工数
• 初期の信頼度区分

ステップ 3.1：ストーリーの説明を読み込む

IF task_provider == "linear":

// configured tracker provider: getStory(id=storyId)

ELSE IF task_provider == "github":

gh issue view {storyId} -R {REPO} --json number,title,body,state,labels

ELSE (file mode):

Read("docs/tasks/epics/epic-{N}-*/stories/us{NNN}-*/story.md")

ストーリーから抽出する項目：

• 機能： ストーリーのタイトル
• 顧客の課題： 「So that [value]」と Context セクションから取得
• ソリューション： Technical Notes（実装アプローチ）から取得
• 根拠： AC と Success Criteria から取得

ステップ 3.2：RICE の大まかな見積もりを作成する

ストーリーと Epic のコンテキストを使い、以下を割り当てます。

• 大まかな Reach
• 大まかな Impact
• 大まかな Effort
• 初期の Confidence

次のいずれかを指定します。

• full_research_required
• rough_estimate_ok
• borderline_needs_review

パス B に進める条件：

• 大まかなスコアで P0/P1 の候補に見える
• 信頼度が低い
• ストーリーが優先順位のしきい値に近い
• ストーリーに戦略上または市場に関する不確実性がある

パス B：選択的な詳細調査

パス A で選ばれたストーリーに限り、外部情報を含む詳細な調査を行います。

ステップ 3.3：市場規模を調査する

WebSearch クエリ（調査の深さに基づく）：

"[customer problem domain] market size TAM {current_year}"
"[feature type] industry market forecast"

mcp__Ref クエリ：

"[domain] market analysis Gartner Statista"

抽出項目：

• 市場規模：$XB（単位：B＝10 億、M＝100 万）
• 成長率：X% CAGR
• ソース：URL + 日付

信頼度の対応付け：

• 業界レポート（Gartner、Statista）→ 信頼度 0.9～1.0
• ニュース記事 → 信頼度 0.7～0.8
• ブログ／フォーラム → 信頼度 0.5～0.6

ステップ 3.4：競合を調査する

WebSearch クエリ：

"[feature] competitors alternatives {current_year}"
"[solution approach] market leaders"

競合を数え、分類する：

見つかった競合数	競争指数	市場タイプ
0	1	ブルーオーシャン
1-2	2	新興
3-5	3	成長中
6-10	4	成熟
>10	5	レッドオーシャン

ステップ 3.5：最終 RICE スコアを算出する

RICE = (Reach x Impact x Confidence) / Effort

リーチ（1-10）： 四半期あたりの影響を受けるユーザー数

スコア	ユーザー数	指標
1-2	<500	ニッチ、単一のペルソナ
3-4	500-2K	部門レベル
5-6	2K-5K	組織全体
7-8	5K-10K	複数の組織
9-10	>10K	プラットフォーム全体

インパクト（0.25-3.0）： ビジネス価値

スコア	レベル	指標
0.25	最小	あれば望ましい
0.5	低	QoL の向上
1.0	中	効率の向上
2.0	高	収益を牽引
3.0	極めて大	戦略的な差別化要因

信頼度（0.5-1.0）： データ品質（ステップ 3.2 より）

データ信頼度の評価：

RICE の各要素について、データの信頼度を評価します。

信頼度	基準	スコアの調整
高	複数の信頼できる情報源（Gartner、Statista、SEC の提出書類）	要素をそのまま使用
中	1～2 件の情報源、品質はさまざま（ブログ＋レポート）	要素の ±25% の範囲を提示
低	情報源なし、チームの推定のみ	要素の ±50% の範囲を提示

出力： 優先順位付けテーブルに要素ごとの信頼度と RICE の範囲（楽観的／悲観的）を示し、不確実性を明確にします。

工数（1-10）： 人月

スコア	期間	ストーリーの指標
1-2	<2 週間	3 AC、シンプルな CRUD
3-4	2-4 週間	4 AC、統合
5-6	1-2 か月	5 AC、複雑なロジック
7-8	2-3 か月	外部依存関係
9-10	3 か月以上	新しいインフラ

ステップ 3.6：優先度を決定する

優先度	RICE のしきい値	競合状況による上書き
P0（クリティカル）	>= 30	または 競争 = 1（ブルーオーシャンの独占）
P1（高）	>= 15	または 競争 <= 2（新興市場）
P2（中）	>= 5	-
P3（低）	< 5	競争 = 5（レッドオーシャン）の場合は P3 に設定

ステップ 3.7：保存してクリアする

• メモリ上の結果テーブルに行を追加します
• 行が full-research か rough-estimate かを記録します
• コンテキストからストーリーの説明をクリアします
• キュー内の次のストーリーに進みます

ストーリーごとの出力： 信頼度レベルを含む、優先順位付けテーブルの完全な行

---

フェーズ 4：優先順位付けテーブルを生成する（5 分）

目的： 統合された Markdown 出力を作成します。

手順：

1. 結果を並べ替える：

   • 第 1 基準：優先度（P0 → P3）
   • 第 2 基準：RICE スコア（降順）

2. Markdown を生成する：

   • references/templates/prioritization_template.md のテンプレートを使用します
   • 優先度の概要、メインテーブル、RICE の詳細、情報源を記入します
   • 各ストーリーが詳細調査と概算のどちらを使用したかを明示します

3. ファイルを保存する：

   Write: docs/market/[epic-slug]/prioritization.md
   

出力： 保存された prioritization.md

---

フェーズ 5：概要と次のステップ（1 分）

目的： 結果と推奨事項を表示します。

出力形式：

## Prioritization Complete

**Epic:** [Epic N - Name]
**Stories analyzed:** X
**Time elapsed:** Y minutes

### Priority Distribution:
- P0 (Critical): X Stories - Implement ASAP
- P1 (High): X Stories - Next sprint
- P2 (Medium): X Stories - Backlog
- P3 (Low): X Stories - Consider deferring

### Top 3 Priorities:
1. [Story Title] - RICE: X, Market: $XB, Competition: Blue/Red

### Saved to:
docs/market/[epic-slug]/prioritization.md

### Next Steps:
1. Review table with stakeholders
2. Run ln-300 for P0/P1 Stories first
3. Consider cutting P3 Stories

---

時間制限

深度	ストーリーごと	合計（10 ストーリー）
クイック	2-3 分	20-30 分
標準	5-7 分	50-70 分
詳細	8-10 分	80-100 分

時間管理ルール：

• ストーリーが時間の上限を超えた場合：概算を維持し、信頼度を低く設定します
• 合計時間が上限を超えた場合：有望度の高いストーリー、または判断が難しいストーリーにのみ詳細調査を行います
• 可能な場合は WebSearch を並行して実行します（市場＋競合）

---

トークン効率

読み込みパターン：

• フェーズ 2：メタデータのみ（ストーリーあたり約 50 トークン）
• フェーズ 3：説明全体を 1 件ずつ読み込み（ストーリーあたり約 3,000～5,000 トークン）
• 各ストーリーの処理後：説明をクリアし、結果の行のみを保持（約 100 トークン）

メモリ管理：

• 順次処理（並列処理はしません）
• コンテキストの最大量：一度にストーリーの説明 1 件
• 結果はコンパクトなテーブル行として蓄積します

---

エコシステムとの統合

ワークフロー内での位置：

ln-210 (Scope → Epics)
     ↓
ln-220 (Epic → Stories)
     ↓
ln-230 (RICE per Story → prioritization table) ← THIS SKILL
     ↓
ln-300 (Story → Tasks)

依存関係：

• WebSearch、mcp__Ref（市場調査）
• タスクプロバイダー：references/tracker_provider_contract.md に従って設定済みのトラッカープロバイダー（エピック、ストーリーを読み込む）
• Glob、Write、Bash（ファイル操作）

後続での利用：

• スプリント計画では、ストーリーを選択する際に P0/P1 を使用します
• ln-300 はストーリーを優先順位順に処理します
• 関係者は実装前にレビューします

構造化されたワーカー出力：

• 単独モードでも優先順位付けサマリーのエンベロープを返します
• summaryArtifactPath が指定されている場合は、同じ JSON アーティファクトを書き込みます

---

重要なルール

1. まずトリアージ - 詳細な調査の前に、すべてのストーリーを対象に低コストのスコアリングを行います
2. 詳細調査のデータはすべて出典を明記 - 市場に関する数値にはすべて出典と日付が必要です
3. 新しいデータを優先 - 過去 2 年以内のデータを使用し、それより古い場合は警告します
4. 必要な深さに応じて相互参照 - 市場動向に左右されるストーリーでは、2 件以上の情報源を使用します
5. 時間を厳守 - さらに調査しても判断が変わらない場合は、概算を維持します
6. 信頼度レベル - 高／中／低、およびスコアが概算か詳細調査に基づくものかを明記します
7. 推測しない - 出典のある主張のみとし、データの欠落は「[No data]」と記します
8. 一度に 1 つのストーリー - トークン効率が重要です
9. 言語を維持 - ユーザーがロシア語で依頼した場合は、ロシア語で回答します

---

完了の定義

• 設定済みのトラッカープロバイダーを通じてエピックを検証済み
• メタデータ優先キューを通じてすべてのストーリーを読み込み済み
• すべてのストーリーについてパス A の概算トリアージを完了済み
• 詳細調査は、ポテンシャルの高いストーリーまたは信頼度の低いストーリーに限定済み
• 各ストーリーの RICE スコアを算出済み
• 競合指数を割り当て済み（1～5）
• 優先度を割り当て済み（P0/P1/P2/P3）
• 出力に信頼度区分と調査の深さを表示済み
• 表を優先度 + RICE の順に並べ替え済み
• ファイルを docs/market/[epic-slug]/prioritization.md に保存済み
• 上位の優先事項と次のステップを含むサマリーを作成済み
• 構造化された story-prioritization-worker のサマリーを返却済み
• summaryArtifactPath が指定されている場合はサマリーアーティファクトを書き込み済み
• 合計所要時間が予算内

---

使用例

基本的な使い方：

ln-230-story-prioritizer epic="Epic 7"

パラメーターを指定する場合：

ln-230-story-prioritizer epic="Epic 7: Translation API" depth="deep"

特定のストーリーを指定する場合：

ln-230-story-prioritizer epic="Epic 7" stories="US001,US002,US003"

出力例（docs/market/translation-api/prioritization.md）：

優先度	顧客の課題	機能	解決策	根拠	影響度	市場	出典	競争状況
P0	「翻訳を繰り返すと GPU コストがかかる」	翻訳メモリ	Redis キャッシュ、5ms の検索	GPU コストを 70～90% 削減	高	$2B+	M&M	3
P0	「PDF を翻訳できない」	PDF 対応	PDF の解析 + レイアウト	エンタープライズ導入の障壁	高	$10B+	Eden	5
P1	「動画字幕が必要」	SRT/VTT 対応	タイミングの維持	ブルーオーシャンの機会	中	$5.7B	GMI	2

---

フェーズ 6：メタ分析

任意の参照資料：ユーザーが実行後のメタ分析またはプロトコル形式の実行振り返りを求めた場合に限り、references/meta_analysis_protocol.md を読み込みます。

スキルの種類：planning-worker。依頼された場合は、すべてのフェーズの完了後に実行します。planning-worker 形式を使用してチャットに出力します。

参照ファイル

• 必読： references/environment_state_contract.md を読み込みます
• 必読： references/storage_mode_detection.md を読み込みます
• 必読： references/research_tool_fallback.md を読み込みます

ファイル	目的
prioritization_template.md	出力用 Markdown テンプレート
rice_scoring_guide.md	RICE 要素の尺度と例
research_queries.md	ドメイン別 WebSearch クエリのテンプレート
competition_index.md	ブルーオーシャン／レッドオーシャンの分類ルール

---

バージョン： 2.0.0 最終更新日： 2026-04-05