meeting-prep

会議の準備

参加者の情報と企業の背景情報を活用して、会議の準備を行います。

ユーザーからのリクエスト：$ARGUMENTS

コマンドを実行する前に、Claude Code の制約事項について references/nimble-playbook.md を読んでください（シェルの状態、&／wait の禁止、サブエージェントの権限、コミュニケーションスタイル）。

---

手順

ステップ 0：事前確認

references/nimble-playbook.md に記載されているトランスポートの選択と標準の事前確認に従ってください。セッション開始時に CLI または MCP を選択し、標準の事前確認呼び出し（日付の計算、今日の日付、プロフィール、メモリーインデックス）を並行して実行します。

結果に応じて、次のように対応します。

• CLI が見つからない、または API キーが設定されていない場合 → references/profile-and-onboarding.md を読み、停止します
• すべての nimble CLI 呼び出しにタグを付けます：nimble --client-source nimble-agent-skills <subcommand>。MCP リクエストはトランスポートレベルで識別されます。詳細は references/nimble-playbook.md を参照してください。
• プロフィールが存在する場合 → ~/.nimble/memory/people/index.md を読んで、既存の人物プロフィールを確認します。参加者について、関連する ~/.nimble/memory/people/ ファイルを事前に読み込み、重複する検索を省いて過去の会議メモを提示します。人物ファイル内の [[path/entity]] 相互参照をたどってください。参加者のファイルから [[competitors/widgetco]] へのリンクがある場合は、その競合他社のファイルを読み込んで、より詳しい背景情報（競合他社インテリジェンスの実行による最近の情報など）を確認します。また、キャッシュされた企業リサーチがないか ~/.nimble/memory/companies/ も確認してください。 同日レポートの確認は不要です。会議の準備は日単位ではなく、会議ごとに行います。同じ日に複数の会議を準備することがあります。代わりに、エンティティ情報の鮮度を確認します。人物または企業のプロフィールが過去 24 時間以内に更新されている場合は、再利用するか確認します：「[Name] の最近のプロフィールが、本日すでにあります。これを使用しますか、それとも更新しますか？」
• プロフィールがない場合 → 問題ありません。会議の準備にオンボーディングは必要ありません。ステップ 1 に進みます。

ステップ 1：ミーティングの背景情報を収集する

$ARGUMENTS からミーティングの詳細を解析するか、ユーザーに尋ねます。

カレンダーのショートカット： ユーザーが出席者を指定しておらず、カレンダーコネクターを利用できる場合は、今日のミーティングを取得して選んでもらえるよう提案します。利用できるのは、カレンダー MCP ツール（ツール一覧で list_events を探します）または gws CLI（gws calendar +agenda --today）です。どちらも利用できない場合は、何も言わずにスキップします。

詳細が明確な場合（例：「明日、WidgetCo の Alex Kim とのミーティングに備えて」）：

• 抽出する情報：出席者名、会社名、ミーティング日時（指定されている場合）
• 簡潔に確認します：「WidgetCo の Alex Kim とのミーティング向けにブリーフィングを準備します……」

情報が一部しかない場合（例：「明日のミーティングに備えて」）：

• プレーンテキストで確認の質問を 1 つします：

  「誰と会いますか？（名前、役職、分かれば会社名も教えてください）」

人物名だけが指定された場合（例：「John Smith について調べて」）：

• その人物について調査を進めます。検索結果から会社名を推測してみます。

以下の項目を抽出します：

項目	必須	情報源
出席者名	はい	ユーザー入力またはカレンダーの予定
会社名	できれば必要	ユーザー入力または検索から推測
出席者の役職	任意	ユーザー入力またはステップ 2 で判明した情報
ミーティングの種類	必須	ユーザー入力、推測、または質問（ディスカバリー、デモ、状況確認、面接、パートナーシップ、社内）
ミーティング日時	任意	ユーザー入力
追加の背景情報	任意	ユーザーのメモ（「相手は当社製品を評価中」「取締役の紹介」など）

ミーティングの種類の判定 — ユーザーが指定していない場合は、文脈の手掛かりから推測します：

