healthcare-providers-enrich

Healthcare Providers Enrich

Nimble のウェブデータ API を活用し、検証済みのウェブデータで既存の医療従事者リストの不足情報を補完します。

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

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

---

手順

Step 0：事前確認 + WSA の検出

関連スキルからの引き継ぎ確認： 事前確認全体を実行する前に、references/nimble-playbook.md の関連スキルからの引き継ぎパターンに従い、このセッション内で先に healthcare-providers-extract が実行されたか確認してください。同日付の抽出結果が存在する場合は、CLI の確認とプロフィールの読み込みを省略し、WSA の Layer 1／3 のインベントリを再利用します。専門分野が変わった場合に限り、Layer 2 を再実行してください。

それ以外の場合は、事前確認全体を実行します。 references/nimble-playbook.md に従って、Bash 呼び出しを同時に 5 回実行します（日付計算、今日の日付、CLI の確認、プロフィールの読み込み、index.md の読み込み）。

同時に、WSA の検出とセットアップも実行します。

• mkdir -p ~/.nimble/memory/{reports,healthcare-providers-enrich/checkpoints}
• ls ~/.nimble/memory/healthcare-providers-enrich/checkpoints/ 2>/dev/null
• references/wsa-reference.md に従って、Layer 1（分野）と Layer 3（汎用ツール）の WSA 検出を実行します。Layer 2（セッション固有）は、ユーザーの専門分野がわかる Step 1 の後に実行します。

検出したエージェントをフェーズごとに分類し、references/wsa-reference.md に従って nimble extract:templates get で検証します。

事前確認の結果に基づいて、以下を行います。

• CLI が見つからない、または API キーが設定されていない場合は、references/profile-and-onboarding.md を参照し、停止します。
• すべての nimble CLI 呼び出しにタグを付けます：nimble --client-source nimble-agent-skills <subcommand>。MCP リクエストはトランスポートレベルで識別されます。詳細は references/nimble-playbook.md を参照してください。
• プロフィールが存在する場合は、コンテキストとして記録します。references/nimble-playbook.md のスマート日付ウィンドウ方式を使用して、モードを判定します。
  • フルモード： 初回実行、または前回の実行から 14 日を超えている場合
  • クイックリフレッシュ： 前回の実行から 14 日未満の場合（不足情報があるレコードのみ再エンリッチ）
  • 同日再実行： last_runs.healthcare-providers-enrich が今日の日付の場合、~/.nimble/memory/reports/healthcare-providers-enrich-*[today].md に既存のレポートがあるか確認します。 見つかった場合は、「本日すでに実行済みです。最新データを取得するためにもう一度実行しますか？」と尋ねます。
• プロフィールがなくても問題ありません。このスキルではオンボーディングは不要です。Step 1 に進みます。

Step 1：入力の解析 + 最初の質問

抽出からの連続実行を簡略化： 同日付の抽出レポートを確認します。

ls ~/.nimble/memory/reports/healthcare-providers-extract-*$(date +%Y-%m-%d).md 2>/dev/null

同日付のレポートが存在する場合は、ファイル名から {slug} を解析し、~/.nimble/memory/healthcare-providers-extract/{slug}/providers.json を読み込みます。診療所のドメインとページ URL のパターンはすでに判明しているため、サイトの URL 規則から個別の略歴ページ URL を組み立て、Step 3 全体を省略します。これにより、不要なウェブ検索を大量に行わずに済みます。同日付のレポートがない場合、古い providers.json ファイルは再利用しないでください。

references/nimble-playbook.md の入力解析パターンを使って、入力の種類を $ARGUMENTS から解析します。主な振り分けは以下のとおりです。

• 抽出結果を検出した場合（providers.json）→ Step 2 に進み、Step 3 を省略すると記録します
• CSV／シート／貼り付けられたデータを検出した場合 → Step 2 に進みます
• 不明確な場合 → 質問します（最大 2 回の質問のうち 1 回として数えます）

入力が明確な場合は確認し、条件を絞る質問を 1 つ尋ねます（プレーンテキストで、AskUserQuestion は使用しません）。

「リストから N 人の医療従事者が見つかりました。確認させてください。

