sales-request-skill

不足しているセールススキルをリクエストまたは作成する

ユーザーが必要としているセールス、マーケティング、またはGTMの機能に、まだスキルがありません。そのスキルを追加するか、リクエストできるよう支援してください。

このスキルは、必ずGitHubで具体的なアクションを実行して終了します。

• パスA（作成）：スキルファイルを作成し、コミットしてプッシュし、sales-skills/sales に プルリクエストを作成します
• パスB（リクエスト）：必要な内容を説明する GitHub issue を sales-skills/sales に作成します
• パスC（知見の共有）：ローカルの知見を確認して個人情報を削除し、共有可能な発見が含まれるスキルごとに GitHub issue を作成します

「PR／issueの内容はこうなります」という説明だけで終わらせないでください。gh pr create または gh issue create を使って、実際に作成してください。

ステップ1：不足していることを確認する

$ARGUMENTS が指定されている場合は、それを使用してください。指定されていない場合は、「既存のスキルではカバーされていない、どのようなセールス、マーケティング、またはGTMの機能が必要ですか？」と尋ねてください。

依頼がセールス／マーケティング／GTMの領域に当てはまることを確認してください。完全に対象外の場合（例：「データベースのマイグレーションツールを作成する」）は、その旨を伝え、代わりに適切なツールを提案してください。

skills/sales-do/SKILL.md のルーティングテーブルを確認し、~/.claude/skills/ にインストールされているスキルを一覧表示して、依頼をカバーするスキルがすでに存在しないことを確認してください。近いスキルがある場合は、代わりにそのスキルを提案してください。

ユーザーに次の内容を要約して伝えてください。

• 必要なもの：一文で説明
• 最も近い既存のスキル：近いものの、要件に合わない点
• カテゴリー：該当するセクション（プロスペクティング＆パイプライン、進行中の商談、戦略＆コンテンツ、マーケティング＆GTM、リサーチ＆データ、クリエイティブ＆デザインなど）

ステップ2：パスを選ぶ

ユーザーに次のように尋ねてください。

次のどれを希望しますか？

1. スキルを作成する — 適切な構成での作成を支援し、PRを準備します
2. スキルをリクエストする — メンテナーに必要性を伝えるGitHub issueを作成します
3. 知見を共有する — インストール済みのスキルを確認して発見を集め、個人情報を削除してリポジトリに共有します

パスA：スキルを作成する

利用可能な場合は skill-creator を使用する

/skill-creator スキルが利用可能か確認してください。利用可能な場合は、作成・テスト・反復の全ワークフローを任せてください。

/skill-creator に任せる際は、次の営業分野に特化したコンテキストを提供してください。

このスキルに関するリポジトリの規約：

• 命名：営業スキルには sales-<problem>、マーケティング／GTM スキルには内容が分かる名前（例：cold-email、launch-strategy）を使用します
• 説明には、営業担当者やマーケターが実際に使う表現を含めます（「コールドメールを書く」「ディスカバリーコールの準備をする」「この反論に対処する」など）
• 説明の末尾には、次の形式の否定的なトリガーを必ず記載します：Do NOT use for X (use /alternative)
• 必須ファイルは SKILL.md のみです。内容を絞り、実用的なものにしてください
• スキルは実行前に、相手、段階、制約について確認質問をする必要があります
• スキルは /sales-do 経由で振り分けられます。ルーターがスキルを選ぶかどうかは説明フィールドで決まります

スキルの構成：

skills/<skill-name>/
├── SKILL.md        # 主な指示（必須）
├── scripts/        # 決定的な処理（データ取得、検証、フォーマット）
├── references/     # 大規模な参考資料（500 語超の API ドキュメント、データモデルなど）
├── assets/         # テンプレート、例、設定ファイル
└── evals/
    └── evals.json  # テストケース（任意。skill-creator または手動で生成）

SKILL.md 本文のパターン（このリポジトリの他のスキルに合わせてください）：

1. コンテキスト収集の手順（ユーザー固有の状況について 2～4 個の質問をする）
2. 実用的な成果物を作るための手順
3. 問題領域に関連するテンプレートやフレームワーク
4. 注意点のセクション（この領域で Claude が陥りがちな失敗を 3～5 個）
5. 出力形式に関するガイダンス
6. 関連スキルを案内する次のステップ

主な原則：

• 自明なことは書かない：Claude が知らない情報、つまり内部規約、分野固有の注意点、分かりにくいパターンに焦点を当てます
• 過度に制約しない：「常に」ではなく「通常は」を使います。状況に応じて柔軟に対応できるようにします
• スクリプト：決定的な処理（データ取得、フォーマット、検証）を伴うスキルには、scripts/ にスクリプトを含めます
• 段階的な情報開示：500 語を超える参考資料は references/ ディレクトリに移します

その後、skill-creator にワークフローを実行させてください。

