Content
81%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 dense, exceptionally well-researched operational skill whose tool-specific failure modes and parameter requirements are exactly what Claude could not infer. Its main cost is length: a conceptual reasoning section teaches knowledge Claude already has, and the OMA/OrthoDB pitfalls are duplicated between Phase 2 and Limitations, pushing conciseness below the otherwise excellent actionability and workflow clarity.
Suggestions
Trim the Conservation Reasoning Framework to the tool-specific content (the dN/dS data path via ensembl_get_homology -> EnsemblSeq_get_id_sequence -> Sequence_dn_ds, and the PhastCons/GERP thresholds); drop the textbook interpretation of dN/dS ratios, 1:many subfunctionalization, and conservation-depth-vs-essentiality explanations, which Claude already knows.
State each OMA/OrthoDB failure mode once: the OMA_resolve_xref substring-matching and OrthoDB_search_groups loose-match pitfalls appear almost verbatim in both Phase 2 and Limitations — keep the Phase 2 detail and cross-reference it from Limitations with one line each.
Move the detailed OMA and OrthoDB tool-call blocks with their verified-live annotations (~95 lines) into a references/ file (e.g. references/ortholog-databases.md), keeping a short decision guide ('use OMA when X, OrthoDB when Y') inline in Phase 2.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The bulk of the body is high-value, non-inferable tool knowledge (e.g. 'OMA does not paginate internally... metadata.total_count is the TRUE ortholog count'), but the Conservation Reasoning Framework section re-explains textbook concepts Claude already knows ('A dN/dS ratio > 1 indicates positive selection', 'A 1:many relationship... copies may have subfunctionalized', 'A gene conserved across all vertebrates suggests a fundamental cellular process'), and the OMA/OrthoDB failure modes are stated twice — nearly verbatim in Phase 2 and again in Limitations. Mostly efficient but with some unnecessary explanation and clear tightening opportunities, matching the score-3 anchor. | 3 / 5 |
Actionability | Guidance is fully concrete and executable in its tool environment: exact tool names with required parameters ('The species parameter is REQUIRED when using gene symbols'), copy-ready call syntax ('"gene:TP53 AND organism_id:9606 AND reviewed:true"', 'OMA_get_protein(protein_id="P04637")'), a real bundled CLI ('scripts/dnds.py is the identical CLI form, validated against Biopython NG86'), and ordered fallback chains. Specific examples cover the common cases, matching the score-5 anchor. | 5 / 5 |
Workflow Clarity | A six-phase workflow is laid out with an overview diagram, each phase has concrete steps and per-phase reasoning, and explicit validation precedes conclusions ('Before concluding a gene is lineage-specific, check: (1)... (2)... (3)'; 'confirm a reference assembly exists... before concluding the gene is truly absent'). The Fallback Strategies section provides error-recovery loops for each failure mode, matching the score-5 anchor with explicit validation steps and feedback loops. | 5 / 5 |
Progressive Disclosure | Structure is good: numbered phases, clear headers, and one real one-level-deep reference to the bundled 'scripts/dnds.py' (verified to exist). However, roughly 95 lines of per-tool OMA/OrthoDB semantics and verified-live failure annotations are inlined in SKILL.md where a reference file would keep the overview lean, leaving minor organization gaps consistent with the score-4 anchor rather than a clean split. | 4 / 5 |
Total | 17 / 20 Passed |