1. どの項目を補完しますか？（連絡先情報、資格、専門分野、レビュー、規制関連、または不足項目すべて）
2. 医療分野は何ですか？（眼科、歯科、皮膚科、一般、その他）」

入力が曖昧な場合は、AskUserQuestion を使用します（最大 2 回の質問のうち 1 回として数えます）。

どの医療従事者リストをエンリッチしますか？

• 医療従事者のデータを直接貼り付ける（氏名 + 判明している情報、1 行につき 1 人）
• CSV ファイルのパスまたは Google Sheet の URL を指定する
• または、手元にある情報を説明する（例：「氏名と州名だけがわかっている眼科医 50 人のリスト」）

ユーザーが最初のメッセージですでに回答している質問は省略してください。

Step 2: 既存データを分析する

入力を構造化レコードに解析します。各プロバイダーについて、以下を特定します。

• 既知のフィールド — ユーザーがすでに持っている情報（名前、州、専門分野など）
• 不足しているフィールド — references/provider-extraction-patterns.md にある5つのコアフィールド（名前、資格、専門分野、連絡先、学歴）に照らした不足情報
• 補完対象 — ユーザーがリクエストした追加フィールド（レビュー、規制情報、認定）

早期終了 — 不足なし： すべてのプロバイダーの信頼度がすでに高い（5/5フィールド）場合は、Step 5（WSAによる補完）に進むか、次のように報告します。「すべてのプロバイダーのプロフィールはすでに完成しています。代わりに、補足データ（レビュー、臨床試験、認定）を追加しますか？」

不足項目の分析概要を作成します。

「N人のプロバイダーを分析しています：

• 名前：N/N件あり
• 資格：N/N件あり（N件不足）
• 専門分野：N/N件あり（N件不足）
• 連絡先情報：N/N件あり（N件不足）
• 学歴：N/N件あり（N件不足）

不足があるN人のプロバイダーの情報補完を開始します……」

専門分野が判明したので、ここで Layer 2 WSA discovery を実行します。

nimble extract:templates list --limit 50  # filter items for "[specialty]"
nimble extract:templates list --limit 50  # filter items for "[directory-user-mentioned]"

セッションごとのディスカバリーについては、references/wsa-reference.md を参照してください。

Step 3: プロバイダーの本人確認をウェブ検索する

不足がある各プロバイダーについて、所属医療機関のウェブサイトと略歴ページを探します。

nimble search --query "[provider name] [credentials] [location] [specialty]" --max-results 5 --search-depth lite

検索戦略：

• 一般的な名前を区別できるよう、既知のフィールドをすべてクエリに含めます
• ディレクトリの掲載情報より、医療機関のウェブサイトの検索結果を優先します
• プロバイダーの所属医療機関名がわかっている場合は、クエリに追加します
• 名前と州しかわからないプロバイダーの場合は、検索範囲を広げて "[name] [state] doctor" とします

結果の選択： 最も関連性の高い結果を選びます。医療機関の略歴ページ > 医療ディレクトリのプロフィール > LinkedIn の順です。抽出用に選択した URL を保存します。

プロバイダーが10人以上の場合は、サブエージェントを使用します（以下の「サブエージェント戦略」を参照）。

チェックポイント（必須）： 先に進む前に、必ずチェックポイントファイルを書き込んでください。プロバイダーが20人以上の場合、中断された実行を再開できないと大量の API クレジットを浪費します。

echo '{...}' > ~/.nimble/memory/healthcare-providers-enrich/checkpoints/{slug}/search.json

Step 4: 不足しているフィールドを抽出する

プロバイダーの人数に応じて、抽出戦略を選択します。references/nimble-playbook.md の Scaled Execution パターンに従ってください。このパターンでは、個別呼び出し（1～10人）、extract-batch（11～100人）、および大規模ジョブ向けの確認ゲートについて説明しています。ガベージ検出と再試行ロジックには、同じリファレンスの Page Extraction with Retry パターンを使用してください。

references/provider-extraction-patterns.md の検出パターン（資格の正規表現、専門分野のキーワード、連絡先のパターン、学歴に関する記載）を使い、抽出したコンテンツから不足しているフィールドを解析します。

