ノートブックからのスキル

学習教材（ドキュメント、記事、動画）または高品質な例（ブログ記事、デザイン、コード）から実行可能なスキルを生成するために、実行可能な方法論を抽出します。

コア哲学: NotebookLM はあなたが理解するのを助けます。このスキルはあなたが実行するのを助けます。

使用時機

ユーザーが知識を実行可能なスキルに変えたい場合：

• 「この記事でコードレビューについて読んだので、そこからスキルを作成してほしい」
• 「これは素晴らしいテクニカルブログ記事です。執筆方法論を抽出してください」
• 「このPDFガイドをスキルに変えて再利用できるようにしたい」
• 「この例から学び、同様の出力を生成するスキルを作成してください」

サポートされているインプットタイプ

タイプ	処理方法
ローカルファイル	PDF、Word、Markdown - 直接読み込み
Web URL	WebFetch でコンテンツ抽出
YouTube	yt-dlp で字幕取得、利用不可の場合は Whisper
NotebookLM リンク	ブラウザオートメーション でノート/サマリー抽出
例/出力	方法論をリバースエンジニアリング

ステップ 0: インプットタイプの識別

重要な最初のステップ - どの処理パスを使用するかを決定します：

ユーザーインプット
    │
    ├─ 教育的意図がある? ("how to", "steps", "guide")
    │   └─ YES → パス A: 方法論ドキュメント
    │
    ├─ 完成した作品? (記事、デザイン、コード、提案書)
    │   └─ YES → パス B: 例 (リバースエンジニアリング)
    │
    └─ どちらでもない? → このコンテンツは不適切であることをユーザーに伝える

パス A の指標 (方法論ドキュメント):

• 「how to」「steps」「method」「guide」といった言葉を含む
• 番号付きリストまたはステップシーケンスがある
• 教育的意図で書かれている
• 「何をすべきか」を説明している

パス B の指標 (例/出力):

• 完成した作品/成果物である
• 教育的意図がない
• 「作り方」ではなく「その物そのもの」である
• 例: よく書かれたブログ記事、完成した提案書、コードプロジェクト

---

パス A: 方法論ドキュメントから抽出

A1: ドキュメント適合性の検証

ドキュメントがスキル生成に適しているかを確認します（最低 2 つは満たす必要があります）:

• 明確な目標/成果がある
• 繰り返し可能なステップ/プロセスがある
• 品質基準がある
• コンテキスト/シナリオの説明がある

不適切な場合: ユーザーに正直に伝え、理由を説明してください。

A2: スキルタイプの識別

タイプ	特性	例
How-to	明確なステップシーケンス、インプット→アウトプット	Docker のデプロイ、CI/CD の設定
Decision	条件、トレードオフ、選択肢	データベースの選択、フレームワーク選定
Framework	メンタルモデル、分析ディメンション	SWOT、5W1H、ファーストプリンシパル
Checklist	検証リスト、合格/不合格基準	コードレビューチェックリスト、ローンチチェックリスト

A3: タイプ別に構造を抽出

How-to の場合:

• 前提条件
• ステップシーケンス（ステップごとの予想出力付き）
• 最終的な予想結果
• よくあるエラー

Decision の場合:

• 決定要因
• オプションと長所/短所
• デシジョンツリー/フローチャート
• 推奨デフォルト

Framework の場合:

• コアコンセプト
• 分析ディメンション
• 適用方法
• 制限事項

Checklist の場合:

• チェック項目と基準
• 優先度レベル
• よく見落とされる項目

A4: スキルを生成

このテンプレートを使用してください：

## 適用シナリオ
[このスキルをいつ使うか]

## 前提条件
- [開始前に必要なもの]

## ステップ
1. [ステップ 1] - [予想される成果]
2. [ステップ 2] - [予想される成果]
...

## 品質チェックポイント
- [ ] [チェックポイント 1]
- [ ] [チェックポイント 2]

## よくある落とし穴
- [落とし穴 1]: [回避方法]

## ソース
- ドキュメント: [名前/URL]
- 抽出日時: [タイムスタンプ]

---

パス B: 例からリバースエンジニアリング

インプットが完成した作品（チュートリアルではない）の場合、方法論をリバースエンジニアリングします。

B1: アウトプットタイプの識別

これはどのような成果物ですか?

• テクニカルブログ記事
• 製品提案/PRD
• 学術論文
• コードアーキテクチャ
• デザインドキュメント
• その他: [指定]

B2: 構造の分析

例を分解します：

構造分析:
├── [パート 1]: [機能] - [割合 %]
├── [パート 2]: [機能] - [割合 %]
├── [パート 3]: [機能] - [割合 %]
└── [パート N]: [機能] - [割合 %]

