Content
76%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A strong, highly actionable body with real executable code and genuinely non-obvious gotchas (no EFetch JSON for PubMed, History-server expiry, MeSH lag, PMC licensing). The main weaknesses are the missing in-sequence validation checkpoints for the batch-fetch workflow and mild repetition of the OpenMed NER hand-off across three sections.
Suggestions
Add explicit validation checkpoints to the Workflow sequence: after ESearch, verify the returned count and WebEnv/query_key before fetching; after each batch fetch, check for NCBI error blocks or truncated output before paging further.
Move the 429-retry/backoff feedback loop from the Edge cases section into Workflow step 3 so the batch-fetch step includes a validate-and-retry loop.
Consolidate the OpenMed NER guidance, which currently appears in When-to-use, Workflow step 5, and the Hand-off section, into the single Hand-off section.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and non-padded with no explanations of concepts Claude already knows, and every section (rate limits, EFetch-has-no-JSON, history expiry, MeSH lag) adds non-obvious domain knowledge. It falls short of 5 because the OpenMed NER hand-off is repeated across "When to use", Workflow step 5, and the "Hand-off to / from OpenMed" section — trimmable redundancy. | 4 / 5 |
Actionability | Fully executable, copy-paste-ready Python (esearch with usehistory=y, efetch_abstracts, esummary with timeouts and raise_for_status), equivalent cURL commands, and concrete query syntax ("[MeSH]", "[tiab]", "[pdat]", 2023:2025[pdat]) covering the common cases. Not 4 — there are no gaps; even error paths (HTTP 429) are addressed. | 5 / 5 |
Workflow Clarity | The 5-step workflow (build query → ESearch → batch-fetch → parse → NER) is clearly sequenced, but this is a batch operation and the sequence itself contains no validation checkpoints — no verify-count-before-fetching, no response-error check, no fetch-completeness confirmation. The 429-retry feedback loop exists only in the separate "Edge cases" section, outside the sequence, so per the batch-operations cap it cannot exceed 3; it is above 2 because the steps are well-defined and rate-limit handling is embedded in step 3. | 3 / 5 |
Progressive Disclosure | Well-organized sections (When to use, Quick start, ESummary, Workflow, Hand-off, Edge cases, Standards) with a concise overview and an external standards link list; no false references to nonexistent bundle files. Not 5 because at ~130 lines everything is inline — bulk detail such as full E-utilities parameter syntax or PMC JATS-XML parsing details could live one level deep in a reference file; not 3 because the structure and placement are otherwise appropriate. | 4 / 5 |
Total | 16 / 20 Passed |