Conciseness

The body is code- and table-forward with every section earning its place, but the intro re-explains what US Core/USCDI are ("the HL7 US realm profiles that EHRs (Epic, Cerner/Oracle Health) require") and lines like "OpenMed NER gives you the clinical mention; US Core wants structured context" are explanatory padding Claude doesn't need. Not 5: a handful of framing sentences could be trimmed; not 3: the bulk is tight, executable guidance.

Actionability

Fully executable throughout: a copy-paste `curl` download for validator_cli.jar, a complete `java -jar validator_cli.jar condition.json -version 4.0.1 -ig hl7.fhir.us.core -tx ...` invocation, a concrete `meta.profile` JSON snippet, and a runnable `from openmed.clinical.exporters.fhir import from_validation_result` example. Not 4: the commands and code cover the common cases with no gaps — even the exit-code behavior and version pinning (`-ig hl7.fhir.us.core#6.1.0`) are specified.

Workflow Clarity

The 6-step Workflow sequences export → declare profile → validate → interpret issues → re-validate until clean → submit, with an explicit validation checkpoint ("**error** = will be rejected; **warning** = must-support / best practice") and a re-validate feedback loop. Not 4: this matches the anchor-5 example's validate/fix/retry structure exactly, and the Edge cases section preempts the known failure modes (missing -tx, unpinned IG, lone-resource validation).

Progressive Disclosure

The single-file body is cleanly sectioned (When to use, Quick start, gaps table, Workflow, Edge cases, Standards) with a well-signaled Standards & references section, and no nested references. Not 5: the skill is ~145 lines with everything inlined — the conformance-gaps table and edge-case list are plausible candidates for a reference file, and the under-50-line exception doesn't apply; not 3: what's inline is cohesive overview-plus-quickstart material, not a wall of API reference.

Specificity

The description lists multiple concrete actions — "running validator_cli.jar (or the public validator.fhir.org)", "declaring meta.profile", "must-support elements", "common conformance gaps (missing code/category/status)", and "turning validator output into a FHIR OperationOutcome" — giving comprehensive coverage of the skill's capabilities. Not 4: there are no minor gaps; every clause names a specific, discrete capability rather than a generic category.

Completeness

It explicitly answers both what ("Validate FHIR R4 resources and Bundles against US Core / USCDI profiles with the official HL7 FHIR validator before submitting to an EHR") and when ("Use after exporting-to-fhir / assembling-fhir-bundles ... when the user mentions US Core, USCDI, must-support, profile validation, or Epic/Cerner ingestion requirements"). Not 4: the when-clause is explicit with concrete trigger phrases, matching the anchor-5 example's structure.

Trigger Term Quality

Trigger terms are natural user phrasing with synonyms: "US Core, USCDI, must-support, profile validation, or Epic/Cerner ingestion requirements", plus "validate" and "FHIR". Not 4: no common variation a user would say when needing this skill is missing for this domain.

Distinctiveness Conflict Risk

It occupies a clear niche — US Core conformance validation as a post-build gate — and explicitly positions itself against sibling skills ("Use after exporting-to-fhir / assembling-fhir-bundles"), so overlap risk is minimal. Not 4: the triggers (US Core, USCDI, must-support) are owned by this skill alone and would not plausibly fire the mechanical builder skills.