pm-skill-creator

目的

アイデアやコンテンツのたたき台から、リポジトリの規約に準拠した構造化済みの SKILL.md のドラフトまで、スキル設計の全工程を対話形式で進めます。適応型の質問でスキルの種類、範囲、構成、内容を見極めたうえで、すぐに検証できるドラフトを生成します。

このスキルは、skill-authoring-workflow を対話形式で補完するものです。前者はプロセスと検証のチェックポイントを定義します。こちらは、作り始める前に何を作るべきかを一緒に考えます。

入力

設計したいスキルのタネを用意してください。まだ形になっていなくても構いません。内容を形にするのがこのスキルの役割です。

• 特に役立つもの： スキルに反映したいアイデア、フレームワーク、または未整理のコンテンツ（メモ、プロンプトの流れ、記事など）
• あると役立つもの： 想定しているスキルの種類、対象者、関連付けたい既存のスキル

依頼にこの内容を含めると（例：「pm-skill-creatorを使ってください。北極星指標を選ぶための意思決定ツリーがあるので、スキルにまとめるのを手伝ってください」）、会話ではその内容を Q1 の回答として扱い、次の質問に進みます。同じ質問を繰り返すことはありません。入力がない場合は、スキルで何を実現したいかを尋ねるところから始めます。

例：Use pm-skill-creator: I have a decision tree for choosing north-star metrics — help me shape it into a skill.

主な概念

このスキルと他の作成ツールの使い分け

ツール	最適な用途
このスキル（skill-creator）	アイデアや未整理のコンテンツを適切な構成にまとめるため、対話形式での支援が必要な場合
skill-authoring-workflow	作るものが決まっていて、プロセスのチェックリストと検証手順が必要な場合
scripts/build-a-skill.sh	構成が決まっていて、ターミナルのウィザードで各セクションを作成したい場合
scripts/add-a-skill.sh	元になる文書があり、AI を使って最初から最後まで生成したい場合

3 種類のスキル（判断基準）

• コンポーネント： 1 つの成果物またはテンプレートです。単独で完結し、他のスキルから参照されます。問い：「誰かが作成するものですか？」
• インタラクティブ： 適応型の質問と、番号付きの推奨事項を用いたガイド付きの対話です。問い：「役立つものにするには、やり取りが必要ですか？」
• ワークフロー： 他のスキルを参照しながら複数のフェーズを調整します。問い：「複数のステップにまたがる活動を調整しますか？」

スキルの構成（必須セクション）

すべてのスキルには、次のセクションがこの順番で必要です。

1. 目的 — 何をするか、いつ使うか（成果を中心に記述）
2. 入力 — ユーザーが提示できるもの（対象、任意のコンテキスト）、呼び出し例、入力に含まれる内容は回答済みとして扱うルール。入力を促す形で記述してください。入力がなくても問題なく、ガイド付きの流れですべて確認できることを示します。平易な言葉のみを使い、$ARGUMENTS などの実行時テンプレート構文は使用しないでください
3. 主な概念 — フレームワーク、定義、メンタルモデル
4. 適用 — エージェントが実行できる手順
5. 例 — 具体的で詳細な例を少なくとも 1 つ
6. よくある落とし穴 — 名前の付いた失敗パターン、その結果、対処法
7. 参考資料 — 関連するスキル、外部フレームワーク、元資料

メタデータの制約

• name：小文字のケバブケースで、64 文字以内
• description：200 文字以内で、トリガーとなる表現（「Use when...」）を含めること
• intent：リポジトリ向けの長めの概要（文字数制限なし）
• type：component、interactive、workflow のいずれか

ファシリテーションの参照元

このスキルの標準的な対話プロトコルとして、workshop-facilitation を使用してください。

このファイルでは、次の内容を定義しています。

• セッション開始時の説明と開始モード（Guided、Context dump、Best guess）
• 平易な言葉でのプロンプトを用いた、1 回につき 1 つの質問
• 進行状況のラベル（例：Context Q1/5）
• 割り込みへの対応と一時停止／再開の動作
• 意思決定の場面での番号付きの推奨事項
• 番号付きのクイック選択肢（必要に応じて「Other (specify)」を含める）

このファイルでは、このドメインに固有の内容を定義します。内容に矛盾がある場合は、このファイルのドメイン固有の指針に従ってください。

アプリケーション

このインタラクティブスキルでは、最大5つの適応型質問を行い、その後、フロントマター、必須セクションすべて、リポジトリ準拠の構成を備えた完全な SKILL.md の草案を作成します。