手掛かり	推測される種類
「見込み客」「デモ」「営業電話」	営業／ディスカバリー
「面接」「候補者」	面接
「取締役会」「投資家」	取締役会／投資家
「パートナー」「統合」	パートナーシップ
同僚との「状況確認」「同期」「1:1」	社内
手掛かりなし	質問する（下記参照）

手掛かりがない場合 — 「一般的な社外ミーティング」と推測してはいけません。ミーティングの種類によって、バリューポジショニングのセクションを生成するかどうかが決まるため、質問を 1 つする価値があります。AskUserQuestion を使用します：

このミーティングの目的は何ですか？

• 営業／ディスカバリー — 提案、デモ、適合性の検討
• パートナーシップ — 統合、共同販売、合弁事業
• 取締役会／投資家 — 取締役会、投資家向け報告、資金調達
• 面接 — 候補者の評価
• 一般／その他 — ネットワーキング、近況報告、または不明

回答をミーティングの種類に対応付けます。ユーザーが「一般／その他」を選んだ場合は、一般的な社外ミーティングとして扱います（バリューポジショニングのセクションはありません）。

ミーティングの種類によって、ブリーフィングの重点が変わります。具体的には、バリューポジショニングのセクション（ステップ 4.5 + ステップ 6）を生成するかどうかが決まります。バリューポジショニングが有効になる種類は、営業／ディスカバリー、パートナーシップ、取締役会／投資家です。次の種類ではスキップします：面接、社内、一般的な社外ミーティング。

ステップ 2：WSA を検出する

各出席者の会社ドメインについて、利用可能な WSA を検出します：

nimble extract:templates list --limit 100  # then filter items for "{company-domain}"

会社ごとに 1 回の検索を同時に実行します。SERP/PDP WSA に絞り込み、managed_by: "nimble" を優先し、nimble extract:templates get --extract-template-name {name} で検証します。 検出した名前とパラメーターをキャッシュします。より詳しいデータを取得できるよう、ステップ 3 で出席者エージェントに渡します。WSA が見つからない場合は、nimble search のみで続行します。

Step 3：出席者ごとの調査（サブエージェント）

エージェントプロンプトのテンプレート全文は、references/attendee-agent-prompt.md を読んでください。 サブエージェントの起動ルールは、references/nimble-playbook.md に従ってください （bypassPermissions、バッチの上限は4、Bash の明示的な指示、失敗時のフォールバック）。

まずメモリを確認してください。 各出席者について、~/.nimble/memory/people/[name-slug].md を確認します。 プロフィールが存在し、作成から30日未満であれば、既知の情報として読み込み、新しい情報に焦点を当てるようエージェントに渡します。30日を超えている場合は、全面的に更新します。

mode: "bypassPermissions" を指定して、nimble-researcher エージェント（agents/nimble-researcher.md）を起動します。出席者ごとにエージェントを1つ割り当てます。充実した調査を行えるよう、Step 2 で見つかった WSA 名を各エージェントに渡します。

重要： Nimble API のレート制限は、API キーごとに毎秒10リクエストです。各エージェントが4～5回検索するため、同時に実行するエージェントは1バッチあたり2つまでにしてください。出席者が3人以上の場合は、2人ずつバッチに分けます。

呼び出し数の見積もりとスケール実行： エージェントを起動する前に、API 呼び出しの合計数を見積もります。出席者1人あたり約5回の検索に、会社検索約4回、抽出3～5回を加えて、約（5 × N）+ 9回です。出席者が3人以上（15回以上の呼び出し）の場合は、個別のページ抽出ではなく、extract-batch を使うようエージェントに指示します。階層の選択については、references/nimble-playbook.md のスケール実行パターンを参照してください。

バッチ1（エージェント2つを同時に実行）：

• 出席者1の調査
• 出席者2の調査

バッチ2（必要な場合）：

• 出席者3の調査
• 出席者4の調査

出席者が1人の場合の最適化： 出席者が1人だけの場合は、エージェントを起動せず、メインコンテキストから直接検索します。これによりオーバーヘッドを削減できます。

フォールバック： エージェントが失敗するか、結果を返さない場合は、その検索をメインコンテキストから直接実行します。ブリーフィングに抜けがないようにしてください。

Step 3.5：不足情報の確認

次に進む前に、出席者全員について、役職と会社名が少なくとも確認できていることを確かめます。

