skill-from-notebook

Notebook のスキル

学習教材（ドキュメント、記事、動画）や質の高い事例（ブログ記事、デザイン、コード）から実践的な方法論を抽出し、再利用可能なスキルを生成します。

基本理念：NotebookLM は理解を助けます。このスキルは、実際に行動するためのものです。

使用するタイミング

知識を実行可能なスキルに変換したい場合：

• 「コードレビューについての記事を読んだので、そこからスキルを作るのを手伝ってください」
• 「優れた技術ブログ記事を紹介します。執筆方法を抽出してください」
• 「この PDF ガイドを、再利用できるスキルに変換してください」
• 「この事例から学び、同様の成果物を作成するスキルを作ってください」

対応する入力タイプ

タイプ	処理方法
ローカルファイル	PDF、Word、Markdown を直接読み取ります
Web URL	WebFetch でコンテンツを抽出します
YouTube	字幕には yt-dlp を使用し、利用できない場合は Whisper を使用します
NotebookLM のリンク	ブラウザーを自動操作してノートや要約を抽出します
事例／出力	方法論をリバースエンジニアリングします

ステップ 0：入力タイプの特定

最初に必ず行う重要なステップです。使用する処理経路を決定します。

User Input
    │
    ├─ Has teaching intent? ("how to", "steps", "guide")
    │   └─ YES → Path A: Methodology Document
    │
    ├─ Is a finished work? (article, design, code, proposal)
    │   └─ YES → Path B: Example (Reverse Engineering)
    │
    └─ Neither? → Tell user this content is not suitable

パス A の判断材料（方法論ドキュメント）：

• 「方法」「手順」「手法」「ガイド」のような言葉が含まれている
• 番号付きリストや手順の流れがある
• 教える意図で書かれている
• 「何をすべきか」を説明している

パス B の判断材料（事例／出力）：

• 完成した作品／成果物である
• 教える意図がない
• 「作り方」ではなく「それ自体」である
• 例：優れたブログ記事、完成度の高い提案書、コードプロジェクト

---

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

A1：ドキュメントの適性を確認する

そのドキュメントがスキル生成に適しているかを確認します（以下のうち少なくとも 2 つを満たす必要があります）。

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

適していない場合：ユーザーに率直に伝え、その理由を説明してください。

A2：スキルのタイプを特定する

タイプ	特徴	例
手順型	明確な手順の流れ、入力→出力	Docker のデプロイ、CI/CD の設定
意思決定型	条件、トレードオフ、選択肢	データベースの選択、フレームワークの選定
フレームワーク型	メンタルモデル、分析の観点	SWOT、5W1H、第一原理
チェックリスト型	検証項目、合否基準	コードレビューのチェックリスト、リリースのチェックリスト

A3：タイプごとに構成を抽出する

手順型の場合：

• 前提条件
• 手順（各ステップで期待される出力を含む）
• 最終的に期待される結果
• よくあるエラー

意思決定型の場合：

• 判断要因
• 長所／短所を含む選択肢
• デシジョンツリー／フローチャート
• 推奨されるデフォルト

フレームワーク型の場合：

• 中核となる概念
• 分析の観点
• 適用方法
• 制約事項

チェックリスト型の場合：

• 基準を含む確認項目
• 優先度
• 見落とされやすい項目

A4：スキルを生成する

次のテンプレートを使用します。

## Applicable Scenarios
[When to use this skill]

