Content
81%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 and well-validated workflow: exact commands, templates, hash algorithms, and error strings, with validation gates and feedback loops at every risky point. The main weaknesses are token efficiency — core invariants (Original Request preservation, ultra markers, language policy) are repeated four to five times each — and a two-level reference chain plus inlined config detail that keeps the main file long.
Suggestions
State each invariant once in a single 'Invariants' section and reference it from Steps 2, 5, and 6 instead of restating the Original Request preservation rule (lines 82, 175, 501, 573), the ultra-marker rule, and the language policy (lines 78-84, 371, 421, 525, 535) verbatim in multiple places — this would cut roughly 15-20% of the body without losing any operative rule.
Move the Step 0 config-resolution and language-policy detail (paths resolution, technical_terms_policy handling, translation-preservation lists) into a references/CONFIG.md and keep only the resolved-value summary inline, mirroring how LIST-MODE and CHECK-MODE are already handled.
Flatten the two-level reference chain by having SKILL.md's Step 4/+check section point directly to references/VALIDATOR.md's dispatch contract (or inlining the two substitution slots into CHECK-MODE.md), so every reference is one level deep from the main file.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with operative, project-specific rules (exact regexes, WARN strings, hash normalization) and explains nothing Claude already knows, but it repeats key invariants many times: the ultra-marker 'exactly one' rule appears roughly five times, '## Original Request' verbatim preservation is stated at four separate places (lines 82, 175, 501, 573), and the language policy is restated across lines 78-84, 371, 421, 525, and 535. Mostly efficient but needs real tightening — between anchors 2 and 3, closer to 3 since the majority of lines are unique operative content. | 3 / 5 |
Actionability | Fully executable guidance throughout: exact commands ('git branch --show-current', 'shasum -a 256'/'sha256sum' via stdin with a precise normalization algorithm), canonical regexes for Source/Reference parsing, concrete TaskUpdate/TaskCreate call shapes, copy-paste-ready report and completion templates, and exact WARN/error strings. This matches the copy-paste-ready anchor 5; anchor 4 would require missing key details. | 5 / 5 |
Workflow Clarity | Steps 0-6 are clearly sequenced with explicit validation checkpoints: ultra-marker integrity checks, SHA256 research-drift detection, a meaning-preservation gate with an explicit fail-repair-retry loop ('On failure, restore or repair the affected rewrite and repeat the comparison before saving'), the +check fresh-context validation pass, ultra link/orphan/dependency integrity re-checks, and a mandatory user-approval gate before any modification. Feedback loops and checklists are present, matching anchor 5. | 5 / 5 |
Progressive Disclosure | Bundle structure is real and well-signaled: LIST-MODE.md, CHECK-MODE.md, EXAMPLES.md, and VALIDATOR.md all exist, are referenced with clear purpose statements ('single source of truth... Do not duplicate its content here'), and move conditional branches out of the main file. However, SKILL.md -> CHECK-MODE.md -> VALIDATOR.md is a two-level reference chain, and the 580-line main file still inlines large config-resolution and language-policy blocks that could live in a reference — good structure with minor organization gaps, anchor 4 rather than the one-level-deep ideal of anchor 5. | 4 / 5 |
Total | 17 / 20 Passed |