有意義な検索結果が3件未満、または「役職不明」の出席者がいる場合：

1. --focus social を使ってフォールバック検索を直接実行します（ソーシャルプラットフォームの人物インデックスを検索するため、人物の特定に最も確実な方法です）。 nimble search --query "[Name] [Company]" --focus social --max-results 5 --search-depth lite
2. --focus social を利用できない場合は、次の方法に切り替えます。 nimble search --query "[Name]" --include-domain '["linkedin.com"]' --max-results 5 --search-depth lite
3. 名前のバリエーションを試します：「[First] [Last]」、「[Full Name] [Company] [Title if known]」

「役職不明」のままブリーフィングを提示してはいけません。まずソーシャル検索を徹底してください。フォールバックを試しても情報が見つからない場合は、「公開情報が限られているため、役職を確認できませんでした。LinkedIn の URL を尋ねることを検討してください。」と正直に記載します。

このステップでは、まだ見つかっていない出席者の LinkedIn プロフィール URL も収集してください。最終的なブリーフィングの出力と Notion での配布に役立つ重要な情報です。

ステップ 4：企業調査

会話に役立つ背景情報を得るため、参加者の企業を調査します。企業の詳細調査を簡略化したもので、全方位的に調べるのではなく、会話に役立つ情報に絞ります。

企業名の引用符での囲み方： 企業名にノイズの多い検索結果につながる一般的な単語が含まれる場合（例：「Acme Supply」、「Nova Dynamics」、「Global Industries」）、エスケープした引用符で囲みます："\"Acme Supply\" news"。代わりに、--include-domain '["[domain]"]'を検索の手がかりとして使うこともできます。

以下の Bash 呼び出しを同時に実行します。

• nimble search --query "\"[Company]\" news" --focus news --start-date "[14-days-ago]" --max-results 8 --search-depth lite
• nimble search --query "\"[Company]\" product launch OR announcement" --focus news --start-date "[14-days-ago]" --max-results 5 --search-depth lite
• nimble search --query "about" --include-domain '["[domain]"]' --max-results 3 --search-depth lite
• nimble search --query "\"[Company]\" funding OR raised OR investors" --max-results 5 --search-depth lite

ユーザーの会社プロフィールが存在する場合は、次も実行します。

• nimble search --query "[Company] [UserCompany] OR [user-domain]" --max-results 5 --search-depth lite

これにより、過去の提携、言及、共通の投資家、競合関係など、両社間に既存の関係があるかを確認できます。

ニュース検索の結果が 3 件未満の場合は、--start-dateを付けずに再試行します。

日付の検証： ブリーフィングに企業ニュースを含める際は、記事の日付だけでなく、出来事の日付（実際に何かが起きた日）が最近のものか確認します。詳しくは、references/nimble-playbook.md →「Signal Date Validation」を参照してください。スニペットに「昨年」や「第 3 四半期のころ」のような過去の表現がある場合は、最近のニュースではなく背景情報として扱います。

すでに企業を調査済みの場合（~/.nimble/memory/companies/に存在する場合）は、既存のプロフィールを読み込み、最新情報を確認するニュース検索のみを実行します。

ステップ 4.5：価値の位置づけに関する調査

会議の種類がインタビュー、社内、または一般的な社外の場合は、このステップをスキップしてください。

このステップでは、参加者の会社について調べた内容（ステップ 4）と、ユーザー自身のビジネスプロフィールを照合し、具体的な位置づけの切り口を見つけます。business-profile.json に company.name と company.domain が少なくとも含まれている場合に最も効果的です。

プロフィールがない場合は、ユーザーの会社や競合他社に関する検索（検索 2、4、5）をスキップし、一般的な調査（検索 1、3）を基に位置づけに関する知見を得てください。参加者の会社についてより詳しく知るため、ステップ 2 で見つかった WSA を活用してください。価値の位置づけセクションの内容は少なくなりますが、課題とソリューションのマッピングや技術スタックの調査は、プロフィールがなくても役立ちます。

ユーザーの営業コンテキストを ~/.nimble/business-profile.json から読み込みます。

• sales_context.key_differentiators — ユーザーの製品の独自性
• sales_context.integration_partners — ユーザーの製品が連携するツール
• sales_context.case_studies — 類似する顧客とその成果
• sales_context.common_objections — あらかじめ用意された反論への回答
• competitors — 登録されている競合他社（参加者の会社が利用しているか確認します）

