Content
85%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.
An exceptionally actionable, well-sequenced migration procedure whose guidance is concrete and copy-paste ready at every step, with validation woven through each phase. Its main weaknesses are its monolithic single-file structure — reference material (API mapping table, semantic-gap catalogue, sandbox diagnostics) is inlined rather than progressively disclosed — and minor duplication that adds length without adding information.
Suggestions
Split reference material into one-level-deep bundle files — e.g. references/jest-vitest-api-map.md for the Step 5 mapping table, references/semantic-gaps.md for the Step 6 catalogue, and references/sandbox-diagnostics.md for Step 8b — leaving SKILL.md as the workflow overview that points to them at the step where each is needed.
Deduplicate the 'Do not run a full nx affected / run devkit as a canary' warning, which appears nearly verbatim in Step 8 and Step 9; state it once (e.g. in Step 8) and reference it from Step 9.
Tighten narrative asides that restate the same lesson twice (e.g. the cache-staleness rationale in Step 3's project.json inputs section repeats the Step 2 resolver discussion) to recover tokens without losing the trap warnings.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is terse and imperative throughout and assumes competence (no explanation of what Jest/Vitest are; every section carries non-obvious repo-specific traps like frozen ESM namespaces and CJS-channel mock deadlocks). It misses a 5 due to duplication — the 'Do not run a full nx affected / run devkit as a canary' warning appears nearly verbatim in both Step 8 and Step 9 — and a few asides that could be trimmed. | 4 / 5 |
Actionability | Fully executable throughout: copy-paste bash for the survey, a complete annotated vitest.config.mts, tsconfig.spec.json JSONC, a Jest→Vitest API mapping table, /proc-level diagnostics for hung workers, and a concrete commit-slice plan. Specific examples cover the common cases (codemod rules, snapshot regeneration, sandbox violation mapping). | 5 / 5 |
Workflow Clarity | Steps 0–9 are explicitly sequenced with pervasive validation checkpoints: Step 0 records the test-count parity target, Step 6 has explicit error-diagnosis loops (including the hung-worker triage procedure), Step 7 requires proving snapshot values did not move, Step 8 mandates repeat runs, single-file runs, and all-target checks with count parity, and Step 8b validates sandbox violations. Batch operations (codemod, snapshot regen) all carry validation, so no cap applies. | 5 / 5 |
Progressive Disclosure | Sections are clearly headed and internally navigable, but this is a single ~560-line monolithic file with no bundle: the Jest→Vitest mapping table, the Step 6 semantic-gap catalogue, and the Step 8b sandbox-diagnostics material are substantial reference content inlined rather than split into one-level-deep reference files. Better organized than anchor 2 (structure exists), but the everything-inline placement of reference material matches anchor 3 rather than anchor 4. | 3 / 5 |
Total | 17 / 20 Passed |