マージルール：

• 実際に不足しているフィールドのみを補完します。既存データは上書きしません
• 追加したフィールドとそのソース URL を記録します
• 抽出データが既存データと矛盾する場合は、既存の値を維持し、ユーザーによる確認が必要な矛盾としてフラグを付けます

チェックポイント（必須）： 先に進む前に、必ずチェックポイントファイルを書き込んでください。

echo '{...}' > ~/.nimble/memory/healthcare-providers-enrich/checkpoints/{slug}/extraction.json

Step 5: WSA による情報補完（任意）

ユーザーがレビュー、規制データ、認定をリクエストした場合、または不足項目の分析からコアフィールドの大半がすでに入力済みで、補完によってさらに価値が加わるとわかった場合：

Step 0 で特定した enrichment-phase WSA を実行します。補完フェーズのマッピング、エージェントの評価、フォールバックチェーンについては、references/wsa-reference.md を参照してください。

各医療機関またはプロバイダーについて、関連する補完エージェントを同時に実行します。バッチ処理については、references/nimble-playbook.md の Scaled Execution パターンに従ってください。

補完データをプロバイダーレコードにマージします。

• レビュー／評価 -> 補足フィールドとして追加します（コア5フィールドには含めません）
• 臨床試験の活動状況 -> 補足フィールドとして追加します
• 認定状況 -> 補足フィールドとして追加します

ステップ 6：重複排除と信頼度スコアリング

references/nimble-playbook.md に記載されている、エンティティの重複排除とエンティティの信頼度スコアリングのパターンに従います。スキル固有の重複排除ルールと、5 項目の信頼度基準は references/provider-extraction-patterns.md に記載されています。

エンリッチメント固有の信頼度： 新たに追加されたフィールドのみをスコアリングします。

• 高 — 2 つ以上のソースでフィールドが見つかり、確認できた
• 中 — 1 つのソースでフィールドが見つかった
• 低 — フィールドが推測された、または一部しか一致していない

ステップ 7：出力

エンリッチメントの差分として結果を提示し、各医療提供者に追加された内容を示します。診療科ごとにまとめ、各グループ内では信頼度順に並べ、最後に実行可能な次のステップを記載した「これが意味すること」セクションを含めます。

# Provider Enrichment: [N] Providers Updated
*[Date] | [A] fields added across [P] providers | [H] High, [M] Medium, [L] Low confidence*

## TL;DR
Enriched [P] of [T] providers. Added [A] total fields: [breakdown by field type].
[Key finding: e.g., "Found contact info for 18 of 20 providers, 3 have clinical trials"].

## Enrichment Results

| # | Name | Added Fields | Confidence | Source |
|---|------|-------------|------------|--------|
| 1 | Dr. Jane Smith | +credentials (MD, FACS), +contact ((555) 123-4567) | High | [source](url) |
| 2 | Dr. John Doe | +specialty (General Ophthalmology), +education (Wills Eye) | Medium | [source](url) |
| 3 | Dr. Alex Chen | +contact ((555) 987-6543) | Low | [source](url) |

## Detailed Records

### Dr. Jane Smith
**Existing:** Name, State (TX)
**Added:**
- Credentials: MD, FACS — [source](url)
- Contact: (555) 123-4567 — [source](url)
- Education: Fellowship, Bascom Palmer Eye Institute — [source](url)
**Confidence:** High (3 fields added, 2 sources)

[Repeat per provider with additions]

## Providers Not Enriched
[List providers where no additional data was found, with attempted searches]

## Data Quality Summary
- **Fully enriched (5/5 fields):** [N] providers
- **Partially enriched:** [N] providers — common gaps: [list]
- **No new data found:** [N] providers

## Sources
[Clickable URL for every page used, grouped by provider]