プロフィールに sales_context がない場合でも、このスキルは動作します。価値の位置づけセクションでは、プロフィールで補強したデータではなく、ウェブ調査のみを利用します。最後に次のように伝えてください。「ヒント：次回、より充実した位置づけを作成するために、プロフィールに営業コンテキストを追加してください。」

以下の Bash 呼び出しを同時に実行します（利用可能なデータに応じて 3～5 件の検索を行います）。

1. nimble search --query "\"[AttendeeCompany]\" tech stack OR tools OR platform OR uses" --max-results 5 --search-depth lite → 利用しているツールやプラットフォームを特定し、integration_partners と照合します。

2. nimble search --query "\"[AttendeeCompany]\" [UserCompany] OR [user-domain]" --max-results 5 --search-depth lite → 既存の関係、言及、競合上の重複を確認します（ステップ 3 ですでに実行済みの場合はスキップします）。

3. nimble search --query "\"[AttendeeCompany]\" challenges OR pain points OR struggling OR migrating" --max-results 5 --search-depth lite → 課題の兆候を探し、ユーザーの価値提案と照合します。

4. （competitors リストがある場合）nimble search --query "\"[AttendeeCompany]\" [CompetitorName1] OR [CompetitorName2]" --max-results 5 --search-depth lite → 競合他社を利用しているか確認します。競合からの乗り換えを促す位置づけに不可欠です。

5. （case_studies に該当する業界の事例がある場合）nimble search --query "[UserCompany] [attendee-industry] case study OR customer story" --max-results 5 --search-depth lite → 参加者の業界で公開されている、参照可能な事例を探します。

検索結果から以下を抽出します。

• 利用しているツールやプラットフォーム（連携の切り口に活用）
• 課題の兆候や困難（価値のマッピングに活用）
• 競合他社の利用状況（乗り換えを促す切り口に活用）
• 既存の事例との業界の一致（社会的証明に活用）

このデータはステップ 5 の価値の位置づけセクションに直接反映されます。

ステップ 5：詳細な情報抽出

ステップ 3～4.5 の結果から、すべての結果の中で最も情報量の多い URL を 3～5 件特定します。 以下を優先してください。

• 参加者自身の LinkedIn の投稿、記事、講演
• 会議に直接関連する、会社の最近の発表
• 参加者へのインタビューや紹介記事
• 会社の概要／チームページ（参加者の役職が見つからなかった場合）
• （価値の位置づけが有効な場合）技術スタックやツールの利用状況がわかるページ
• （価値の位置づけが有効な場合）課題や移行計画に関する記事

URL ごとに Bash 呼び出しを 1 回ずつ行い、すべて同時に実行します。

nimble extract --url "https://..." --format markdown

抽出に失敗した場合は、references/nimble-playbook.md のフォールバックに従ってください。

参加者が 1 人で会社が判明している場合： 会社情報の抽出はスキップし、人物に関する URL を中心に調べます。
参加者が複数いる場合： 会社レベルの URL よりも、人物に特化した URL を優先します。

ステップ 6：ブリーフィングを作成する

出力は会議準備用ブリーフィングとして構成します。会議の種類に応じて重点を調整してください。