skill-creator が利用できない場合

上記の規約に従い、手動でスキルを作成します。

SKILL.md を作成する

---
name: <skill-name>
description: "<What problem it solves>. Use when <trigger phrases the user would say>. Do NOT use for <X> (use /alternative)."
argument-hint: "[brief hint about expected arguments]"
license: MIT
version: 1.0.0
tags: [sales, <category>]
---

skills/ にある既存のスキルを 2～3 個読み、文体や構成を合わせてください。特に次の点に注意してください。

Description フィールド — /sales-do ルーターと Claude がスキルを使うかどうかを判断するための情報です。トリガーとなる表現を具体的に記載してください。スキルが何をするかだけでなく、いつ使うかも含めてください。

# Bad: too vague
description: "Help with sales emails"

# Good: specific triggers, covers edge cases
description: "Write and optimize cold outbound email sequences. Use when writing first-touch cold emails, building multi-step outreach sequences, A/B testing subject lines, or improving reply rates on existing campaigns."

本文 — まず質問して状況を把握するパターンに従います。出力をすぐに活用できるよう、テンプレート、フレームワーク、例を含めてください。

スキルをテストする

新しいスキルのディレクトリ内に evals/evals.json ファイルを生成し、現実的なテストケースを 2～3 個用意してください。各評価ケースには、営業担当者やマーケターが実際に言いそうなプロンプトと、良い応答の要件を説明するアサーションを記載してください。

{
  "skill_name": "<skill-name>",
  "evals": [
    {
      "id": 0,
      "prompt": "realistic user prompt a salesperson or marketer would say",
      "expected_output": "description of what a successful response looks like",
      "assertions": [
        {"name": "assertion_name", "description": "specific thing to check in the output"}
      ]
    }
  ]
}

スキルを有効にした状態で評価プロンプトを実行し、出力がアサーションを満たすことを確認してください。これは /skill-creator が使用するスキーマと同じなので、どちらの作成方法でも評価ケースを同様に利用できます。

PR を提出する

スキルファイルを作成したら、プルリクエストを提出します。以下の手順をすべて実行し、「手順はこちらです」で終わらせないでください。

1. skills/sales-do/SKILL.md を更新し、適切なルーティングテーブルに行を追加します
2. README.md を更新し、適切なカタログテーブルに行を追加します
3. ブランチを作成します：git checkout -b add-<skill-name>
4. ステージしてコミットします：git add skills/<skill-name>/ evals/ skills/sales-do/SKILL.md README.md && git commit -m "Add <skill-name> skill"
5. プッシュします：git push -u origin add-<skill-name>
6. PR を作成します：

gh pr create \
  --repo sales-skills/sales \
  --title "Add <skill-name> skill" \
  --body "$(cat <<'EOF'
## Summary
- **Problem**: <what the user is solving>
- **Category**: <which section it belongs in>
- **Example invocation**: `/<skill-name> <example prompt>`

## Files
- `skills/<skill-name>/SKILL.md` — main instructions
- `skills/sales-do/SKILL.md` — routing table updated
- `README.md` — catalog table updated
EOF
)"

完了したら、PR の URL をユーザーに返します。

パス B：スキルをリクエストする

リポジトリに GitHub のイシューを作成します。下書きを作成するだけでなく、実際に提出してください。

gh issue create \
  --repo sales-skills/sales \
  --title "Skill request: <skill-name>" \
  --body "$(cat <<'EOF'
## Problem
<What the user is trying to do, in their words>

## Category
<Which section this fits in: Prospecting, Active Deals, Strategy, Marketing, Research, Creative, etc.>

## Example use case
<A concrete scenario where this skill would help>

## Suggested trigger phrases
<2-3 phrases a salesperson or marketer might say that should route to this skill>
EOF
)"

完了したら、イシューの URL をユーザーに返します。

パス C：知見を共有する

ユーザーが API の癖、料金の変更、回避策、注意点などを発見するたびに、インストール済みの各スキルにある references/learnings.md ファイルに知見が蓄積されます。このパスでは、それらのファイルをスキャンして個人情報を取り除き、GitHub のイシューを作成することで、個々の発見をすべてのユーザーに役立つスキルへ反映します。

ステップ C1 — インストール済みスキルをスキャンする

すべての知見ファイルを探します。

