Skill Planner

Skill Planner

WHAT

course-bundleの全抽出結果を分析し、生成可能なスキルの計画（skill-plan.json）を作成する。 各スキルの目的・入出力・必要リソース・依存関係を設計し、ユーザー承認後にskill-synthesizerへ渡す。

スコープ外:

• スキルの実際の生成（skill-synthesizerの責務）
• トランスクリプトの抽出（concept-extractor, procedure-extractor, visual-indexerの責務）
• リソースの取得（resource-fetcherの責務）

---

WHY

抽出フェーズで得られたknowledge, procedures, resourcesは断片的。そのままではスキル化できない。 計画フェーズで以下を決定する:

1. 何をスキルにするか - 手順+リソースの組み合わせから実行可能な単位を特定 2. 何を共有知識にするか - 概念・マインドセットは基盤knowledgeに集約 3. 依存関係は何か - スキル間の前提関係を明示 4. 何が未解決か - リソース未取得など、スキル化の障害を特定

ユーザー承認なしにskill-synthesizerに渡してはならない。 スキル構成はユーザーが決める。

---

発動条件

• 「スキル計画」「スキル設計」
• 「何のスキルが作れるか」
• 「skill plan」「plan skills」
• /skill-planner

---

HOW

入力要件

BLOCKER: 前提条件チェック

以下を確認するまでStep 2に進むな:

1. knowledge/knowledge-graph.json が存在すること

2. 少なくとも1つのprocedures.jsonが存在すること

>

存在しない場合はユーザーに報告し、concept-extractorまたはprocedure-extractorの実行を提案すること。

---

処理ステップ

Step 1: 前提条件チェック ← BLOCKER
Step 2: 全入力ファイル読み込み
Step 3: スキル候補の特定
Step 4: スキルタイプの判定
Step 5: 共有知識の設計
Step 6: 依存関係グラフの構築
Step 7: 未解決項目の特定
Step 8: skill-plan.json生成
Step 9: 自己検証
Step 10: ユーザーへの提示 ← BLOCKER（承認必須）

Step 2: 全入力ファイル読み込み

以下を全て読み込む（存在するもののみ）:

1. manifest.json → コース名・章リスト 2. knowledge/knowledge-graph.json → 概念依存関係 3. 全chapters//knowledge.json → 概念・暗黙知 4. 全chapters//procedures.json → 手順 5. resources-manifest.json → 取得済みリソース 6. manuals/ ディレクトリのファイル一覧 → マニュアル参照用

Step 3: スキル候補の特定

procedures.jsonの各手順について: 1. 独立した目的（入力→出力）を持つか確認 2. 対応するリソース（プロンプト、テンプレート等）があるか確認 3. 候補としてリストアップ

Step 4: スキルタイプの判定

Step 5: 共有知識の設計

以下を shared_knowledge に集約:

• 基盤概念（複数スキルの前提となる概念）
• NG/OKパターン（講座全体の判断基準）
• チェックリスト項目（品質確認の共通基準）
• マインドセット・価値観（暗黙知から抽出）

Step 6: 依存関係グラフの構築

1. knowledge-graph.jsonのprerequisite_graphを参照 2. 各スキルが参照する概念の前提を追跡 3. depends_onとして記録 4. 循環依存がないことを確認

Step 7: 未解決項目の特定

以下をunresolvedに記録:

• リソースが言及されているが未取得
• URLが記載されているがアクセスできない
• 外部ツールが必要だが未確認

Step 8: skill-plan.json生成

スキーマは schemas/skill-plan.schema.json に準拠。 出力先: {course-bundle}/skill-plan.json

Step 9: 自己検証

以下をすべてチェックし、問題があれば修正:

• [ ] 各executable skillにresourcesまたはproceduresがあるか
• [ ] skill_nameが全体で一意か
• [ ] depends_onが実在するスキル名を参照しているか
• [ ] trigger_wordsが講座固有の具体的なワードか（「作成」「生成」のような汎用語はNG）
• [ ] shared_knowledgeに基盤概念が含まれているか
• [ ] unresolved欄に未取得リソースが全て記載されているか
• [ ] dependency_graphに循環依存がないか
• [ ] 1スキルが3章以上の内容を含んでいないか（巨大スキル禁止）

---

スキル分割ルール

分割の詳細な判断基準は references/planning-strategy.md を参照。

---

NG / OK テーブル

---

BLOCKER: ユーザー承認

skill-plan.jsonを生成したら、必ず以下のフォーマットでユーザーに提示し、承認を得ること。

承認を得るまでskill-synthesizerに渡してはならない。

---

ユーザーへの提示

処理完了後、以下のフォーマットで提示:

## Skill Plan: {course_name}

### ヒアリング仮説との照合
manifest.jsonのuser_context.skill_hypothesesがある場合、仮説との照合結果を表示:

| 仮説 | 結果 | 対応スキル |
|------|------|-----------|
| {hypothesis} | ✅ 検出 / ⚠️ リソース未取得 / ❌ 該当なし | {skill_name or "—"} |

➕ 追加発見: {仮説になかったが作れるスキル}

### Executable Skills ({n}件)

| # | スキル名 | 目的 | リソース | 状態 |
|---|---------|------|---------|------|
| 1 | {skill_name} | {purpose} | {resource_names} | Ready / Unresolved |
| ... |

### Shared Knowledge
- 基盤概念: {n}件
- NG/OKパターン: {n}件
- チェックリスト: {n}件
- 参照マニュアル: {manual_refs}

### 依存関係

{dependency_graph as text}

### 未解決項目 ({n}件)
| リソース名 | 言及箇所 | 必要なアクション |
|-----------|---------|----------------|
| {name} | {mentioned_in} | {action_needed} |

