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 high-quality, contract-style skill body: fully phased workflow with strong validation and error-recovery checkpoints, concrete commands and examples, and no filler. Remaining gaps are minor — slightly verbose annotation/result-channel prose, two validation steps lacking exact commands, and inconsistent reference-path notation.
Suggestions
Give the exact inline Node command for the ESM data-URL import check and a representative in-memory mock dataApi snippet in Phase 4, so validation steps 2 and 5 are copy-paste executable like the PAC CLI commands.
Pick one canonical form for reference paths (either the relative ../../ links or ${PLUGIN_ROOT}) and use it consistently in the References block and Phase 1.
Tighten the annotations bullets and result-channel prose by leaning on the inline JSON/JavaScript examples, cutting sentences that restate what the examples show.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense, imperative, and free of explanations of concepts Claude already knows; nearly every line encodes host-specific contract details the model could not infer ("_<field>_value" lookup shapes, "@OData.Community.Display.V1.FormattedValue", reserved envelope keys). It misses 5 because the annotations bullets and result-channel prose partially restate what the inline examples already demonstrate, and could be trimmed. | 4 / 5 |
Actionability | Concrete PAC CLI commands ("pac model list-tables --search", "pac model genpage generate-types --data-sources ... --output-file ..."), a complete JSON sidecar example, an explicit runTool signature, and specific validation steps (JSON.parse checks, grep for imports/placeholders). It falls short of 5 because two validation steps — importing the file as an ESM data URL and invoking runTool with an in-memory mock dataApi — describe the technique without giving the exact inline command. | 4 / 5 |
Workflow Clarity | Phases 1-4 are clearly sequenced with a dedicated validation phase, explicit failure handling ("If discovery or type generation fails, stop and report the error. Do not fall back to invented tables or columns"), temporary-artifact cleanup, and a refinement loop that re-runs schema verification when edits introduce unverified names. Validation checkpoints fully cover the destructive/batch Dataverse operations. | 5 / 5 |
Progressive Disclosure | Sections are well organized and the one-level-deep references (host API .d.ts, known-good sample .tool.js/.tool.json, sibling UI skill) are signaled both in a References block and again in Phase 1. It misses 5 because the reference paths are given in two inconsistent forms (relative ../../ links vs. ${PLUGIN_ROOT} paths), and the long MUST rule-lists are candidates for partial extraction into a reference file; no bundle files are present here to verify the referenced paths resolve. | 4 / 5 |
Total | 17 / 20 Passed |