find ~/.claude/skills/*/references/learnings.md 2>/dev/null

各ファイルを読み取ります。以下はスキップします。

• 初期テンプレート以外に内容がない空のひな形
• 共有済み（）または共有を辞退済み（）とマークされた項目

ユーザーが特定のスキルまたはプラットフォームについて言及した場合（例：「Apollo の注意点をいくつか見つけました」）、それを認識したうえで、そのスキルの知見とほかに見つかった知見をあわせてスキャンすることを伝えます。

インストール済みスキル全体を通じて未共有の知見が見つからなかった場合は、ユーザーに次のように伝えます。

未共有の知見は見つかりませんでした。スキルを使うと、知見は自動的に蓄積されます。API の癖、回避策、注意点などを見つけると、各スキルの references/learnings.md に追記されます。スキルをしばらく使ってから、またお試しください。

何も見つからなければ、ここで終了します。

ステップ C2 — 提示して分類する

未共有の知見がある各スキルについて、次の表を提示します。

#	知見	一般化可能？	理由
1	...	はい／いいえ	...

一般化可能（共有するもの）：

• API の癖、ドキュメントに記載されていない動作、エンドポイントの変更
• ドキュメントに反映されていない料金変更や制限
• プラットフォームのバグに対する回避策
• 設定上の注意点や、直感的でない既定値
• ツール間の連携に関する問題
• レート制限、スロットリング、クォータの詳細

一般化できない（スキップするもの）：

• 企業名、チーム構成、社内ワークフロー
• 個人の好みや、組織固有のカスタムフィールド
• 1 つの組織に固有の内部ツール設定
• アカウント固有の交渉済み料金や契約

作業を続ける前に、分類を確認するか、変更するかユーザーに尋ねます。

ステップ C3 — 個人情報を取り除く

一般化可能な知見ごとに、個人を特定できる情報を検索して置き換えます。

検索対象	置換後
企業名またはドメイン名	[Company]、[domain]
人名	[Name]
メールアドレス	[email]
GitHub／SNS のハンドル名	[handle]
アカウント、API、ワークスペースの ID	[account-id]
内部 URL または IP アドレス	[internal-url]
交渉済みまたは非公開の料金	完全に削除する（公開されている料金情報のみ残す）
顧客名	[customer]
特定のチーム名	[team]（「Sales」「Marketing」「Engineering」などの一般的な名称は残す）

個人情報を取り除いた知見ごとに、取り除く前と後を表示し、作業を続ける前に、置き換え後の内容に問題がないかユーザーに確認します。

ステップ C4 — レビュー用の GitHub issue を開く

スキルごとに issue を 1 件作成します（焦点を絞り、個別にマージできるようにします）。自動送信せず、事前入力済みの issue をブラウザーで開いて、ユーザーが確認できるようにします。

共有可能な学びがあるスキルごとに、GitHub issue の URL を作成します。

• タイトル：Learnings: sales-{skill-name}
• ラベル：learnings
• 本文：サニタイズ済みの学びを、コピーしてすぐに使える形式でそれぞれ記載し、スキルのバージョンと提出方法に関する背景も加えます

タイトル、本文、ラベルを URL エンコードして、GitHub の新規 issue 作成用 URL に含めます。

https://github.com/sales-skills/sales/issues/new?title=...&body=...&labels=learnings

各 URL をブラウザーで開きます。

import subprocess
subprocess.run(['open', '-na', 'Google Chrome', '--args', '--profile-directory=Profile 6', url])

学びについては、gh issue create で自動送信しないでください。公開する前に、サニタイズ済みの内容をユーザーが確認する必要があります。

ステップ C5 — 処理済みとしてマークする

ユーザーが issue の送信を確認した後、レビュー済みの学びすべてに次のマークを付けます。

• 共有済み：ユーザーが送信した学びに `` を追記します
• 見送り：ユーザーが一般化できないと判断した学び、または共有しないことを選んだ学びに `` を追記します

これにより、今後の実行時に同じ学びについて再度確認することを防げます。

品質チェックリスト

新しいスキルを提出する前に（PR または skill-creator 経由で）、次の項目を確認します。

• 名前がリポジトリの規約に従っている（営業向けは sales-<problem>、マーケティング／GTM 向けは内容がわかる名前）
• 説明に、ユーザーが実際に使いそうな具体的なトリガーフレーズが含まれている
• 説明の末尾に否定的なトリガーがある：「X には使用しないでください（/alternative を使用）」
• フロントマターに license: MIT と metadata: { author, version } が含まれている
• SKILL.md で、出力を作成する前に確認の質問をするよう指示している
• 出力が実践的で、実行に移せる内容であり、一般論にとどまっていない
• この分野で Claude がよく失敗する点を 3〜5 個記載した ## Gotchas セクションが含まれている
• 当たり前のことを書かず、Claude が知らない可能性のある情報に焦点を当てている
• 過度に制約していない。「常に」ではなく「通常は」を使い、Claude に柔軟性を持たせている
• 500 語を超える参考資料を references/ ディレクトリに移している
• データ取得、書式設定、検証などの決定的な処理には scripts/ 内のスクリプトを使用している
• sales-do/SKILL.md のルーティング表に新しい行を追加している
• README.md のカタログ表に新しい行を追加している
• evals/evals.json が生成されており、skill-creator のスキーマに沿った現実的なテストケースが 2〜3 件含まれている
• 該当する場合、関連するスキルへのリンクがある

例

例 1：不足しているスキルを最初から最後まで作成する

ユーザーの発言：「四半期ごとのビジネスレビューを作成するスキルがあるべきです。既存のスキルには対応するものがありません。作成できますか？」

スキルの動作：

1. 不足を確認します（ステップ 1）：skills/sales-do/SKILL.md のルーティング表と ~/.claude/skills/ を確認し、QBR スキルがないことを見つけて、必要性、最も近い既存スキル、カテゴリ（戦略とコンテンツ）をまとめます。
2. 3 つの方法を提示します（ステップ 2）。ユーザーは「作成」を選びます。
3. 利用可能な場合は /skill-creator に委任し、リポジトリの規約（命名、否定的なトリガーを含む説明、質問を先にする本文、Gotchas セクション）を伝えます。
4. skills/qbr-prep/SKILL.md と、現実的なテストケースを 2〜3 件含む evals/evals.json を作成し、テストを実行します。
5. skills/sales-do/SKILL.md と README.md を更新し、ブランチを作成してコミット、プッシュした後、sales-skills/sales に対して gh pr create を実行します。

結果：新しいスキルのディレクトリ、テストに合格した eval ファイル、更新済みのルーティング表とカタログ表が作成され、ライブのプルリクエスト URL がユーザーに返されます。

例 2：今すぐには作成できないスキルをリクエストする

ユーザーの発言：「チャネルパートナーとの共同販売案件を管理するスキルが欲しいのですが、作成する時間がありません。」

スキルの動作：

1. 不足を確認し、営業／マーケティング／GTM の領域に適合することを検証します。
2. ユーザーは「リクエスト」（方法 B）を選びます。
3. 問題の説明、カテゴリ、使用例、推奨するトリガーフレーズ 2〜3 件を記載して、sales-skills/sales で gh issue create を実行します。

結果：GitHub issue が作成され、その URL が返されます。チャット内にドラフトが残ることはありません。

例 3: スキルの使用中に得た知見を共有する

ユーザーの発言: 「見込み顧客の開拓中に Apollo のレート制限に関する注意点が分かったので、上流に共有してください。」

スキルの動作:

1. ~/.claude/skills/*/references/learnings.md をスキャンし、空のスタブと、すでに または のマーカーが付いた項目はスキップします。
2. 各知見を「一般化可能？」の表に表示し、分類をユーザーに確認します。
3. PII（企業名、メールアドレス、アカウント ID、交渉済みの価格）を削除し、承認用に変更前と変更後を表示します。
4. スキルごとに URL エンコードされた GitHub の新規 Issue 作成リンクを作成し、レビュー用にブラウザーで開きます。gh による自動送信は行いません。
5. ユーザーが送信を確認した後、処理した各知見に または を追記します。

