Conciseness

No padding or explanations of concepts Claude already knows, and every section carries non-obvious verified facts (e.g. 'Do NOT use +AND+', 'Dates are strings: device AE/MAUDE use YYYYMMDD'). However, the five worked examples and much of the interpretation-table content are duplicated verbatim in references/openfda_fields.md, so a meaningful block of tokens could be trimmed or delegated. Not 5 because of that duplication; not 3 because nothing reads as unnecessary explanation — it is mostly lean, operator-specific detail.

Actionability

Fully executable, copy-paste-ready tool calls with real outputs: 'OpenFDA_search_device_adverse_events {"search":"device.generic_name:pacemaker AND event_type:Death","limit":1}' → 'total = 16619', plus exact field paths ('animal.species:Dog', 'reaction.veddra_term_name') and concrete interpretation of each result. The examples cover the common cases across all product classes. Not 4: there are no gaps — tool names, arguments, expected outputs, and interpretation are all specified.

Workflow Clarity

The 7-step workflow (classify → pick tool → build query → run → interpret → summarize/cite → route out-of-scope) is clearly sequenced with useful checkpoints (read data.meta.results.total, cite query + total, limitations caveat, stop-and-route step 7). Not 5: there is no explicit validate-and-retry loop for failed/empty queries — the recovery advice (simplify the token, avoid special chars) lives in the grammar section rather than as a workflow checkpoint. Not 3: the sequence is complete with most checkpoints explicit; this is retrieval, not a destructive/batch operation, so the validation cap does not apply.

Progressive Disclosure

Good structure: the body is a navigable overview (tool map, grammar, workflow, examples, limitations) with a clearly signaled, real, one-level-deep reference ('See references/openfda_fields.md for the full per-endpoint field reference and additional query examples' — the file exists and matches). Not 5 because the inline interpretation tables and all five worked examples substantially duplicate the reference file, so the split is not clean; not 3 because the reference is well signaled and the core/most-needed content is appropriately inline.

Specificity

Names multiple concrete capabilities across named endpoints: 'Orchestrates openFDA endpoints (MAUDE device adverse events + device recalls + 510(k), CAERS food/supplement/cosmetic adverse events, veterinary adverse events, drug shortages, and cross-product enforcement/recall reports)' — comprehensive, no vague filler.

Completeness

Both 'what' (post-market safety surveillance and recall/adverse-event retrieval across the named product classes and endpoints) and 'when' ('USE WHEN the user asks: ...' with concrete trigger phrases) are explicitly answered, matching the anchor-5 example exactly.

Trigger Term Quality

The 'USE WHEN' clause quotes many natural user phrasings with synonyms: "are there adverse events for [device / pacemaker / infusion pump / insulin pump]", "is [drug] in shortage", "food recall for listeria", "MAUDE report for [device]", "CAERS reactions for [brand]" — comprehensive natural-language coverage. Not below 5: no common variation (device, recall, shortage, supplement, veterinary) is missing; not above because 5 is the max.

Distinctiveness Conflict Risk

The 'DO NOT USE for drug adverse-event SIGNAL detection or disproportionality (PRR / ROR /...' clause carves out a clear niche, but the clause is truncated mid-list and the skill does cover raw FAERS drug-event retrieval ('OpenFDA_search_drug_events'), leaving minor overlap risk with closely related drug-AE skills on plain "adverse events for [drug]" queries. Not 5: the boundary is incompletely stated in the description itself; not 3: the explicit DO-NOT-USE routing goes well beyond 'somewhat specific'.