---

ステップ 0：セッションの開始

エージェントが言うこと：

「新しい PM スキルを一から設計するお手伝いをします。所要時間は約10～15分で、質問は最大5つです。どのように始めますか？

1. ガイド形式 — 質問を1つずつ行い、回答をもとにスキルを作成します（おすすめ）
2. コンテキストの貼り付け — 生のコンテンツ、メモ、フレームワークを貼り付けてください。スキルの構成を提案します
3. おまかせ — トピックだけ教えてください。調整できる草案を作成します」

---

質問1：素材は何ですか？（Q1/5）

エージェントが尋ねること：

「何をスキルにしますか？手元にあるものを何でも教えてください。」

1. フレームワークまたはメンタルモデル — PM の課題に対する、体系的な考え方（例：優先順位付けマトリクス、意思決定ツリー）
2. テンプレートまたは成果物 — PM が作成する成果物（例：PRD のセクション、ポジショニングステートメント、エピック形式）
3. プロセスまたはワークフロー — PM のタスクを完了するための複数ステップの手法（例：ディスカバリースプリント、ロードマップ策定）
4. コーチングまたはアドバイスのトピック — PM がガイド付きの適応的な支援を必要とする領域（例：ステークホルダーとの調整、価格設定の判断）

または、手元にあるものを自分の言葉で説明してください。

エージェントのメモ： 選択肢を選ばずにユーザーが生のコンテンツを貼り付けた場合は、内容を分析して回答を推測します。先に進む前に、解釈が正しいか確認します。

---

質問2：スキルタイプの決定（Q2/5）

Q1 の回答をもとに、エージェントがタイプを提案して確認します：

Q1 = フレームワークまたはテンプレートの場合：

「これはコンポーネントスキルのようです。単体で完結する成果物またはリファレンスです。テンプレート、品質基準、例を含めます。これは合っていますか？それとも、会話による適応的な要素を見落としていますか？

1. はい、コンポーネントです — 単独で使える成果物またはリファレンスです
2. 実際には、会話が必要です — うまく使うには、ユーザーにガイド付きの質問をする必要があります（→ インタラクティブ）
3. 1つの成果物に収まりません — 複数のステップまたは他のスキルを統括します（→ ワークフロー）」

Q1 = プロセスまたはワークフローの場合：

「これはワークフロースキルのようです。複数のフェーズからなるプロセスです。他の個別のスキルや成果物を参照または統括しますか？それとも、ガイド付きの会話に近いですか？

1. はい、ワークフローです — 明確なフェーズがあり、他のスキルを参照する場合もあります
2. 会話に近いです — 適応的な質問や提案に価値があります（→ インタラクティブ）
3. 説明したものよりシンプルです — 実際には、ステップを含む1つの成果物です（→ コンポーネント）」

Q1 = コーチングまたはアドバイスの場合：

「これはインタラクティブスキルのようです。回答に応じて内容が変わるガイド付きの質問を行い、最後に番号付きの提案を示します。合っていますか？

1. はい、インタラクティブです — 役立てるには、双方向のやり取りが必要です
2. リファレンスに近いです — 会話ではなく、フレームワークがあれば十分です（→ コンポーネント）
3. 一連のプロセスです — 複数のフェーズがあり、他のスキルを統括します（→ ワークフロー）」

---

質問3：範囲と命名（Q3/5）

エージェントが尋ねること：

「このスキルの名前は何にしますか？2つ必要です。

a) 仮の名前 — 小文字とハイフンを使う形式で、最大64文字（例：feature-investment-advisor、user-story、discovery-process）

b) 1文の説明 — 何をするのか、いつ使うのかを説明します。200文字以内で、動詞または「次の場合に使用...」で始めてください。

まずは案を出してください。必要に応じてこちらで整えます。または、スキルの目的だけを説明していただければ、名前と説明の両方を提案します。」

エージェントのメモ： 先に進む前に、名前の形式（ケバブケース、64文字以下）と説明の長さ（200文字以下）を検証します。いずれかの条件を満たさない場合は、修正案を提示します。

---

質問 4：重要な内容（Q4/5）

Q2 のスキルタイプに応じて、この質問は変わります。

コンポーネントスキルの場合：

「この成果物またはフレームワークの核となる要素は何ですか？以下を教えてください。

