healthcare-providers-verify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Healthcare Providers Verify

医疗从业者资质验证

Validate practitioner credentials against the NPI registry and authoritative sources, powered by Nimble's web data APIs.

User request: $ARGUMENTS

Before running any commands, read

references/nimble-playbook.md

for Claude Code constraints (no shell state, no

wait

, sub-agent permissions, communication style).

基于Nimble网络数据API，针对NPI注册表及权威来源验证从业者资质。

用户请求：$ARGUMENTS

运行任何命令前，请阅读

references/nimble-playbook.md

了解Claude Code的限制条件（无shell状态、禁止使用

wait

、子Agent权限、沟通风格）。

Instructions

操作说明

Step 0: Preflight + WSA Discovery

步骤0：预检 + WSA发现

Sibling handoff check: Before running full preflight, check if

healthcare-providers-extract

healthcare-providers-enrich

ran earlier in this session by following the Sibling Handoff pattern from

references/nimble-playbook.md

. If same-day output exists, skip CLI check and profile load, and reuse WSA Layer 1/3 inventory. Only re-run Layer 2 if the verification focus changed.

Otherwise, run full preflight from

references/nimble-playbook.md

(5 simultaneous Bash calls: date calc, today, CLI check, profile load, index.md load).

Also simultaneously — run WSA discovery and setup:

mkdir -p ~/.nimble/memory/{reports,healthcare-providers-verify/checkpoints}

ls ~/.nimble/memory/healthcare-providers-verify/checkpoints/ 2>/dev/null

Run Layer 1 (vertical) and Layer 3 (general tools) WSA discovery from
```
references/wsa-reference.md
```
. Layer 2 (session-specific) runs after Step 1 when you know the user's specialty and verification focus.

Classify discovered agents into verification categories and validate with

nimble agent get

per

references/wsa-reference.md

From the preflight results:

CLI missing or API key unset ->
```
references/profile-and-onboarding.md
```
, stop
Profile exists -> note it for context. Determine mode using smart date windowing from
```
references/nimble-playbook.md
```
:
- Full mode: first run OR last run > 14 days ago
- Quick refresh: last run < 14 days ago (re-verify only previously Unverified/Flagged practitioners)
- Same-day repeat: if
```
last_runs.healthcare-providers-verify
```
  is today, check for existing report at
```
~/.nimble/memory/reports/healthcare-providers-verify-*[today].md
```
  . If found, ask: "Already ran today. Run again for fresh data?"
No profile -> that's fine. This skill doesn't require onboarding. Proceed to Step 1.

兄弟工具交接检查：在执行完整预检前，请按照

references/nimble-playbook.md

中的兄弟工具交接模式，检查本次会话中是否已运行过

healthcare-providers-extract

或

healthcare-providers-enrich

。如果存在当日输出，则跳过CLI检查和配置文件加载，直接复用WSA第1/3层资源清单。仅当验证重点发生变化时，才重新运行第2层。

否则，执行完整预检：按照

references/nimble-playbook.md

中的要求执行（同时调用5个Bash命令：日期计算、当日日期、CLI检查、配置文件加载、index.md加载）。

同时，执行WSA发现和设置：

mkdir -p ~/.nimble/memory/{reports,healthcare-providers-verify/checkpoints}

ls ~/.nimble/memory/healthcare-providers-verify/checkpoints/ 2>/dev/null

根据
```
references/wsa-reference.md
```
运行第1层（垂直领域）和第3层（通用工具）WSA发现。第2层（会话专属）将在步骤1之后运行，届时你将了解用户的专业领域和验证重点。

将发现的Agent分类到验证类别，并按照

references/wsa-reference.md

使用

nimble agent get

进行验证。

根据预检结果：

CLI缺失或API密钥未设置 -> 参考
```
references/profile-and-onboarding.md
```
，停止操作
配置文件存在 -> 记录上下文信息。根据
```
references/nimble-playbook.md
```
中的智能日期窗口确定模式：
- 完整模式：首次运行或上次运行距今超过14天
- 快速刷新模式：上次运行距今不足14天（仅重新验证之前标记为未验证/已标记的从业者）
- 当日重复运行：如果
```
last_runs.healthcare-providers-verify
```
  为今日，检查
