Content
78%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 well-structured router-style skill body: an evidence-tier policy with usage rules, a task→file index, an ordered canonical workflow with validation mentions, and concrete lookup tooling (MCP tool names, a pinned CLI, copy-paste query recipes). It stays lean and assumes ONNX Runtime knowledge, but the workflow steps and their validation checkpoints are directional rather than inline-executable, with the executable detail delegated to referenced files.
Suggestions
Inline one minimal copy-paste recipe for the most common path — e.g., the EnsureReadyAsync → TryRegister → GetEpDevices → AppendExecutionProvider call sequence or a two-line C# snippet — so the canonical workflow's step 4–5 is executable without opening bundle files.
Operationalize the validation checkpoints: name the concrete check at steps 5–7 (e.g., which ETW log or log line confirms the selected EP, or the command that reports EP_NOT_APPLICABLE cache misses) instead of the bare instruction "validate them before reuse".
Tighten the evidence-tier section by merging the tier table's "How to use it" column with the four bullet rules, which overlap — this trims tokens without losing any policy.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is efficient and assumes Claude's competence ("Inference uses ordinary ONNX Runtime APIs" — no library primers), and it avoids restating basics. It is not a 5 because minor tightening is possible: the tier table's "How to use it" column and the four bullet rules partially overlap, and sentences like "This skill keeps three kinds of knowledge apart. Upstream docs can be wrong or silent…" explain rationale that could be trimmed. It is clearly above 3, which would require genuinely unnecessary explanation. | 4 / 5 |
Actionability | Concrete, executable guidance is present: exact MCP tool names ("microsoft_docs_search", "microsoft_docs_fetch", "microsoft_code_sample_search with language: 'csharp'"), a pinned CLI ("npx @microsoft/learn-cli@1.0.0 search|fetch|code-search"), a copy-paste query table, and exact per-task file paths. It falls short of 5 because the canonical workflow's steps ("Establish the CPU inference path first", "Find compatible EPs, then install or prepare and register") are directional — the executable detail is delegated to referenced files rather than shown, so the top-level guidance alone is not copy-paste ready. | 4 / 5 |
Workflow Clarity | The 7-step "Canonical workflow (Tier 1)" is a clear, correctly ordered sequence (model → deployment choice → CPU path → install/register → select → compile/cache → diagnostics) with validation mentioned ("Compile and cache hardware-specific artifacts, and validate them before reuse", "Try device policies only after explicit selection works") and a feedback loop via diagnostic logs ("use Windows ML diagnostic logs to see what was actually selected and why it failed"). It is not 5 because the checkpoints are named but not operationalized inline — no concrete check, command, or log event is given at the step where it applies, which is the 4 anchor ("most checkpoints present; minor validation gaps"). | 4 / 5 |
Progressive Disclosure | The body is a textbook router: a tier table mapping knowledge kinds to folders, a "Read by task" table mapping each task to exactly one file (e.g., "Download failures, ETW logs, 'provider missing' triage → canon/diagnostics.md"), and clearly signaled one-level-deep links — easy navigation with content appropriately split out of SKILL.md. Note: no bundle files were present in the review workspace (no references/, scripts/, assets/, and the referenced canon/, upstream/, trackdub/, samples/ folders do not exist here), so the linked files could not be verified; the score reflects the structure as written. | 5 / 5 |
Total | 17 / 20 Passed |