1. テンプレートまたは構成 — どのようなセクションやフィールドが含まれていますか？
2. 品質基準 — 良いものと悪いものを分けるのは何ですか？
3. 具体例を1つ — うまく作成されたことがわかる記入済みの例。理想的には、異なるビジネス領域の2つ目の例も依頼するか生成してください。1つは SaaS、もう1つは産業分野または非 SaaS の例です。これにより、このスキルが暗黙のうちに「SaaS でしか使えない」と教えるのを防げます。リポジトリにある架空の世界観を使用し、2つ目のファイルにはドメインに応じた名前（sample-industrial.md）を付けてください。例に登場する企業はすべて架空のものにしてください。

箇条書き、簡単なメモ、完成版のいずれでもかまいません。」

対話型スキルの場合：

「会話の流れを説明してください。

1. 最初の質問は何ですか？ — ユーザーはまず何を伝える必要がありますか？
2. 分岐する2〜4個の経路は何ですか？ — 回答によって、その後の流れはどう変わりますか？
3. どのような推奨事項が導き出されますか？ — どのような結果を3〜5個提示しますか？

考えている決定木を教えてください。大まかなものでかまいません。」

ワークフロースキルの場合：

「各フェーズを整理してください。

1. 主なステップは何ですか？（通常は3〜6フェーズです）
2. 各フェーズの入力と出力は何ですか？
3. どの既存スキルを参照しますか？（scripts/find-a-skill.sh --keyword <topic> で確認してください）
4. 判断が必要なポイントはどこですか？

一連の流れを教えてください。順次進行、分岐、またはその両方でもかまいません。」

---

質問 5：落とし穴とエッジケース（Q5/5）

エージェントが尋ねます：

「うまく進められなかった場合、何が起きますか？失敗パターンを2〜3個教えてください。

1. 失敗に名前を付ける — ラベルを付けてください（例：「指標のごまかし」「ヒーロー症候群」）。
2. 結果を説明する — その落とし穴にはまると何が起きますか？
3. 対処法を示す — どのような修正措置を取ればよいですか？

はっきりわからない場合は、最もよく見かける間違いを教えてください。こちらで整理をお手伝いします。」

---

ドラフトの生成

Q1〜Q5 の回答を集めた後、エージェントは以下を含む完全な SKILL.md のドラフトを生成します。

1. YAML フロントマター — name、description、intent、type、best_for、scenarios、estimated_time
2. 目的 — Q1 と Q3 から要点をまとめます
3. 入力 — Q2/Q3 をもとに、ユーザーが提供する内容、呼び出し例、入力がインラインで提供された場合のルール（提供された内容を使い、再度尋ねない）を導き出します
4. 重要な概念 — Q4 の内容をもとに構成します
5. 適用方法 — Q4 から導き出した手順ごとの指示です
6. 例 — Q4 の具体例（または、提供されていない場合は生成した例）。十分な完成度の基準として、2つのドメイン（SaaS と産業分野）の例を用意します
7. よくある落とし穴 — Q5 をもとに構成します
8. 参考資料 — 会話中に特定した関連スキルとソース資料

生成後、エージェントが伝えます：

「SKILL.md のドラフトはこちらです。完了とする前に、以下を確認してください。

1. ドラフトを確認する — 意図した内容が反映されていますか？
2. 検証を実行する — python3 scripts/check-skill-metadata.py skills/<name>/SKILL.md
3. トリガーを確認する — python3 scripts/check-skill-triggers.py skills/<name>/SKILL.md --show-cases
4. スモークテストを実行する — ./scripts/test-a-skill.sh --skill <name> --smoke

修正したい点はありますか？それとも、検証に進みますか？」

例

例：フレームワーク → コンポーネントスキル

Q1: 「1 — フレームワークです。構築するか購入するかの判断を評価するための、2x2のマトリックスです。」 Q2: 「1 — はい、コンポーネントです。」 Q3: 「名前：build-vs-buy-matrix。説明：『戦略的価値と実装の複雑さを軸とした2x2のマトリックスを使って、構築するか購入するかの判断を評価します。内製するかソリューションを購入するかを選ぶ際に使用します。』」 Q4: 「軸は、戦略的差別化（低／高）と実装の複雑さ（低／高）です。4つの象限：購入（低／低）、提携（低／高）、構築（高／低）、投資（高／高）。品質基準：各象限に明確な判断ルールと例が1つずつあること。」 Q5: 「最大の間違い：一度きりの判断として扱うこと。結果：何かを構築した後に市場が変化し、差別化されていない技術の保守から抜け出せなくなります。対策：四半期ごとに見直します。」

**出力：**テンプレート、記入済みの例、四半期ごとの見直しに関する落とし穴を含む、完全なコンポーネントスキル。

