Content
70%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.
The body is a well-sequenced, highly actionable workflow guide with explicit validation steps and fallback chains for the tool domain. Its weaknesses are token efficiency — general oncology education and repeated caveats pad the file — and progressive disclosure, since all reference-grade material is inlined with no bundle files or external references.
Suggestions
Trim or move the general oncology education (staging vs. grading, histological vs. molecular axes, biomarker thresholds like HER2 IHC 3+ / Ki67 >20%) into a references/ file, keeping only the tool-specific interpretation guidance (e.g., 'pass MSI-H to OncoKB as gene="Other Biomarkers"') inline.
Deduplicate: state the GBM→GB alias caveat once (Phase 2 or the codes table) and merge the 'Key Tools' table with the 'Tool Parameter Reference' table into a single table.
Create a references/ directory (e.g., oncotree-codes.md for the code table, biomarker-interpretation.md) and link to it from the body so the SKILL.md reads as a lean overview with well-signaled one-level-deep references.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The tool-specific content is dense and useful, but the "Tumor Classification Reasoning" and "Biomarker Interpretation Strategy" sections re-teach general oncology Claude already knows (e.g., "Stage (TNM): How far has it spread? T=tumor size, N=lymph nodes, M=metastasis", "Ki67: Proliferation index... High (>20%) suggests aggressive biology", "HER2: Positive = IHC 3+ or FISH-amplified"). There is also duplication: the GBM→"GB" caveat appears three times (Phase 2, the Common Codes table, and Interpretation Guidance), and tool parameters are tabulated twice (Key Tools and Tool Parameter Reference). This fits the level-3 anchor ("mostly efficient but includes some unnecessary explanation or could be tightened") better than level 4, since multiple sections, not minor instances, could be trimmed. | 3 / 5 |
Actionability | Concrete, specific guidance throughout: exact tool signatures with parameters (e.g., `OncoKB_annotate_variant(gene="EGFR", variant="L858R", tumor_type="LUAD")`), response-field documentation, verified code mappings, and case-sensitivity/404 gotchas. It falls short of the level-5 anchor ("copy-paste ready code") because the "Common Patterns" blocks are illustrative patterns over MCP tool results (e.g., `results["data"][0]["code"]`) rather than fully executable code, and no end-to-end runnable example is given — but it clearly exceeds level 3's pseudocode/incomplete level. | 4 / 5 |
Workflow Clarity | The four-phase workflow is clearly sequenced with an explicit validation checkpoint ("Always validate via `OncoTree_get_type` before using in downstream tools") and error-recovery feedback loops (the Fallback Chains table for 404s and empty searches, plus the Python pattern `if detail["status"] == "success": OncoKB_annotate_variant(...)`). This matches the level-5 anchor (explicit validation steps, feedback loops for error recovery); the domain is read-only lookup/annotation so the destructive/batch validation cap does not apply, and it is clearly above level 4's "minor validation gaps". | 5 / 5 |
Progressive Disclosure | There are no bundle files (references/, scripts/, assets/ are absent) and no pointers to external material — everything, including ~60 lines of general tumor-classification reasoning, biomarker interpretation, staging-vs-grading education, and code lookup tables, is inlined in a single ~190-line SKILL.md. Section headers are clear, but reference-style content that would naturally live in a separate file is inline, matching the level-3 anchor ("some structure but... content that should be separate is inline") rather than level 4's "most content appropriately placed" with clearly signaled references. | 3 / 5 |
Total | 15 / 20 Passed |