Content
82%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 lean, dense instruction set: four sequenced steps, three complete TypeScript templates encoding project-specific test conventions, and an exact run command. It only drops points on small concrete details — placeholder identifiers, a missing `vi` import in the component template, no failure-handling step after the test run, and fully inlined templates — none of which obscure what to do.
Suggestions
Fix the component template to import `vi` from 'vitest' so the `vi.fn()` example is executable as written.
Add a short feedback step after the vitest run (e.g., 'If tests fail, fix the test or flag the underlying bug, then re-run until green') to close the workflow loop.
Consider moving the three full templates to references/ files (e.g., references/adapter-template.md) or trimming each to its most instructive case to slim the main file.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is pure payload — 'Create tests for the specified file or module.' followed by four one-line steps and three code templates, with zero concept explanation or padding. Every template encodes project-specific conventions Claude cannot infer (naming, `__tests__/OriginalName.spec.ts`, store access via `get()`), so every token earns its place; there are no over-explanations to trim, which rules out the anchor below. | 5 / 5 |
Actionability | Concrete, structurally complete TypeScript templates with real imports ('vitest', 'svelte/store', '@testing-library/svelte'), an exact file convention ('Create the test in `__tests__/OriginalName.spec.ts`') and an exact run command ('npx vitest run --reporter=verbose'). Not fully copy-paste ready: templates use `xxx` placeholder names, and the component template calls `vi.fn()` without importing `vi`, so the code would fail as written — a minor but real gap that keeps it below the top anchor. | 4 / 5 |
Workflow Clarity | Four clearly sequenced steps (analyze file → determine test type → create spec file → run suite) with verification present via the verbose vitest run. Missing a feedback loop: no instruction on what to do when the test run reports failures, which keeps it below the explicit validate/fix/retry pattern of the top anchor; the destructive/batch cap does not apply since test creation is neither. | 4 / 5 |
Progressive Disclosure | Well-organized '## Steps' structure with three clearly labeled '###' sub-sections (Adapter, Store, Component) and no buried or nested references. At ~90 body lines with three full templates inlined, content that could live in `references/` files is kept in the main file, and the under-50-line simple-skill exception does not apply — good structure with minor organization gaps rather than an appropriately split overview. | 4 / 5 |
Total | 17 / 20 Passed |