```
~/.nimble/memory/reports/healthcare-providers-verify-*[today].md
```
  是否存在现有报告。如果存在，询问：“今日已运行过该工具。是否重新运行以获取最新数据？”
无配置文件 -> 无需担心。本技能无需完成入职流程，继续执行步骤1。

Step 1: Parse Input + Starting Questions

步骤1：解析输入 + 初始问题

Chained-from-sibling shortcut: Check for same-day extract or enrich output:

bash

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

If a same-day report exists, parse the

{slug}

and load the provider data (

providers.json

enriched.json

). This gives you names, credentials, specialties, and locations — skip parsing and go directly to Step 2.

Parse

$ARGUMENTS

for input type using the Input Parsing Pattern from

references/nimble-playbook.md

. Key routing:

Sibling output detected (providers.json/enriched.json) -> proceed to Step 2
CSV/Sheet/pasted data detected -> proceed to Step 2
Unclear -> ask (counts as 1 of max 2 prompts)

If input is clear, confirm and ask one shaping question (plain text, not AskUserQuestion):

"Found N practitioners to verify. Quick questions:

What should I verify? (credentials, specialty, active status, practice address — or all)

Healthcare vertical? (ophthalmology, dental, dermatology, general, or other)"

If input is ambiguous, use AskUserQuestion (counts as 1 of max 2 prompts):

What practitioner data should I verify?

Paste provider data directly (name + credentials + location, one per line)

Provide a CSV file path or Google Sheet URL

Or describe what you have (e.g., "a list of 50 ophthalmologists I need to verify against the NPI registry")

Skip questions the user already answered in their initial message.

兄弟工具输出快捷方式：检查是否存在当日的提取或补充输出：

bash

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

如果存在当日报告，解析

{slug}

并加载从业者数据（

providers.json

或

enriched.json

）。这将为你提供姓名、资质、专业领域和地点信息——跳过解析步骤，直接进入步骤2。

根据

references/nimble-playbook.md

中的输入解析模式，解析

$ARGUMENTS

以确定输入类型。关键路由：

检测到兄弟工具输出（providers.json/enriched.json）-> 进入步骤2
检测到CSV/表格/粘贴的数据 -> 进入步骤2
输入不明确 -> 询问用户（最多可提示2次）

如果输入明确，确认并提出一个明确问题（纯文本，不要使用AskUserQuestion）：

“已找到N位需要验证的从业者。快速提问：

需要验证哪些内容？（资质、专业领域、活跃状态、执业地址——或全部）

医疗垂直领域？（眼科、牙科、皮肤科、全科，或其他）”

如果输入模糊，使用AskUserQuestion（最多可提示2次）：

需要验证哪些从业者数据？

直接粘贴从业者数据（姓名 + 资质 + 地点，每行一条）

提供CSV文件路径或Google Sheet链接

或描述你拥有的数据（例如：“我需要验证50位眼科医生的NPI注册表信息”）

如果用户在初始消息中已回答某些问题，则跳过这些问题。

Step 2: Analyze Input Data

步骤2：分析输入数据

Parse the input into structured records. For each practitioner, identify:

Claimed fields — name, credentials, specialty, state/city, practice name
Verification targets — which claims to check based on user's focus

Minimum required fields: Name + at least one of (credentials, state, specialty). If a practitioner has only a name with no other identifiers, flag it: "Cannot verify [name] — need at least a state, credential, or specialty to search."

Build a verification plan summary:

"Analyzing N practitioners for verification:

Names: N/N present

Credentials claimed: N/N

Specialty claimed: N/N

State/location: N/N

Starting NPI verification..."

Run Layer 2 WSA discovery now that you know the specialty:

bash

nimble agent list --limit 50 --search "[specialty]"
nimble agent list --limit 50 --search "[registry-user-mentioned]"

See

references/wsa-reference.md

for session-specific discovery.

将输入解析为结构化记录。针对每位从业者，识别：

申报字段——姓名、资质、专业领域、州/城市、执业机构名称
验证目标——根据用户的关注重点确定需要检查的申报内容

必填字段：姓名 + 至少一项（资质、州、专业领域）。如果某位从业者仅有姓名而无其他标识符，标记为： “无法验证[姓名]——需要至少一个州、资质或专业领域信息以进行搜索。”

生成验证计划摘要：

“正在分析N位从业者的验证需求：

姓名：N/N已提供

申报资质：N/N已提供