## What This Means
[Actionable interpretation: which providers are ready to contact, which need more
data, what the enrichment coverage tells you about this list's quality]

ソースへのリンクは必須です。 追加されたフィールドはすべて、ソース URL までたどれるようにしてください。

ステップ 8：メモリに保存

すべての Write 呼び出しを同時に実行します。

• レポート -> ~/.nimble/memory/reports/healthcare-providers-enrich-{slug}-{date}.md
• エンリッチ済みデータ -> ~/.nimble/memory/healthcare-providers-enrich/{slug}/enriched.json
• プロフィール -> ~/.nimble/business-profile.json の last_runs.healthcare-providers-enrich を更新（プロフィールが存在する場合のみ）
• references/memory-and-distribution.md の wiki 更新パターンに従い、影響を受けるすべてのエンティティファイルの index.md の行を更新し、この実行のエントリを log.md に追記します。
• チェックポイントをクリーンアップする（実行完了時）か、保持する（実行が部分的な場合）

ステップ 9：共有と配布

配布は必ず提案してください。省略しないでください。 コネクターの検出と共有フローについては、references/memory-and-distribution.md に従います。

Notion：エンリッチメントレポート全体を、日付付きのサブページとして共有します。 Slack：エンリッチメントの概要とフィールド数のみを含む TL;DR を共有します。

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

• 「Dr. X について詳しく教えて」 -> エンリッチ済みプロフィール全体を表示
• 「CSV にエクスポート」 -> 元のフィールドとエンリッチ済みフィールドを含む CSV を生成
• 「さらにフィールドをエンリッチ」 -> 対象フィールドを拡張して再実行
• 「まだ情報が不足している医療提供者は誰？」 -> 不完全なレコードに絞り込む

関連スキルの提案：

次のステップ：

• healthcare-providers-verify を実行して、エンリッチ済みの資格情報とライセンス状況を検証します。
• healthcare-providers-extract を実行して、診療所のウェブサイトからさらに医療提供者を見つけます。
• market-finder を実行して、この地域の診療所をさらに探します。

---

サブエージェント戦略

10 件以上の医療提供者を一括でエンリッチする場合は、nimble-researcher エージェント（agents/nimble-researcher.md）を使って検索と抽出を並列化します。

references/nimble-playbook.md のサブエージェント起動ルール（bypassPermissions、最大 4 件のバッチ、明示的な Bash の指示、失敗時のフォールバック）に従います。

起動パターン： 医療提供者 5 件ごとに 1 つのエージェントを起動します。各エージェントは割り当てられた医療提供者に対してステップ 3～4 を実行し、エンリッチ済みレコードを返します。各エージェントには、個別の nimble extract 呼び出しではなく、割り当てられた URL に対して nimble extract-batch を使うよう指示してください。エージェントごとに 1 回のバッチ呼び出しを行うほうが、逐次呼び出しより高速で信頼性が高くなります。

小規模バッチの最適化： 医療提供者が 10 件未満の場合は、エージェントを起動せず、メインコンテキストから直接実行します。

フォールバック： エージェントが失敗した場合は、そのエンリッチメントをメインコンテキストから直接実行します。出力に不足が残らないようにしてください。

---

エラー処理

標準のエラーテーブル（API キーの欠落、429、401、結果が空、抽出結果がゴミデータ）については、references/nimble-playbook.md を参照してください。このスキル固有のエラーは次のとおりです。

• プロバイダーの検索結果がない場合：「[state] で [name] のウェブ上の情報が見つかりませんでした。名前が一般的すぎるか、プロバイダーがオンライン上に情報を掲載していない可能性があります。追加の情報（クリニック名、専門分野など）を使って試してみますか？」
• プロバイダーの候補が複数ある場合：「[state] で [name] という名前のプロバイダーが複数見つかりました。どのプロバイダーか確認していただけますか？ [クリニック名とともに上位3件を一覧表示]」
• 抽出結果がすべてゴミデータの場合：「プロバイダーのウェブサイトは、JavaScript によるレンダリングが多用されているようです。ブラウザーでレンダリングして再試行します……」（共通パターンに従って --render を指定し、自動再試行します）
• CSV／Sheet の解析エラー：「入力ファイルを解析できませんでした。プロバイダー名と、少なくとも1つの識別情報（州、専門分野、またはクリニック名）を含む列が必要です。代わりにデータを直接貼り付けていただけますか？」
• **不足が検出されない場合：**ステップ2で処理します（WSA による情報補完またはレポート作成に早期移行します）。