答えるべき質問:

• 何個のパートがありますか?
• 各パートの機能は何ですか?
• 順序と割合は何ですか?

B3: 品質特性を抽出

この例を良くしているものは何ですか?

ディメンション	質問
構造	コンテンツはどのように組織されていますか?
スタイル	トーン、語彙選択、表現は?
テクニック	どのような方法が有効ですか?
ロジック	情報はどのように流れていますか?
詳細	小さいが重要なタッチは?

B4: プロセスをリバースエンジニアリング

推論: このアウトプットを作成するには、どのステップが必要ですか?

## 推論された生成ステップ
1. [ステップ 1]: [何をするか] - [重要なポイント]
2. [ステップ 2]: [何をするか] - [重要なポイント]
...

## 重要な決定
- [決定 1]: [オプション] - [この例が X を選んだ理由...]

## 再利用可能なテクニック
- [テクニック 1]: [適用方法]
- [テクニック 2]: [適用方法]

B5: スキルを生成

リバースエンジニアリングされたスキル用にこのテンプレートを使用してください:

## アウトプットタイプ
[このスキルが生成する成果物の種類]

## 適用シナリオ
[このタイプのアウトプットをいつ作成するか]

## 構造テンプレート
1. [パート 1]: [機能] - [~X%]
2. [パート 2]: [機能] - [~X%]
...

## 品質特性 (例から学んだもの)
- [特性 1]: [どのように現れるか]
- [特性 2]: [どのように現れるか]

## 生成ステップ
1. [ステップ 1]: [何をするか] - [ヒント]
2. [ステップ 2]: [何をするか] - [ヒント]
...

## チェックリスト
- [ ] [チェック項目 1]
- [ ] [チェック項目 2]

## 参考例
- ソース: [名前/URL]
- 分析日時: [タイムスタンプ]

---

例: パス A (方法論ドキュメント)

ユーザー: 「良いコミットメッセージの書き方についての記事からスキルを抽出してください」

プロセス:

1. 記事を読む
2. 識別: これは How-to タイプです（ステップがあり、教育的意図がある）
3. 抽出:
   • 目標: 明確で有用なコミットメッセージを書く
   • ステップ: 従来形式を使用、件名と本文を分離、など
   • 品質基準: 件名は 50 文字未満、命令形、など
4. ステップとチェックリスト付きのスキルを生成

---

例: パス B (リバースエンジニアリング)

ユーザー: 「これは素晴らしいテクニカルブログ記事です。それから学び、同様の記事を書くスキルを作成してください。」

プロセス:

1. 識別: これは 例 です（完成した作品、教育的意図なし）
2. 構造を分析:

   ├── フック: 実際の課題（2-3 文）
   ├── 問題: コアイシュー に関する 3 文
   ├── ソリューション: 結論優先、その後詳細
   ├── コード: 各スニペット < 20 行、コメント付き
   ├── 落とし穴: 3 つの一般的なエラー
   └── サマリー: 1 行のテイクアウェイ
   

3. 品質特性を抽出:
   • タイトル = 特定の技術 + 解決された問題
   • 1 段落に 1 つのアイデア
   • コード:テキスト比率 ~40:60
   • 信頼性のための個人的な逸話
4. ステップをリバースエンジニアリング:
   • 自分が解決した実際の問題から始める
   • ソリューション優先で書き、その後セットアップ
   • 段階的にコード例を追加
   • など
5. スキルを生成: 「テクニカルブログ記事の書き方」

---

アドバンス: 複数例学習

ユーザーが同じタイプの複数の例を提供する場合:

例 A ──┐
例 B ──┼──> 共通点を抽出 ──> コア方法論
例 C ──┘           │
                   ▼
             相違点を分析 ──> スタイル変種 / オプションテクニック

これにより、より堅牢で汎用可能なスキルが生成されます。

---

重要な注記

1. 必ず最初に検証してください - すべてのコンテンツがスキル抽出に適しているわけではありません
2. パスを早期に識別してください - 方法論ドキュメント vs 例は異なるアプローチが必要です
3. 具体的に - 曖昧なスキルは役に立ちません。具体的なステップと基準を含めてください
4. ソースを保持してください - 常に知識がどこから来たかをクレジットしてください
5. 明確化を求めてください - ユーザーの意図が不明な場合は、進める前に質問してください
6. 品質を速度より優先してください - コンテンツを真に理解するために時間をかけてください

このスキルが NOT である もの

• サマライザーではありません (NotebookLM の仕事です)
• ドキュメントコンバーターではありません
• 実行可能な方法論を繰り返し実行できるように抽出することです