Content
70%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 well-sequenced, highly actionable normative playbook with explicit validation checkpoints, feedback loops, and checklists — workflow clarity is excellent. Its weaknesses are substantial cross-section redundancy (parity rules and invariants restated up to five times) and a fully monolithic structure with no reference-file split despite ~280 lines of clearly separable content.
Suggestions
Deduplicate the porting/parity requirements that appear nearly verbatim in sections 1, 3, 4, 5, and 8 — state them once authoritatively (e.g., in the contract method or validation section) and reference that statement elsewhere, and consider replacing section 8's anti-patterns list (which restates section 1's invariants) with pointers to the invariant each anti-pattern violates.
Split clearly separable material into one-level-deep reference files — e.g., references/contract-template.md for the VAL-* template and field semantics, references/validation-methods.md for validator lanes and per-surface evidence requirements, and references/task-topology.md for the work/validate/gate planning rules — keeping SKILL.md as a concise overview with well-signaled links.
Add one worked example of a real VAL-* assertion (filled Surface/Needs/Behavior/Evidence fields for a concrete scenario) so workers can pattern-match correct granularity, since the current template alone leaves the distinction between compact assertions and broad buckets abstract.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Individual sections are dense and normative without explaining concepts Claude already knows, but the same rules are restated many times: porting/parity and golden-corpus requirements appear nearly verbatim across sections 1, 3, 4, 5, and 8, and the ~20-bullet anti-patterns list in section 8 largely restates section 1's invariants and section 5's validation rules. Mostly efficient but could be tightened considerably fits anchor 3; not 2 because the prose is information-rich rather than padded filler, not 4 because the cross-section redundancy is substantial rather than minor. | 3 / 5 |
Actionability | Provides concrete, specific guidance: a copy-paste-ready VAL-* assertion template with exact field names (Surface, Needs, Behavior, Evidence), exact artifact paths (contract/<ID>.md, MEMORY.md, AGENTS.md, decisions/), defined task types (work/validate/gate), and a pre-submit_plan checklist. Mostly executable with minor gaps fits anchor 4; not 5 because there is no worked example of a real assertion or mission, and runtime mechanisms (submit_plan, advance_project, contract-review) are invoked without any invocation detail. | 4 / 5 |
Workflow Clarity | Section 2 gives a numbered 14-step operating order with an explicit replan protocol ("trace the issue back to the earliest invalid step"), mandatory adversarial contract review before task planning, validation-before-gate ordering, evidence-only closure, and a feedback loop ("diagnose the root cause and patch the earliest invalid artifact"), plus a pre-submit checklist in section 6. This matches anchor 5's clear sequence with explicit validation steps, feedback loops, and checklists. | 5 / 5 |
Progressive Disclosure | The 8-section structure is well organized, but the ~280-line skill is entirely monolithic — no references/, scripts/, or assets/ files exist, and clearly separable material (the assertion template and contract-review checklist, validation methods, the anti-pattern catalog) is inlined rather than split into one-level-deep reference files. Some structure but content that should be separate is inline fits anchor 3; not 4 because a 280-line single file is not appropriately placed content, not 2 because section headers and numbering provide real navigation. | 3 / 5 |
Total | 15 / 20 Passed |