Content
80%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, well-organized contract document that scores highly on token efficiency and structure, with concrete templates for annotations and file naming. Its main gap is procedural: skeleton generation and route-parity review are specified as rules rather than sequenced workflows with validation checkpoints, and a worked example would make the contracts immediately actionable.
Suggestions
Add one worked example of a complete annotated test skeleton (e.g., a single integration test showing AC, Behavior, @lane, @dependency, and Selection evidence filled in with realistic content) so the annotation contract is copy-paste actionable.
Convert the route-parity section into an explicit sequenced review checklist (identify routes to the mutation → compare validation/classification/bounds/order → classify each difference as proof obligation or not → reuse or add the smallest test), with a final verification step that all annotations and lane declarations are present.
State the skeleton-generation order explicitly (choose lane → write annotations → name the file per convention) so a generating task doesn't have to reassemble the steps from separate sections.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is pure contract — a lane table, an exact annotation template, naming globs, and a dense route-parity paragraph — with no padding and no explanation of concepts Claude already knows; the single explanatory sentence about comment syntax is one line and load-bearing, matching the lean/every-token-earns-its-place anchor rather than the trimmable-over-explanation anchor at 4. | 5 / 5 |
Actionability | The annotation block ("AC: [...]", "@lane: integration | fixture-e2e | service-integration-e2e") and file-naming globs are concrete, directly usable formats, but there is no worked example of a complete annotated test skeleton and the route-parity guidance is a comparison checklist without a demonstrated application, fitting the concrete-with-minor-gaps anchor rather than the fully-copy-paste anchor at 5. | 4 / 5 |
Workflow Clarity | The contracts are clear but procedures are implicit: generating a skeleton requires assembling rules scattered across the lanes table, annotation spec, and naming section with no stated order, and the route-parity review ("compare validation, classification, resource bounds...") reads as criteria rather than a sequenced review with checkpoints like "verify all required annotations are present", matching the sequence-present-but-checkpoints-missing anchor. | 3 / 5 |
Progressive Disclosure | At ~45 lines with well-organized sections (Test Lanes, Test Skeleton Specification, File Naming, Route Parity) and no need for external reference files — none exist and none are referenced — this meets the rubric's under-50-lines exception for a top structure score. | 5 / 5 |
Total | 17 / 20 Passed |