申报专业领域：N/N已提供

州/地点：N/N已提供

开始NPI验证...”

现在你已了解专业领域，运行第2层WSA发现：

bash

nimble agent list --limit 50 --search "[specialty]"
nimble agent list --limit 50 --search "[registry-user-mentioned]"

请参考

references/wsa-reference.md

了解会话专属发现流程。

Step 3: NPI Registry Lookup

步骤3：NPI注册表查询

Prefer the NPPES API — it returns structured JSON in one call instead of search + extract (two calls). Build the query URL from the practitioner's fields:

bash

nimble extract --url "https://npiregistry.cms.hhs.gov/api/?version=2.1&first_name=[First]&last_name=[Last]&state=[ST]&limit=5" --format markdown

Add

&taxonomy_description=[Specialty]

if the specialty is known and specific enough. The API returns NPI number, status, credentials, taxonomy codes, addresses, and enumeration dates — everything needed for verification in a single call.

Fallback to web search if the NPPES API returns zero results or errors:

bash

nimble search --query "[Name] [Credential] [State] NPI registry" --max-results 5 --search-depth lite

Then extract the top result from an NPI source (see source priority below).

Source priority (enforce in sub-agent prompts):

NPPES API (
```
npiregistry.cms.hhs.gov/api/
```
) — preferred, structured JSON
```
npidb.org/doctors/
```
— clean structured data, good fallback
```
nppes.cms.hhs.gov
```
(provider-view pages) — official CMS source
Skip all others (healthline, hmedata, vitals, etc.) — inconsistent formatting

Tell sub-agents: "Only extract from NPPES API, npidb.org, or nppes.cms.hhs.gov. Ignore other NPI aggregator sites."

Search budget per provider: Max 3 search queries + 1 extraction per practitioner. If no NPI match after 3 attempts, mark as Unverified and move on. Tell sub-agents: "Do not run more than 4 nimble commands per provider. Mark as Unverified if no match by then."

For 10+ practitioners, use sub-agents (see Sub-Agent Strategy below).

Key fields from NPI records — see

references/npi-verification-patterns.md

for the full list: NPI number, status, credentials, taxonomy/specialty, enumeration date, last updated, practice address.

Checkpoint enforcement: After each sub-agent returns its batch results, the main context MUST write the checkpoint before spawning the next step or presenting results:

Receive sub-agent results

Write checkpoint:

echo '[results]' > ~/.nimble/memory/healthcare-providers-verify/checkpoints/{slug}/batch-{n}.json

Continue to next step

Do NOT skip this — if the run fails between steps, the user loses all progress.

优先使用NPPES API——它可通过一次调用返回结构化JSON，无需搜索+提取（两次调用）。根据从业者的字段构建查询URL：

bash

nimble extract --url "https://npiregistry.cms.hhs.gov/api/?version=2.1&first_name=[First]&last_name=[Last]&state=[ST]&limit=5" --format markdown

如果专业领域已知且足够具体，添加

&taxonomy_description=[Specialty]

。该API会返回NPI编号、状态、资质、分类代码、地址和注册日期——一次调用即可获取验证所需的全部信息。

如果NPPES API返回零结果或错误，回退到网页搜索：

bash

nimble search --query "[Name] [Credential] [State] NPI registry" --max-results 5 --search-depth lite

然后从NPI来源中提取排名靠前的结果（请遵循以下来源优先级）。

来源优先级（在子Agent提示中强制执行）：

NPPES API (
```
npiregistry.cms.hhs.gov/api/
```
)——首选，结构化JSON
```
npidb.org/doctors/
```
——清晰的结构化数据，良好的回退选项
```
nppes.cms.hhs.gov
```
（提供者视图页面）——官方CMS来源
跳过所有其他来源（healthline、hmedata、vitals等）——格式不一致

告知子Agent：“仅从NPPES API、npidb.org或nppes.cms.hhs.gov提取信息。忽略其他NPI聚合网站。”

每位从业者的搜索预算：每位从业者最多3次搜索查询 + 1次提取。如果3次尝试后仍未找到NPI匹配项，标记为未验证并继续处理下一位。告知子Agent：“每位从业者运行的nimble命令不得超过4次。如果届时仍无匹配项，标记为未验证。”

如果从业者数量超过10位，使用子Agent（请参阅下文的子Agent策略）。