---

このプランでスキルを生成しますか？（全部 / 選択 / 修正）

---

ユーザーの回答への対応

Planning Strategy

course-bundleの抽出結果からスキル計画を策定するための詳細ガイド。

---

1. Executableスキルの特定方法

判定フロー

procedures.jsonの各手順について:
  ├─ 明確な入力→出力があるか？
  │   ├─ YES: スキル候補
  │   └─ NO: shared_knowledgeへ
  │
  スキル候補について:
  ├─ 対応するプロンプト/テンプレートがresources-manifest.jsonにあるか？
  │   ├─ YES (fetched): executable (Ready)
  │   ├─ YES (not_fetched): executable (Unresolved記載)
  │   └─ NO: 手順のみのexecutable（リソース不要型）
  │
  リソース不要型の判定:
  ├─ 手順だけで実行完結するか？（例: 設定手順、分析手順）
  │   ├─ YES: executable
  │   └─ NO: unresolvedに記載

入力→出力の判定基準

以下のパターンがあればスキル候補:

スキルにならないもの

---

2. スキル境界の判定（分割 vs 統合）

分割すべき場合

統合すべき場合

境界判定チェックリスト

以下すべてYESなら1スキル:

• [ ] 同じプロンプト/テンプレートを使うか？
• [ ] 入力の種類は同じか？
• [ ] 出力の種類は同じか？
• [ ] 途中で中断してもユーザーに意味のある成果物があるか？ → NOなら分離不能

1つでもNOなら分割を検討。

---

3. 依存関係グラフの構築方法

Step 1: 概念依存の追跡

knowledge-graph.jsonのprerequisite_graphから:
  concept A → prerequisite: concept B

concept Aを使うスキルXは、concept Bを含むスキルYに依存
  → skill X depends_on skill Y

Step 2: 共有知識への依存

ほぼ全てのexecutableスキルは shared_knowledge に依存する。 これは明示的にdepends_onに含める。

Step 3: スキル間の直接依存

スキルAの出力がスキルBの入力になる場合:
  → skill B depends_on skill A

Step 4: 循環依存の検出

dependency_graphを深さ優先探索:
  visitedセットにスキル名を追加しながら探索
  既にvisitedにあるスキル名に到達 → 循環依存

循環依存が見つかった場合:
  1. 共通部分をshared_knowledgeに切り出す
  2. 両スキルがshared_knowledgeに依存する形に変更

依存関係の原則

---

4. 未解決リソースの扱い

分類と対応

unresolvedがあってもスキルは作れるか？

---

5. Good vs Bad スキル計画の例

Bad: 巨大スキル

{
  "skill_name": "youtube-booster-all-in-one",
  "purpose": "YouTubeブースター講座の全内容を実行するスキル",
  "procedures": ["p03-01", "p04-01", "p05-01", "p06-01", "p07-01", "p08-01", "p09-01", "p10-01", "p11-01", "p12-01"]
}

問題点:

• 10章分の手順を1スキルに詰め込んでいる
• 入力→出力が不明確
• 全てのリソースが必要になりコンテキストを圧迫
• ユーザーが一部だけ使いたい場合に対応できない

Good: 目的別分割

{
  "planned_skills": [
    {
      "skill_name": "prediction-x-generator",
      "purpose": "PredictionXで参考台本から台本プロンプトを自動生成",
      "procedures": ["p09-01"],
      "resources": [{"id": "r01", "name": "PredictionXプロンプト", "status": "fetched"}],
      "rationale": "PredictionXプロンプトが取得済みで、手順p09-01に5ステップの明確なワークフローがある"
    },
    {
      "skill_name": "fusion-omega-generator",
      "purpose": "FusionOmegaで新規台本をゼロから生成",
      "procedures": ["p10-01"],
      "resources": [{"id": "r02", "name": "FusionOmegaプロンプト", "status": "fetched"}],
      "rationale": "FusionOmegaプロンプトが取得済みで、PredictionXとは入力が異なる（参考動画不要）"
    }
  ]
}

良い点:

• 1スキル=1目的
• 別テンプレート=別スキル
• 各スキルの入力→出力が明確
• 個別に実行可能

Bad: 汎用trigger_words

{
  "trigger_words": ["作成", "生成", "作って"]
}

問題点: あらゆるスキルが誤発動する

Good: 講座固有のtrigger_words

{
  "trigger_words": ["PredictionX", "台本自動生成", "コピー3回", "参考台本"]
}

良い点: 講座特有の用語で確実に正しいスキルが発動

Bad: 未解決リソースの無視

{
  "skill_name": "gpts-template-builder",
  "type": "executable",
  "resources": [{"id": "r05", "name": "GPTsテンプレート", "status": "fetched"}]
}

問題点: 実際にはfetchedではないのにfetchedと記載

Good: 正直な状態報告

{
  "skill_name": "gpts-template-builder",
  "type": "executable",
  "resources": [{"id": "r05", "name": "GPTsテンプレート", "path": "", "status": "not_fetched"}],
  "rationale": "手順p06-01は明確だが、GPTsテンプレートが未取得のため実行にはリソース取得が必要"
}

加えてunresolvedに記載:

{
  "unresolved": [
    {
      "type": "resource_not_fetched",
      "name": "GPTsテンプレート",
      "mentioned_in": "ch06",
      "action_needed": "Notionページへのアクセスが必要"
    }
  ]
}

---

6. shared_knowledgeの設計指針

何を含めるか

何を含めないか

命名規則

shared_knowledgeの名前は {course-name}-knowledge とする。 例: youtube-booster-knowledge, ai-marketing-knowledge