pm-skill-creator

目的

アイデアやコンテンツの段階から、リポジトリの要件に準拠した構造化済みの SKILL.md ドラフトに至るまで、スキルの設計プロセス全体を対話形式で進めます。適応型の質問を通じてスキルの種類、対象範囲、構成、内容を判断し、すぐに検証できるドラフトを生成します。

このスキルは、作り始める前に「何を」作るかを一緒に考えます。会話を通じて、アイデアやコンテンツの段階から適切な構成に整え、検証できるドラフトを生成します。

主な概念

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

• コンポーネント：1 つの成果物またはテンプレートです。単体で完結し、他のスキルから参照されます。問いかけ：「誰かが作成するものですか？」
• インタラクティブ：適応型の質問と、選択肢を列挙した提案を通じて会話を進めます。問いかけ：「役立つものにするには、やり取りが必要ですか？」
• ワークフロー：複数フェーズのオーケストレーションを行い、他のスキルを参照します。問いかけ：「複数のステップにわたる複数の活動を調整しますか？」

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

すべてのスキルに、次のセクションをこの順序で含める必要があります。

1. 目的 — 何をするか、いつ使うか（成果を重視）
2. 主な概念 — フレームワーク、定義、メンタルモデル
3. 適用方法 — エージェントが実行できる手順
4. 例 — 具体的で詳細な例を少なくとも 1 つ
5. よくある落とし穴 — 失敗パターンの名称、結果、対処法
6. 参考資料 — 関連するスキル、外部フレームワーク、出典資料

メタデータの制約

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

ファシリテーションプロトコル

次の対話プロトコルを使って、このスキルをガイド付きの会話として進行します。

• 最初に一行で概要を伝え、開始方法を提示します。ガイド付き（一度に 1 つの質問）、コンテキストの一括入力（ユーザーが最初にすべてを貼り付ける）、最善の推測（トピックだけをもとに進める）から選べます。
• 平易な言葉で、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 が Framework または Template の場合：

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

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

Q1 が Process または Workflow の場合：

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

1. はい、ワークフローです — 明確なフェーズがあり、ほかのスキルを参照することもあります
2. 会話に近いです — 適応的な質問や提案に価値があります（→ インタラクティブ）
3. 説明されたほど複雑ではありません — 実際には、手順を含む 1 つの成果物です（→ コンポーネント）」

Q1 が Coaching または Advisory の場合：

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

1. はい、インタラクティブです — 役立つものにするには、やり取りが必要です
2. リファレンスに近いです — ユーザーに必要なのはフレームワークであり、会話ではありません（→ コンポーネント）
3. 一連のプロセスです — 複数のフェーズがあり、ほかのスキルを連携させます（→ ワークフロー）」

---

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

エージェントが質問します：

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

a）仮の名前 — 小文字のケバブケースで、最大 64 文字です（例：feature-investment-advisor、user-story、discovery-process）

b）1 文の説明 — 何をするのか、いつ使うのかを記述します。200 文字以内で、動詞または『Use when...』で始める必要があります。

最善の案を教えてください。必要であれば、こちらで整えます。スキルの目的を説明していただければ、両方を提案します。」

エージェントのメモ： 続行する前に、名前の形式（ケバブケース、≤ 64 文字）と説明の長さ（≤ 200 文字）を検証します。どちらかが条件を満たさない場合は、修正案を提示します。

---

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

この質問は、Q2 で決まったスキルの種類に応じて変わります：

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

「この成果物またはフレームワークの中心となる要素は何ですか？次の情報が必要です。

1. テンプレートまたは構成 — どのようなセクションやフィールドが含まれますか？
2. 品質基準 — 良いものと悪いものを分ける基準は何ですか？
3. 具体例 1 つ — 適切に作成された記入済みの例

箇条書き、メモ書き、完成した草案など、どのような形でもかまいません。」

インタラクティブスキルの場合：

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

1. 最初の質問は何ですか？ — ユーザーはまず何を伝える必要がありますか？
2. 分岐は 2～4 通りで何ですか？ — 回答によって、その後の流れはどう変わりますか？
3. どのような提案が導かれますか？ — 提示する結果は 3～5 通りで何ですか？

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

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

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

1. 主なステップは何ですか？（通常は 3～6 フェーズです）
2. 各フェーズの入力と出力は何ですか？
3. 既存のどのスキルを参照しますか？（続行する前に、既存のスキルを検索して、このトピックをすでに扱っているものがないか確認してください。）
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. 主要な概念 — Q4の内容をもとに構成
4. 適用方法 — Q4から導き出した手順
5. 例 — Q4の具体例（提示されていない場合は生成）
6. よくある落とし穴 — Q5をもとに構成
7. 参考資料 — 会話中に特定された関連スキルとソース資料

生成後、エージェントは次のように伝えます。

「SKILL.mdのドラフトができました。完成とする前に、次の点を確認しましょう。

1. ドラフトを確認する — あなたの意図が反映されていますか？
2. フロントマターを検証する — nameとdescriptionがあり、文字数制限内であることを確認してください（nameは64文字以下のケバブケース、descriptionは200文字以下で「Use when...」というトリガーの手がかりを含むこと）。
3. 構成とトリガーを確認する — 必須セクションがすべてあり、descriptionとトリガーが実際のユーザーリクエストに一致することを確認してください。
4. 重複がないか確認する — 既存のスキルと重複していないことを確認してください。

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

例

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

Q1：「1 — フレームワークです。内製と購入の判断を評価するための2×2マトリクスです。」 Q2：「1 — はい、コンポーネントです。」 Q3：「名前：build-vs-buy-matrix。説明：『戦略的価値と実装の複雑さを軸にした2×2マトリクスを使って、内製と購入の判断を評価します。社内で構築するか、ソリューションを購入するかを選ぶときに使用します。』」 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：検証の省略

症状： 「下書きはよさそうなので、リリースしましょう。」

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

対処法： スキルが完成したと判断する前に、必ず下書きのフロントマターを検証し、必須セクションがすべてそろっていることを確認してください。例外はありません。

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

症状： 1 つのスキルに、特定の分野全体を詰め込もうとします。

結果： 何もうまくこなせない 500 行の怪物になります。範囲が広すぎて正確に起動できず、長すぎて役に立ちません。

対処法： 1 つのスキルにつき、1 つの仕事に絞ります。適用手順が 6 つを超える場合、または分岐が 4 つを超える場合は、複数のスキルが必要でしょう。