NPI记录中的关键字段——请查看

references/npi-verification-patterns.md

获取完整列表：NPI编号、状态、资质、分类/专业领域、注册日期、最后更新日期、执业地址。

检查点强制执行：每个子Agent返回其批量结果后，主上下文必须在启动下一步或展示结果前写入检查点：

接收子Agent结果

写入检查点：

echo '[results]' > ~/.nimble/memory/healthcare-providers-verify/checkpoints/{slug}/batch-{n}.json

继续执行下一步

请勿跳过此步骤——如果运行在步骤之间失败，用户将丢失所有进度。

Step 4: Cross-Reference and Verify

步骤4：交叉引用与验证

For each practitioner, compare claimed data against extracted NPI data. Follow the verification logic in

references/npi-verification-patterns.md

Name matching — normalize both names and determine match level (Strong, Likely, Weak, No Match) per the name matching rules in the reference
Credential matching — compare claimed credentials against NPI record
Specialty matching — compare claimed specialty against NPI taxonomy using the taxonomy matching strategy in the reference
Address matching — compare claimed state/city against NPI practice address
Status check — verify NPI status is Active

Assign verification status per practitioner based on the totality of evidence:

Verified — all claims match NPI record
Partially Verified — NPI found, minor discrepancies
Unverified — no NPI match found or unable to disambiguate
Flagged — active mismatches requiring human review

See

references/npi-verification-patterns.md

for the detailed criteria for each status and the mismatch severity levels (Critical vs Warning).

针对每位从业者，将申报数据与提取的NPI数据进行比对。遵循

references/npi-verification-patterns.md

中的验证逻辑：

姓名匹配——标准化两个姓名，并根据参考文档中的姓名匹配规则确定匹配级别（强匹配、可能匹配、弱匹配、无匹配）
资质匹配——将申报资质与NPI记录进行比对
专业领域匹配——使用参考文档中的分类匹配策略，将申报专业领域与NPI分类进行比对
地址匹配——将申报的州/城市与NPI执业地址进行比对
状态检查——验证NPI状态是否为活跃

为每位从业者分配验证状态：基于所有证据的整体情况：

已验证——所有申报内容与NPI记录匹配
部分验证——找到NPI记录，但存在轻微差异
未验证——未找到NPI匹配项或无法明确区分
已标记——存在需要人工审核的活跃不匹配项

请查看

references/npi-verification-patterns.md

获取每个状态的详细标准以及不匹配严重级别（严重 vs 警告）。

Step 5: WSA Supplementary Verification (Optional)

步骤5：WSA补充验证（可选）

If the user requested regulatory verification beyond NPI lookup, or if Step 5 left practitioners as Unverified that might benefit from additional sources:

Run verification-phase WSAs discovered in Step 0. See

references/wsa-reference.md

for the verification phase mapping, agent evaluation, and fallback chains.

Practice confirmation: For Unverified practitioners, try confirming their practice exists via practice-level WSAs or web search:

bash

nimble search --query "[practice-name] [city] [state]" --max-results 5 --search-depth lite

Regulatory verification: For practitioners the user wants regulatory checks on:

bash

nimble search --query "[name] [credentials] clinical trials OR FDA OR board certification" --max-results 5 --search-depth lite

如果用户要求进行NPI查询之外的监管验证，或者步骤5中仍有未验证的从业者可能从其他来源受益：

运行步骤0中发现的验证阶段WSA。请查看

references/wsa-reference.md

了解验证阶段映射、Agent评估和回退链。

执业机构确认：针对未验证的从业者，尝试通过执业机构级WSA或网页搜索确认其执业机构是否存在：

bash

nimble search --query "[practice-name] [city] [state]" --max-results 5 --search-depth lite

监管验证：针对用户需要进行监管检查的从业者：

bash

nimble search --query "[name] [credentials] clinical trials OR FDA OR board certification" --max-results 5 --search-depth lite

Step 6: Deduplication & Confidence Scoring

步骤6：去重与置信度评分

Follow the Entity Deduplication pattern from

references/nimble-playbook.md

. Skill-specific dedup rules are in

references/provider-extraction-patterns.md

NPI dedup check: After all sub-agents return, scan for duplicate NPI numbers across batches. If two different providers mapped to the same NPI, flag both as "Flagged — possible NPI collision, requires human review." This catches data entry errors and name confusion in the source provider list.