## Prerequisites
- [What's needed before starting]

## Steps
1. [Step 1] - [Expected outcome]
2. [Step 2] - [Expected outcome]
...

## Quality Checkpoints
- [ ] [Checkpoint 1]
- [ ] [Checkpoint 2]

## Common Pitfalls
- [Pitfall 1]: [How to avoid]

## Source
- Document: [name/URL]
- Extracted: [timestamp]

---

パス B：事例からのリバースエンジニアリング

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

B1：出力タイプを特定する

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

• 技術ブログ記事
• 製品提案書／PRD
• 学術論文
• コードアーキテクチャ
• 設計ドキュメント
• その他：[具体的に記述]

B2：構成を分析する

事例を分解します。

Structure Analysis:
├── [Part 1]: [Function] - [Proportion %]
├── [Part 2]: [Function] - [Proportion %]
├── [Part 3]: [Function] - [Proportion %]
└── [Part N]: [Function] - [Proportion %]

回答する質問：

• いくつの部分で構成されていますか？
• 各部分の役割は何ですか？
• 順序と割合はどうなっていますか？

B3：品質の特徴を抽出する

この事例が優れている理由は何ですか？

観点	質問
構成	内容はどのように整理されていますか？
スタイル	語調、語彙、表現はどうなっていますか？
テクニック	効果を高めている方法は何ですか？
論理	情報はどのように展開していますか？
詳細	小さいながらも重要な工夫は何ですか？

B4：プロセスをリバースエンジニアリングする

この出力を作成するには、どのような手順が必要かを推定します。

## Deduced Production Steps
1. [Step 1]: [What to do] - [Key point]
2. [Step 2]: [What to do] - [Key point]
...

## Key Decisions
- [Decision 1]: [Options] - [This example chose X because...]

## Reusable Techniques
- [Technique 1]: [How to apply]
- [Technique 2]: [How to apply]

B5：スキルを生成する

リバースエンジニアリングしたスキルには、次のテンプレートを使用します。

## Output Type
[What kind of artifact this produces]

## Applicable Scenarios
[When to create this type of output]

## Structure Template
1. [Part 1]: [Function] - [~X%]
2. [Part 2]: [Function] - [~X%]
...

## Quality Characteristics (Learned from Example)
- [Characteristic 1]: [How it manifests]
- [Characteristic 2]: [How it manifests]

## Production Steps
1. [Step 1]: [What to do] - [Tips]
2. [Step 2]: [What to do] - [Tips]
...

## Checklist
- [ ] [Check item 1]
- [ ] [Check item 2]

## Reference Example
- Source: [name/URL]
- Analyzed: [timestamp]

---

例：パス A（方法論ドキュメント）

ユーザー：「適切なコミットメッセージの書き方に関するこの記事からスキルを抽出してください」

プロセス：

1. 記事を読む
2. 特定する：これはハウツー形式です（手順があり、教える意図がある）
3. 抽出する：
   • 目標：明確で役立つコミットメッセージを書く
   • 手順：一般的なフォーマットを使う、タイトルと本文を分ける、など
   • 品質基準：タイトルは 50 文字未満、命令形を使う、など
4. 手順とチェックリストを含むスキルを生成する

---

例：パス B（リバースエンジニアリング）

ユーザー：「優れた技術ブログ記事を見つけました。これを参考に、同じような記事を書くためのスキルを作成してください」

プロセス：

1. 特定する：これはサンプルです（完成した成果物で、教える意図はない）
2. 構成を分析する：

   ├── Hook: Real pain point (2-3 sentences)
   ├── Problem: 3 sentences on the core issue
   ├── Solution: Conclusion first, then details
   ├── Code: Each snippet < 20 lines, with comments
   ├── Pitfalls: 3 common errors
   └── Summary: One-line takeaway
   

3. 品質特性を抽出する：
   • タイトル = 具体的な技術 + 解決した問題
   • 1 つの段落につき 1 つのアイデア
   • コードと文章の比率は約 40：60
   • 信頼性を高める個人的な体験談
4. 手順をリバースエンジニアリングする：
   • 実際に解決した問題から始める
   • まず解決策を書き、その後に設定を書く
   • コードサンプルを段階的に追加する
   • など
5. スキルを生成する：「技術ブログ記事の書き方」

---

応用：複数のサンプルからの学習

ユーザーが同じ種類のサンプルを複数提示した場合：

Example A ──┐
Example B ──┼──> Extract commonalities ──> Core methodology
Example C ──┘           │
                        ▼
                  Analyze differences ──> Style variants / Optional techniques

これにより、より堅牢で汎用性の高いスキルを作成できます。

---

重要な注意事項

1. 必ず最初に適性を確認する - すべてのコンテンツがスキル抽出に適しているわけではありません
2. 早い段階でパスを特定する - 方法論ドキュメントとサンプルでは、異なるアプローチが必要です
3. 具体的にする - 曖昧なスキルは役に立ちません。具体的な手順と基準を含めてください
4. 出典を保持する - 知識の出典を必ず明記してください
5. 明確化を求める - ユーザーの意図が不明な場合は、先に質問してください
6. 速さより品質を優先する - コンテンツを十分に理解するために時間をかけてください

このスキルに該当しないもの

• 要約ツールではありません（それは NotebookLM の役割です）
• ドキュメント変換ツールではありません
• 繰り返し実行できる実用的な方法論を抽出することが目的です