---

例：アドバイザリートピック → 対話型スキル

Q1: 「4 — コーチングのトピックです。PM がリーダーシップ層との初めての価格設定に関する会話を進めるのを支援します。」 Q2: 「1 — はい、対話型です。」 Q3: 「名前：pricing-conversation-advisor。説明：『リーダーシップ層との初めての価格設定に関する会話に備えます。価格変更や新たな収益化を経営陣に提案する際に使用します。』」 Q4: 「最初の質問：価格設定の変更内容は何ですか？分岐：新製品の価格設定、既存製品の値上げ、フリーミアムから有料への移行、従量課金への移行。推奨事項：用意するデータ、異議への対応、説明の組み立て方。」 Q5: 「失敗パターン：『価格から話し始める』。結果：経営陣が戦略ではなく価格に注目してしまいます。対策：価格を明かす前に、必ずビジネス上の根拠と顧客への影響から話し始めます。」

**出力：**3つの質問からなるフロー、4つの分岐、分岐ごとに列挙された推奨事項を含む、完全な対話型スキル。

---

アンチパターン：スコープの拡大

Q1: 「ビジョン、ロードマップ、OKR、優先順位付け、ステークホルダーとの調整、指標など、プロダクト戦略全般を網羅するスキルが欲しいです。」

エージェントの応答：「それは1つではなく、4〜6個のスキルです。今、最も重要なものを1つ選んで、それを作りましょう。最も急を要するのはどれですか？

1. ビジョン → コンポーネントスキル
2. ロードマップの計画 → ワークフロースキル（既存：roadmap-planning）
3. 優先順位付け → 対話型スキル（既存：prioritization-advisor）
4. その他

まず1つから始めましょう。他のスキルはその後に作成できます。」

よくある落とし穴

落とし穴 1：タイプの混同

**症状：**実際には番号付き手順のテンプレートなのに、「ワークフロー」と呼んでしまう。

**結果：**存在しないサブスキルを参照し、ユーザーを混乱させる、過剰に設計されたスキルになります。

**対策：**Q2 のタイプ判定の質問に正直に答えます。他のスキルを連携させたり、入力と出力が異なる明確なフェーズがあったりしない場合は、おそらくコンポーネントです。

落とし穴 2：説明がトリガーにならない

**症状：**説明にスキルの内容（「価格設定の判断に使うフレームワーク」）は書かれているものの、使用する場面が書かれていない。

**結果：**Claude がユーザーのリクエストとスキルを照合できず、使われないままになります。

**対策：**すべての説明に「次の場合に使用します」という記述が必要です。例：「構造化されたフレームワークを使って価格設定の判断を評価します。価格モデルの選択や価格提案の準備をする際に使用します。」

落とし穴 3：検証を省略する

症状：「下書きはよさそうなので、このまま公開しましょう。」

**結果：**壊れたフロントマター、セクションの欠落、相互参照の不整合、カタログ内の件数の不一致が発生します。

**対策：**スキルの完成と判断する前に、必ず check-skill-metadata.py と check-skill-triggers.py を実行します。例外はありません。

落とし穴 4：何でも詰め込んだスコープ

症状： 領域全体を 1 つのスキルに詰め込もうとします。

結果： 何をさせても中途半端な、500 行の巨大なスキルになります。範囲が広すぎて正確に呼び出されず、長すぎて役に立ちません。

対策： 1 つのスキルにつき 1 つの役割にします。アプリケーションの手順が 6 つを超える場合や、分岐が 4 つを超える場合は、複数のスキルが必要である可能性が高いです。

参考資料

関連スキル

• skill-authoring-workflow — プロセスのチェックリストと検証ゲートです。このスキルでドラフトを生成した後に使用してください。
• workshop-facilitation — この対話型スキルのファシリテーションプロトコルです。

リポジトリツール

• scripts/build-a-skill.sh — セクションごとにスキルを作成するターミナルウィザード
• scripts/add-a-skill.sh — コンテンツ優先の自動スキル生成ツール
• scripts/check-skill-metadata.py — 構造の検証
• scripts/check-skill-triggers.py — トリガー準備状況の監査
• scripts/test-a-skill.sh — 品質ゲート全体
• scripts/find-a-skill.sh — 作成前に重複するスキルがないか確認

ドキュメント

• CLAUDE.md — スキルの蒸留プロトコルと品質基準のマスタードキュメント
• docs/Building PM Skills.md — 手動でスキルを作成するガイド
• docs/Add-a-Skill Utility Guide.md — 自動作成ガイド