Conciseness

The body is largely lean and code-driven with no tutorial padding about what ClinicalTrials.gov or Python is; it assumes competence and focuses on non-obvious domain knowledge (three-valued logic, negation/temporality, unit normalization). It falls just short of the top anchor because of minor repetition — the decision-support disclaimer appears both in the intro ('This is decision support, not enrollment') and again in edge cases ('Not a medical device...'), and the aggregation rule is stated both in prose after `evaluate()` and in the workflow's report step.

Actionability

Mostly executable guidance: `split_criteria`, the `Criterion` dataclass, the patient-profile dict, and `evaluate()` are copy-paste-ready Python covering the common cases, and the workflow names concrete tools (`openmed.analyze_text`, `coding-icd10`, `mapping-loinc`). It is not a 5 because the hardest step — structuring a free-text bullet into a `Criterion` (step 3) — is only hinted at ('numeric thresholds come from a regex/units pass') with no example, leaving a minor gap.

Workflow Clarity

The 5-step workflow is clearly sequenced (typed gates first, then split, structure, evaluate, report) and includes implicit checkpoints: unknowns are surfaced prominently, unlabeled bullets default to inclusion 'and flag for review'. This is not a destructive or batch operation, so the cap at 3 does not apply; it falls short of the top anchor only because there is no explicit re-check/error-recovery loop (e.g., what to do when NER fails to find a target or when the aggregation yields conflicting results).

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/ directories), and the single-file body is well-sectioned with clear headers (When to use, Quick start, Workflow, Edge cases, Standards) and clearly signaled links to external standards and companion skills. It matches the 'good structure' anchor rather than the top anchor because at ~155 lines with two substantial code blocks, the parser/evaluator code could arguably live in scripts/ files referenced one level deep, which would keep SKILL.md a leaner overview.

Specificity

The description lists multiple concrete actions — 'Parses free-text clinical-trial eligibility criteria into structured inclusion and exclusion logic', 'matches them against patient facts', 'screen a synthetic patient for trial fit', 'explain why a patient does or does not meet criteria' — with comprehensive coverage of the skill's scope. It matches the anchor for multiple specific concrete actions rather than the anchor below, which requires minor gaps in coverage; none are evident.

Completeness

It explicitly answers both questions: the 'what' ('Parses free-text... criteria into structured inclusion and exclusion logic, then matches them against patient facts') and the 'when' ('Use when the user wants to turn a ClinicalTrials.gov eligibility block into machine-readable rules, screen a synthetic patient..., or explain why a patient...'). This mirrors the anchor-5 example structure with concrete trigger phrases, and the 'Use when' clause is explicit, so the cap at 3 does not apply.

Trigger Term Quality

It enumerates natural trigger phrases users would actually say: 'eligibility criteria, inclusion, exclusion, trial matching, patient screening, criteria parsing' plus the technical term 'eligibilityModule' and 'age/sex gates'. This comprehensively covers natural terms and synonyms, matching the top anchor rather than the 'a few natural terms missing' anchor below.

Distinctiveness Conflict Risk

The clinical-trial eligibility niche is distinct ('ClinicalTrials.gov eligibility block', 'eligibilityModule', 'openmed.analyze_text'), and it explicitly positions itself relative to neighboring skills ('Pairs after OpenMed and after searching-clinicaltrials') and bounds its scope ('Decision-support only — never autonomous enrollment'). Minimal conflict risk with other skills, matching the clear-niche anchor rather than the 'minor overlap risk' anchor below.