Verification-specific scoring: The verification status (Verified / Partially Verified / Unverified / Flagged) replaces confidence scoring for this skill. Each status includes a confidence qualifier:

High confidence — 2+ NPI sources corroborate, strong name match
Medium confidence — single NPI source, likely name match
Low confidence — weak name match, partial field matches

遵循

references/nimble-playbook.md

中的实体去重模式。本技能专属的去重规则请查看

references/provider-extraction-patterns.md

。

NPI去重检查：所有子Agent返回结果后，扫描各批次中的重复NPI编号。如果两个不同的从业者映射到同一个NPI，将两者标记为“已标记——可能存在NPI冲突，需要人工审核”。这可以捕获源从业者列表中的数据输入错误和姓名混淆问题。

验证专属评分：验证状态（已验证/部分验证/未验证/已标记）将替代本技能的置信度评分。每个状态包含一个置信度限定词：

高置信度——2个及以上NPI来源证实，姓名强匹配
中置信度——单个NPI来源，姓名可能匹配
低置信度——姓名弱匹配，部分字段匹配

Step 7: Output

步骤7：输出

Present results as a verification report — showing status per practitioner with specific mismatch details. Group by verification status, include a "What This Means" section at the end.

markdown

undefined

以验证报告的形式展示结果——显示每位从业者的状态以及具体的不匹配详情。按验证状态分组，在末尾添加“结果说明”部分。

markdown

undefined

Provider Verification: [N] Practitioners Checked

提供者验证：已检查[N]位从业者

[Date] | [V] Verified, [PV] Partially Verified, [U] Unverified, [F] Flagged

[日期] | [V]已验证，[PV]部分验证，[U]未验证，[F]已标记

TL;DR

摘要

Verified [V] of [T] practitioners against the NPI registry. [F] flagged for review: [brief description of critical issues]. [U] could not be verified — [common reason].

已针对NPI注册表验证[T]位从业者中的[V]位。[F]位已标记需审核：[严重问题简要描述]。[U]位无法验证——[常见原因]。

Verification Results

验证结果

#	Name	Claimed	NPI Status	Verification	Issues	Source
1	Dr. Jane Smith	MD, Retinal Surgery, TX	Active (NPI 1234567890)	Verified	—	NPI
2	Dr. John Doe	OD, Ophthalmology, CA	Active (NPI 0987654321)	Partially Verified	Subspecialty differs	NPI
3	Dr. Alex Chen	MD, Dentistry, NY	Not Found	Unverified	No NPI match	NPPES query
4	Dr. Pat Lee	DO, Cardiology, FL	Deactivated	Flagged	NPI deactivated 2024-01	NPI

#	姓名	申报信息	NPI状态	验证状态	问题	来源
1	Jane Smith医生	MD，视网膜外科，德克萨斯州	活跃（NPI 1234567890）	已验证	—	NPI
2	John Doe医生	OD，眼科，加利福尼亚州	活跃（NPI 0987654321）	部分验证	亚专业领域不符	NPI
3	Alex Chen医生	MD，牙科，纽约州	未找到	未验证	无NPI匹配项	NPPES查询
4	Pat Lee医生	DO，心脏病学，佛罗里达州	已停用	已标记	NPI于2024-01停用	NPI

Flagged Practitioners (Requires Human Review)

已标记从业者（需人工审核）

Dr. Pat Lee

Pat Lee医生

Claimed: DO, Cardiology, FL NPI Record: NPI 1122334455 — Deactivated (01/15/2024) Issues:

CRITICAL: NPI status is Deactivated since January 2024
Credential matches (DO confirmed)
Specialty matches (Cardiovascular Disease taxonomy) Source: NPI Record Action needed: Confirm if provider has re-registered or if this is a different individual.

[Repeat per flagged practitioner]

申报信息：DO，心脏病学，佛罗里达州 NPI记录：NPI 1122334455 — 已停用（2024年1月15日）问题：

严重：NPI状态自2024年1月起已停用
资质匹配（已确认DO）
专业领域匹配（心血管疾病分类）来源：NPI记录 需采取的行动：确认提供者是否已重新注册，或是否为不同个体。

[每位已标记从业者重复上述内容]

Unverified Practitioners

未验证从业者

[List practitioners where no NPI match was found, with search queries attempted]