結果: スキルごとに、内容の秘匿処理が済んだレビュー可能な Issue が 1 件作成され、ローカルの知見には再度確認を求められないようマーカーが付けられます。

トラブルシューティング

スキルが、最初に不足点を確認せずに作成を提案し続ける

原因: ステップ 1（不足点の確認）がスキップされたため、既存のスキルで依頼を十分に満たせるにもかかわらず、重複したスキルが提案されている可能性があります。

解決策: 選択肢を提示する前に、必ず skills/sales-do/SKILL.md のルーティングテーブルと、~/.claude/skills/ にインストールされているスキルを確認してください。近いものがあれば、新しいスキルを作成する代わりに、そのスキルを提案してください。

gh pr create または gh issue create が認証または権限エラーで失敗する

原因: gh CLI が認証されていないか、ユーザーに sales-skills/sales へのプッシュ権限がありません。

解決策: gh auth status を実行してログイン状態を確認してください。認証されていない場合は、gh auth login を実行するようユーザーに促してください。上流リポジトリにプッシュできない場合は、フォークを作成してブランチをフォークにプッシュし、そこから PR を作成してください。または、リクエストを確実に記録するために、パス B（Issue を作成する）に切り替えてください。

「知見の共有」で何も見つからない、またはすでに共有済みの項目が表示される

原因: すべての知見ファイルが空のスタブであるか、項目にすでに / マーカーが付いているため、スキャン時に意図的にスキップされています。

解決策: これは想定どおりです。スキルの使用に伴って知見が蓄積されることをユーザーに伝え、後で再度試すよう案内してください。マーカー付きの項目を再共有してはいけません。以前共有を見送った知見が一般化可能になった場合は、スキャンを再実行する前に、そのマーカーを手動で削除してください。

関連するスキル

• /sales-do — どのスキルを使えばよいか分からない場合は、ルーターがあらゆる営業目標に合ったスキルを選びます。インストール: npx skills add sales-skills/sales --skill sales-do