skill-from-masters について
Skill From Mastersは、理論だけでなく実際の事例を基にスキルを作成するワークフローです。実行可能な指示を書きたい人向けに、成功例と失敗例の収集、比較パターンの抽出、スキルのテストを案内します。
主な機能
- 01タスクと利用場面の絞り込み
- 02成功例と失敗パターンの収集
- 03有効・無効な方法の整理
- 04事例を具体的な指示に変換
- 05実例を使ったスキルのテスト
活用シーン
- 01具体的な業務向けスキルの作成
- 02実務経験を手順に整理
- 03スキルがよくある失敗を防ぐか確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ gbsoss/ skill-from-masters --skill skill-from-mastersインストール後、Claude Code で/skill-from-mastersを入力して読み込まれたか確認します。
同梱ファイルreferences/methodology-database.mdreferences/skill-taxonomy.md
詳細
熟練者から学ぶスキル
本で読んだ知識を並べたスキルではなく、実践の達人のように振る舞えるスキルを作りましょう。
核心理念
スキルは仕事をするためのものです。仕事に役立つ知識は、理論ではなく実践から生まれます。
実践の達人 vs 理論の専門家
| 実践の達人 | 理論の専門家 |
|---|---|
| 最も優れた成果を上げる人 | 本を書く人 |
| トップ営業担当者 | 営業手法の著者 |
| 顧客を感動させるカスタマーサポート担当者 | カスタマーサポートのトレーナー |
| 優秀な人材を採用する面接官 | 面接術の本の著者 |
| 相手がもっと話したくなる聞き手 | 心理カウンセリングの教授 |
私たちが探すのは実践の達人、つまり最も優れた成果を上げる人です。理論の専門家は説明を補うだけです。
本を書く人は、要約や指導が得意ですが、必ずしも最も優れた成果を上げているとは限りません。本当の達人は本を書かないことも多いですが、その事例ややり方、失敗から学んだことこそが最も価値のある情報です。
そのため:
❌ 错误:找写书的人 → 提取他们的理论 → 生成skill
✅ 正确:找做得最好的人 → 学习他们怎么做的 → 用理论辅助解释
ワークフロー
Step 1:タスクを理解して絞り込む
タスクが十分に具体的であることを確認します。範囲が広すぎるタスクでは、有効な事例を見つけられません。
絞り込む方法:
- 分野を尋ねる:このタスクはどの分野に属しますか?
- 状況を尋ねる:具体的にどのような状況で使いますか?
- 制約を尋ねる:どのような制約がありますか?
- 事例を尋ねる:実際に経験した状況を一つ説明できますか?
絞り込みの基準:
- この具体的な状況に関する実例を見つけられますか?
- 何が「うまくできている」のか、「うまくできていない」のかを判断できますか?
どちらかの答えが「いいえ」なら、さらに絞り込みます。
Step 2:事例を探す(最も重要なステップ)⚠️
ここがワークフロー全体の核心です。まず事例を探し、理論から始めないでください。
2.1 優れた事例を探す(最も優れた人はどうしているか)
重要:本を書く人ではなく、実践で最も優れた成果を上げる人を探します。
検索方法:
"[具体任务] top performer"
"[具体任务] how the best do it"
"[具体任务] real example from [top company]"
"[角色] who is the best at [任务]"
"[具体任务] interview with [practitioner]"
"[具体任务] behind the scenes"
目標:実践で優れていると広く認められた実例を3~5件見つけます。
実践の達人を見分ける手がかり:
- 具体的な成果やデータがある(「成約率がX%向上」「顧客満足度が最高」)
- 同業者から認められている(「チームのみんなが彼から学んでいる」)
- 一般論ではなく、実例の詳しい内容がある
優れた事例ごとに、次の点を記録します。
- この人は具体的にどう行動したのか?
- 一般的な人のやり方と何が違うのか?
- より優れた成果につながった具体的な工夫は何か?
2.2 失敗事例を探す(うまくできていない例)⚠️ 同じく重要
検索方法:
"[具体任务] common mistakes"
"[具体任务] what not to do"
"[具体任务] fails"
"[具体任务] I learned the hard way"
"[具体任务] before after comparison"
"why [具体任务] doesn't work"
目標:よくある失敗パターンと、実際に陥った落とし穴を見つけます。
失敗事例ごとに、次の点を記録します。
- 具体的に何を間違えたのか?
- なぜそのやり方は効果がなかったのか?
- 正しくはどうすべきなのか?
2.3 比較を探す(効果的 vs 効果的でない)
検索方法:
"[具体任务] good vs bad example"
"[具体任务] before after"
"[具体任务] do this not that"
"[具体任务] comparison"
違いを直接示してくれるため、比較は最も価値のある素材です。
事例収集の基準:
- 優れた事例を少なくとも3件見つけましたか?
- よくある失敗パターンを少なくとも5件見つけましたか?
- 効果的な方法と効果的でない方法を直接比較できる事例を見つけましたか?
- 実際の細部がわかるほど、事例は具体的ですか?
どれか一つでも答えが「いいえ」なら、引き続き検索します。
Step 3:効果的/効果的でないパターンを導き出す
理論から推論するのではなく、事例からパターンを導き出します。
導き出す方法:
-
すべての優れた事例に共通する点を挙げる
- どの事例でも何をしているのか?
- どのような共通の特徴があるのか?
- なぜその方法は効果的なのか?
-
すべての失敗事例に共通する点を挙げる
- どの事例でも何を間違えているのか?
- その間違いの根本原因は何か?
- どうすればその間違いを避けられるのか?
-
比較表を作成する
| 有效做法 | 无效做法 | 为什么 |
|----------|----------|--------|
| [具体做法A] | [对应的错误做法] | [原因] |
| [具体做法B] | [对应的错误做法] | [原因] |
| ... | ... | ... |
導き出す基準:
- 効果的な方法一つひとつに、効果的でない方法との比較がありますか?
- 「これをして、あれはしない」と一文で説明できますか?
- これらのパターンは理論上の仮説ではなく、事例に基づいていますか?
Step 4:理論で説明を補う(任意)
理論の専門家(本を書く人)が登場するのはこのステップで、あくまで補助的な役割です。
理論の役割は、実践の達人のやり方が効果的な理由を説明することであり、やり方を指示することではありません。
検索方法:
"why [有效做法] works"
"[领域] psychology behind"
"[理论专家名] explains [现象]"
理論の価値:
- 実践から導いたパターンに「なぜ」という説明を加える
- 背後にある論理をユーザーが理解するのを助ける
- 信頼性を高める
注意:
- 理論は補助であり、中心ではありません
- 理論による説明が見つからなくても問題ありません。実践の達人の事例そのものが、最良の証拠です
- 理論が実践を覆い隠さないようにします。スキルの核心は「本に何と書いてあるか」ではなく、「最も優れた成果を上げる人はどうしているか」であるべきです
Step 5:スキルを生成する
事例から導き出したパターンを、スキルの指示に変換します。
生成の原則:
-
事例を使って説明する
- すべてのルールに、具体的な「こうする」と「こうしない」の例を含めます
- 例は実例に基づくものとし、作り話にしません
-
まずやり方を説明し、その後で理由を説明する
- ユーザーがまず知りたいのは、どうすればよいかです
- 理論による説明は後に置きます
-
失敗事例と優れた事例を同じくらい重視する
- 「何をしてはいけないか」を知るほうが、「何をすべきか」を知るより実用的なことがよくあります
- 「よくある間違い」や「避けるべきこと」のセクションを設けます
-
具体性を保つ
- 抽象的な原則(「共感を示す」など)は避けます
- 具体的な方法に置き換えます(「ユーザーがXと言ったら、ZではなくYと返す」など)
skill-creatorを呼び出して生成します:
Use the Skill tool with: skill: "skill-creator:skill-creator"
次の点を確認します。
- 判断力が必要なスキルなら、
model: opusを追加する - 優れた事例と失敗事例の比較を含める
- 命令形で書く
Step 6:事例を使ってテストする
実例を使って、生成したスキルをテストします。
- 優れた事例を一つ選び、スキルが同等の品質の結果を出せるか確認する
- 失敗パターンを意図的に引き起こし、スキルがそれを回避できるか確認する
- ユーザーに自分の実際の状況で試してもらう
テストに失敗したら、Step 2に戻ってさらに事例を探します。
検索方法の比較
❌ 古いやり方(理論に偏重)
"[domain] best practices expert"
"[domain] framework methodology"
"[expert name] methodology"
"[domain] principles"
このような検索では、本の要約や学術的なフレームワーク、抽象的な原則が見つかります。どれも「本で得た知識」です。
✅ 新しいやり方(実践に偏重)
"[task] real example"
"[task] case study"
"[task] common mistakes"
"[task] what not to do"
"[task] before after"
"[task] I learned the hard way"
"how [company] does [task]"
このような検索では、実例や失敗から得た教訓、比較が見つかります。どれも「実践から得た知識」です。
品質チェックリスト
スキルを完成させる前に、次の点を確認します。
事例の品質:
- 十分な数の優れた事例(少なくとも3件)を見つけましたか?
- 十分な数の失敗事例(よくある間違いを少なくとも5件)を見つけましたか?
- 事例は理論上の仮説ではなく、実際の経験に基づいていますか?
- 実際の細部がわかるほど、事例は具体的ですか?
パターンを導き出す品質:
- 効果的な方法と効果的でない方法が、明確に対比されていますか?
- すべてのルールに「これをする」と「これはしない」の組み合わせがありますか?
- パターンは理論からの推論ではなく、事例から導き出されていますか?
スキルの品質:
- スキルに具体例が含まれ、抽象的な原則だけにとどまっていませんか?
- 失敗事例と優れた事例の両方が反映されていますか?
- 実例を使ってテストしましたか?
最終チェック:
- このスキルは「何度も経験を積んだベテラン」のようですか。それとも「たくさん本を読んだ人」のようですか?
例:従業員への気配りスキルの正しい作り方
❌ 間違ったやり方(古いワークフロー)
- "active listening methodology"を検索する
- カール・ロジャーズの三原則を見つける
- 厚生労働省の傾聴ガイドラインを見つける
- 原則を抜き出して、スキルを生成する
- 結果:スキルが学術的になり、ユーザーから「気にかけてもらえていると感じない」と言われる
✅ 正しいやり方(新しいワークフロー)
- "employee care conversation example"を検索する
- "what makes people feel heard"を検索する
- "bad listening examples"を検索する
- "therapist response good vs bad"を検索する
- 実際の会話の比較をたくさん見つける:
- ❌ 「お疲れなのですね」→ 冷淡で、オウム返しのよう
- ✅ 「どうしたのですか?最近何かあったのですか?」→ 温かく、相手に関心を示す
- パターンを導き出す:
- オウム返しをしない
- 本当の好奇心と気遣いを示す
- 表面的に共感するのではなく、具体的に質問する
- 「こう言う vs こうは言わない」の比較をたくさん含むスキルを生成する
- 結果:スキルに温かみがあり、ユーザーは気にかけてもらえていると感じる
要点
- 本を書く人ではなく、最も優れた成果を上げる人を探す — 実践の達人 > 理論の専門家
- まず事例を探し、その後で理論を見る — 理論は説明を補うだけ
- 優れた事例 + 失敗事例 — 何をしてはいけないかを知るほうが、何をすべきかを知るより実用的
- 比較に最も価値がある — 「こうする vs ああする」の比較が最も直感的
- スキルは仕事をするためのもの — 生成するのは「実践の達人」であり、「たくさん本を読んだ人」ではありません