[列出未找到NPI匹配项的从业者，以及尝试过的搜索查询]

Verification Summary

验证总结

Verified: [V] practitioners — all claims confirmed
Partially Verified: [PV] — minor discrepancies noted
Unverified: [U] — no NPI match (common names, missing identifiers)
Flagged: [F] — critical issues requiring review

已验证：[V]位从业者——所有申报内容已确认
部分验证：[PV]位——存在轻微差异
未验证：[U]位——无NPI匹配项（姓名过于常见、缺少标识符）
已标记：[F]位——存在需审核的严重问题

Sources

来源

[Clickable URL for every NPI lookup page used, grouped by practitioner]

[每位从业者使用的所有NPI查询页面的可点击URL，按从业者分组]

What This Means

结果说明

[Actionable interpretation: which practitioners are safe to include in your directory, which need follow-up, what the verification rate tells you about your data quality. Suggest next steps for unverified/flagged records.]


**Source links are mandatory.** Every verification finding must trace back to a
source URL.

[可操作的解读：哪些从业者可安全纳入你的目录，哪些需要跟进，验证率反映了你的数据质量如何。为未验证/已标记记录建议下一步行动。]


**来源链接为必填项**。每个验证结果必须追溯到来源URL。

Step 8: Save to Memory

步骤8：保存到内存

Make all Write calls simultaneously:

Report ->

~/.nimble/memory/reports/healthcare-providers-verify-{slug}-{date}.md

Verification data ->

~/.nimble/memory/healthcare-providers-verify/{slug}/verified.json

Profile -> update

last_runs.healthcare-providers-verify

~/.nimble/business-profile.json

(only if profile exists)

Follow the wiki update pattern from
```
references/memory-and-distribution.md
```
: update
```
index.md
```
rows for all affected entity files, append a
```
log.md
```
entry for this run.
Clean up checkpoint (complete run) or keep (partial run)

Update sibling artifacts: If

providers.json

enriched.json

exists for this slug under

~/.nimble/memory/

, merge NPI numbers and verification status into those files. Generate a verified CSV export at

~/.nimble/memory/healthcare-providers-verify/{slug}/verified-{date}.csv

with all verification columns (NPI, NPI Status, NPI Taxonomy, Verification Status). Offer this export path in Step 9 so the user can copy it where needed.

同时执行所有写入操作：

报告 ->

~/.nimble/memory/reports/healthcare-providers-verify-{slug}-{date}.md

验证数据 ->

~/.nimble/memory/healthcare-providers-verify/{slug}/verified.json

配置文件 -> 更新

~/.nimble/business-profile.json

中的

last_runs.healthcare-providers-verify

（仅当配置文件存在时）

遵循
```
references/memory-and-distribution.md
```
中的wiki更新模式：更新所有受影响实体文件的
```
index.md
```
行，在
```
log.md
```
中添加本次运行的条目。
清理检查点（运行完成）或保留检查点（运行未完成）

更新兄弟工具产物：如果

~/.nimble/memory

下存在此slug对应的

providers.json

或

enriched.json

，将NPI编号和验证状态合并到这些文件中。在

~/.nimble/memory/healthcare-providers-verify/{slug}/verified-{date}.csv

生成验证CSV导出文件，包含所有验证列（NPI、NPI状态、NPI分类、验证状态）。在步骤9中提供此导出路径，以便用户按需复制。

Step 9: Share, Distribute & Follow-ups

步骤9：分享、分发与跟进

Always offer distribution — do not skip. Follow

references/memory-and-distribution.md

for connector detection and sharing flow.

Notion: full verification report as a dated subpage. Slack: TL;DR with verification counts and flagged items only.

Follow-ups:

"Tell me more about Dr. X" -> show full verification detail
"Export as CSV" -> generate CSV with verification statuses
"Re-verify flagged only" -> re-run NPI search for Flagged/Unverified only
"What should I do about the flagged ones?" -> actionable next steps per issue

Sibling skill suggestions:

Next steps:
Run
healthcare-providers-extract
on unverified providers' practice URLs to get fresh data
Run
healthcare-providers-enrich
to fill gaps in verified providers' records
Run
market-finder
to find additional practices in this area

务必提供分发选项——请勿跳过。遵循

references/memory-and-distribution.md

中的连接器检测和分享流程。