# Meeting Prep: [Company Name]
*[Meeting date/time if known] | Prepared [today's date]*

## Quick Take
[2-3 sentences: who you're meeting, why it matters, and the one thing to know
going in. This is the "read nothing else" paragraph.]

## Attendees

### [Name] — [Title]
**Background:** [Current role, time in position, career trajectory highlights]
**Recent Activity:** [What they've been posting, speaking about, or working on.
  Direct quotes from posts/talks when available.]
**Conversation hooks:** [2-3 specific things to reference — shared connections,
  their recent project, a post they wrote, a talk they gave]
**Notes from prior meetings:** [If exists in memory — what was discussed, their
  preferences, open items. "No prior meetings on file" if none.]

[Repeat for each attendee]

## Relationship Map
[Cross-attendee connections — shared employers, mutual connections, overlapping
  interests, organizational dynamics between attendees. Skip if single attendee.]

## Company Context
- **What they do:** [One line]
- **Size / Stage:** [Employees, funding stage, HQ]
- **Recent news:** [Top 2-3 items, dated with source]
- **Relevant to your meeting:** [How their company context connects to your
  discussion — e.g., recent product launch you might discuss, funding that
  signals growth, leadership change affecting priorities]

## Value Positioning
*[Only for sales/discovery, partnership, and board/investor meetings. Omit entirely
  for interview, internal, and general external meetings.]*

### Value Mapping
[Match their specific needs/pain points to your capabilities. Every mapping must
  be grounded in research from Step 4.5, not generic claims.
  Format: "They [specific finding with source] → Your product [specific capability]"]

### Integration Hooks
[Tools/platforms they use that your product integrates with. Only include
  integrations confirmed from research (their tech stack) AND your profile
  (integration_partners). If no overlap found, say so honestly.]

### Recommended Positioning
[2-3 sentences on how to frame your pitch for THIS specific company and person.
  Consider: their company stage, recent news, the attendee's role and priorities,
  and any competitive displacement opportunity. This is the "elevator pitch
  calibrated to this meeting" paragraph.]

### Reference Customers
[Similar companies from your case_studies that match their industry, size, or
  use case. Include the outcome/metric if available. If no matching case studies,
  omit this subsection rather than forcing a weak match.]

## Talking Points
[3-5 specific, actionable conversation starters grounded in the research.
  Not generic "ask about their priorities" — specific: "Ask about their
  migration from [old tool] to [new tool] that they announced last month."
  When value positioning is active, weave 1-2 positioning angles into the
  talking points naturally — don't make every talking point a sales pitch.]

## Watch Out For
[1-3 things to be aware of — sensitive topics (recent layoffs, bad press),
  potential awkward overlaps, information gaps you couldn't fill.]

## Sources
[Numbered list of key URLs cited in the briefing]

会議の種類に応じた調整：

種類	重視する点	ブリーフィングに追加する内容	価値の提示
営業／ディスカバリー	購買権限、課題の兆候、競合スタック	「適格性確認の兆候」セクション	はい — セクション全体
パートナーシップ	相互利益の兆候、連携の機会	「連携の機会」セクション	はい — 連携のきっかけに重点を置く
取締役会／投資家	財務状況、市場での位置付け、ポートフォリオの重複	「参照すべき主要指標」セクション	はい — 推奨する位置付けに重点を置く
面接	候補者の職歴の深さ、カルチャー面の兆候	「評価の観点」セクション	いいえ
社内	企業調査は省略し、相手の最近の仕事に重点を置く	簡易形式、企業セクションなし	いいえ
一般的な社外会議	すべての観点をバランスよく扱う	上記の標準形式	いいえ

基本ルール：

• 社外の企業や人物に関する事実の記述には、すべて出典 URL を付ける必要があります。 ユーザー自身のビジネスプロフィール（差別化要因、連携、導入事例）から得た データは、外部ソースを必要とするのではなく、プロフィールに基づくものとして 明記してください。
• 「要点」を最初に記載してください。多くの読者はそこまでしか読みません。
• 会話のポイントは、今回の会議に特化し、調査結果に基づく具体的な内容にしてください。 汎用的な会話のきっかけは決して生成しないでください。
• 人物について公開情報がない場合は、役割や経歴を推測せず、「公開情報は見つかりませんでした」と記載してください。
• メモリに過去の会議メモがある場合は、未解決の項目や継続性に関わるポイントを 目立つように提示してください。これが最も価値の高い情報です。
• 価値の提示に関する主張は、ステップ 4.5 の調査結果に基づくものにしてください。 「自社製品の強みをアピールする」といった汎用的な位置付けの助言は決して 生成しないでください。価値を結び付ける際は、参加者の企業に関する具体的な 調査結果と、ユーザーのプロフィールまたは調査から得た具体的な機能を必ず 関連付けてください。
• プロフィールに sales_context がない場合は、「価値の提示」セクションの最後に 一度だけ、次のように記載してください。「ヒント： ~/.nimble/business-profile.json でプロフィールを編集し、営業情報 （差別化要因、連携、導入事例）を追加すると、次回はより充実した位置付けができます。」

ステップ 7：メモリに保存する

すべての Write 呼び出しを同時に実行してください。

• レポート → ~/.nimble/memory/reports/meeting-prep-[company-slug]-[date].md
• 参加者ごと → ~/.nimble/memory/people/[name-slug].md （references/memory-and-distribution.md の形式を使用してください）。参加者の 勤務先（例：[[competitors/widgetco]] または [[companies/widgetco]]）や、その他に判明した関連先への [[path/entity]] 相互参照を追加してください。
• 企業プロフィール → 新しい企業データが見つかった場合は ~/.nimble/memory/companies/[company-slug].md を更新してください。調査した人物への 逆方向の相互参照（例：[[people/alex-kim]]）を追加してください。
• プロフィール → ~/.nimble/business-profile.json の last_runs.meeting-prep を更新してください（プロフィールが存在する場合のみ）。
• references/memory-and-distribution.md の Wiki 更新パターンに従ってください。 影響を受けるすべてのエンティティファイルについて index.md の行を更新し、 今回の実行内容を log.md に追記してください。

people/ に保存する人物プロフィールには、今後の会議準備で読み込めるよう、 役割、経歴、関心事、コミュニケーションスタイルなどの主要な事実を構造化して 記載してください。

ステップ 8：共有して配布する

必ず配布を提案してください。このステップを省略してはいけません。 コネクターの検出、 共有の手順、出典リンクの適用については references/memory-and-distribution.md に従ってください。

ステップ 9：フォローアップ

• 参加者についてさらに詳しく調べる → その人物に焦点を当てた追加調査
• 参加者を追加する → 会議に参加する他の人物も調査
• 「[トピック]についてはどうですか？」 → 特定の観点に絞った検索
• 「問題ありません」 → 完了
• 関連スキル： 企業を360度の視点から調査するには company-deep-dive、 競合として追跡するには competitor-intel、営業会議の前にメッセージを 比較するには competitor-positioning

---

エージェントチームモード（デュアルモード）

起動時に確認します：echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

チームモード（フラグが設定されている場合）：サブエージェントの代わりにチームメイトを起動します。各チームメイトは 1人の参加者を調査し、他の参加者とのつながりを発見した場合、他のチームメイトにメッセージを送れます。

チームメイト	担当	相互確認の対象
参加者1の調査担当	参加者1の人物および所属企業を詳細に調査	他のすべてのチームメイト（共通の勤務先、つながり）
参加者2の調査担当	参加者2の人物および所属企業を詳細に調査	他のすべてのチームメイト
[参加者ごとに追加]	...	...

参加者間のつながりを発見する方法：

1. 各チームメイトが、割り当てられた参加者を個別に調査します
2. チームメイトが、別の参加者と重複する勤務先、学校、つながりを発見した場合、そのチームメイトにメッセージを送ります：「私の担当参加者の[名前]は2019年から2022年まで[企業]に勤務していました。そちらの参加者と重複していますか？」
3. メッセージを受け取ったチームメイトが確認して返信します
4. リード（あなた）がすべての相互参照を集め、「関係マップ」セクションを作成します

この方法では、チームメイトが調査後に結果を比較するだけでなく、積極的につながりを探すため、ソロモードよりも質の高い関係マップを作成できます。

ソロモード（フラグが設定されていない場合）：ステップ3の標準的なサブエージェントフローです。

---

このスキルではないもの

• 競合のモニタリングではありません — 競合の追跡には competitor-intel を使用します
• 企業の詳細調査ではありません — 参加者を含めずに調査するには company-deep-dive を使用します
• CRMではありません — ウェブ上の情報を収集しますが、連絡先や営業案件は管理しません
• カレンダーアプリではありません — コンテキスト把握のために予定を読み取りますが、予定の管理はしません

---

エラー処理

標準のエラーテーブルについては references/nimble-playbook.md を参照してください。このスキル固有のエラー：

• 人物が見つからない： 名前の表記を変えて試します（フルネーム、名と姓、企業名を含める）。それでも 見つからない場合：「[名前]の公開情報が見つかりませんでした。役職またはLinkedInの情報を教えていただけますか？」
• 名前が曖昧： 企業名や役職の情報を添えて上位候補を提示し、確認を求めます。
• 企業の検索結果が空： その旨を記載し、参加者個人の調査結果に重点を置きます。