Content
63%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 dense, correctly sequenced, and highly actionable workflow grounded in repo-specific facts Claude could not infer (stubbed vs unstubbed generation, naming transformations, failing-specs policy, versioning special cases). Its main weaknesses are the repeated stubbing warnings, one incomplete pseudocode block in the core gap-discovery flow, and a monolithic structure with no reference files despite content that clearly warrants splitting.
Suggestions
Extract the C# test-pattern gallery, the existing-coverage directory inventory, and the CI coverage-upload details into reference files (e.g. references/test-patterns.md, references/coverage-map.md) and link them from SKILL.md — this addresses both the progressive_disclosure and conciseness issues in one move.
State the stubbed-vs-unstubbed behavior once (in the Step 3 area or a single dedicated section) and delete the repeated warnings at the Important note, the Step 3 note, and the Notes section, keeping one pointer to Test-Spector.ps1.
Complete the Step 1 gap-discovery PowerShell loop with the actual spec-to-test-path matching logic (underscore-prefixing, kebab-to-PascalCase, parent-vs-child coverage), since discovery is the skill's primary flow and is currently left as '# ... check if test exists' pseudocode.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with repo-specific, non-inferable facts (stubbing semantics, "$failingSpecs", kebab-to-PascalCase transformations), but "All committed Spector libraries are stubbed" plus the pointer to Test-Spector.ps1 is repeated roughly five times (the Important note, the stubbing section, the Step 3 note, and the Notes section), and the 30-line existing-coverage directory catalog is admitted to go stale ("The gap list evolves over time. Always re-run the comparison"). This fits 'mostly efficient but could be tightened' rather than score 4; it is not score 2 because nearly all of the content is high-value information Claude cannot already know. | 3 / 5 |
Actionability | Commands are copy-paste ready throughout ("pwsh eng/scripts/Test-Spector.ps1 -filter \"http/encode/duration\"", "dotnet test ... --filter \"FullyQualifiedName~...\"", complete C# test templates and csproj snippets), but the skill's primary flow — programmatic gap discovery — ends in pseudocode: "# ... check if test exists". That is a concrete gap preventing a 5, while everything else is fully executable, keeping it above score 3. | 4 / 5 |
Workflow Clarity | A 10-item workflow checklist is followed by sequenced Steps 1–8 with explicit checkpoints ("Verify the spec is not in the failing specs list", "Verify generation succeeded" with a check command, "Validate all tests pass") and Test-Spector.ps1's regenerate-run-restore cycle. Score 5 requires explicit error-recovery feedback loops, which are absent (no guidance for what to do when a test fails or generation errors); score 3 would understate the checkpoints that are clearly present, so this sits at 'clear sequence with most checkpoints; minor validation gaps'. | 4 / 5 |
Progressive Disclosure | This is a single ~560-line SKILL.md with no bundle files at all, and substantial content that belongs in separate reference files is inlined: the C# test-pattern gallery (six full patterns), the existing-coverage directory inventory, and the CI coverage-upload command block. Internal section headers and the workflow checklist keep it navigable (above the score-2 'minimal structure' anchor), but with no references and content that should be split inline, it fits 'some structure but could be better organized' rather than score 4. | 3 / 5 |
Total | 14 / 20 Passed |