Notion：将完整验证报告保存为带日期的子页面。 Slack：仅分享摘要，包含验证计数和已标记项。

跟进选项：

“告诉我更多关于X医生的信息” -> 展示完整验证详情
“导出为CSV” -> 生成包含验证状态的CSV文件
“仅重新验证已标记的从业者” -> 仅对已标记/未验证的从业者重新运行NPI搜索
“针对已标记的从业者我应该怎么做？” -> 根据问题提供可操作的下一步建议

兄弟工具建议：

下一步行动：
针对未验证从业者的执业网址运行
healthcare-providers-extract
以获取最新数据
针对已验证从业者运行
healthcare-providers-enrich
以填补数据空白
运行
market-finder
以查找该区域的其他执业机构

Sub-Agent Strategy

子Agent策略

For batch verification (10+ practitioners), use

nimble-researcher

agents (

agents/nimble-researcher.md

) to parallelize NPI lookups and extraction.

Follow the sub-agent spawning rules from

references/nimble-playbook.md

(bypassPermissions, batch max 4, explicit Bash instruction, fallback on failure).

Spawn pattern: One agent per batch of 5 practitioners. Each agent runs Steps 3-4 for its assigned practitioners and returns verification records. Tell each agent to use

nimble extract-batch

for its NPI result URLs where possible — one batch call per agent is faster than sequential calls.

Small batch optimization: If fewer than 10 practitioners, run directly from the main context instead of spawning agents.

Fallback: If any agent fails, run those verifications directly from the main context. Never leave gaps in the output.

针对批量验证（10位及以上从业者），使用

nimble-researcher

Agent（

agents/nimble-researcher.md

）并行执行NPI查询和提取。

遵循

references/nimble-playbook.md

中的子Agent生成规则（绕过权限、批量最大4个、明确Bash指令、失败时回退）。

生成模式：每5位从业者分配一个Agent。每个Agent为其分配的从业者执行步骤3-4，并返回验证记录。告知每个Agent尽可能对其NPI结果URL使用

nimble extract-batch

——每个Agent一次批量调用比顺序调用更快。

小批量优化：如果从业者数量少于10位，直接从主上下文运行，无需生成Agent。

回退方案：如果任何Agent失败，直接从主上下文运行这些验证。输出中不得存在空白。

Error Handling

错误处理

See

references/nimble-playbook.md

for the standard error table (missing API key, 429, 401, empty results, extraction garbage). Skill-specific errors:

No NPI results for practitioner: "Couldn't find an NPI record for [name] in [state]. The name may be too common, or the provider may practice under a different name. Want me to try with additional context (practice name, NPI number)?"
Multiple NPI matches: "Found multiple NPI records for [name] in [state]. Can you confirm which one? [list top 3 with NPI numbers and specialties]"
NPI page extraction returned garbage: "The NPI lookup page appears to be JavaScript-rendered. Retrying with browser rendering..." (auto-retry with
```
--render
```
per the shared pattern)
CSV/Sheet parse error: "Couldn't parse the input file. Expected columns with practitioner names and at least one identifier (state, specialty, or credentials). Can you paste the data directly instead?"
Insufficient data for verification: "Cannot verify [N] practitioners — they have only a name with no state, credential, or specialty. Add identifiers or remove them from the list."

请查看

references/nimble-playbook.md

中的标准错误表（缺失API密钥、429、401、空结果、提取无效数据）。本技能专属错误：

从业者无NPI结果：“无法在[州]找到[姓名]的NPI记录。姓名可能过于常见，或提供者可能使用其他姓名执业。是否需要我尝试添加更多上下文（执业机构名称、NPI编号）？”
多个NPI匹配项：“在[州]找到[姓名]的多个NPI记录。能否确认是哪一个？[列出前3个，包含NPI编号和专业领域]”
NPI页面提取返回无效数据：“NPI查询页面似乎是JavaScript渲染的。正在使用浏览器渲染重试...”（按照共享模式自动使用
```
--render
```
重试）
CSV/表格解析错误：“无法解析输入文件。预期包含从业者姓名和至少一个标识符（州、专业领域或资质）的列。能否直接粘贴数据？”
验证数据不足：“无法验证[N]位从业者——他们仅有姓名，无州、资质或专业领域信息。请添加标识符或从列表中移除这些从业者。”