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 dense, token-efficient standards rulebook that assumes Claude's competence and defers stack-specific detail to well-signaled, verified one-level-deep references loaded on demand. Its weaknesses are the absence of an explicit application sequence — the flow from loading references to shipping must-fail controls is implied rather than stated with checkpoints — and a fair share of abstract doctrine alongside the concrete rules.
Suggestions
Add a short ordered "How to apply" sequence near the top (load the affected stack references → apply rules during the change → ship tests with must-fail controls → clean up dead paths) so the implied workflow becomes explicit with checkpoints.
Convert § Prove Your Guards' prose paragraph into a numbered control procedure (create the disposable copy in `mktemp -d` → run only the changed rows → expect the failure → remove the directory) so its validation loop is scannable rather than embedded in a wall of text.
Pair the abstract doctrine sections (Core Principle, Over-Engineering) with one concrete example each, e.g. a sample must-fail control or a before/after ownership snippet, to lift actionability without adding padding.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is a lean rulebook with zero padding: no concept explanations, no restatement of things Claude already knows, and every line states a rule (e.g., "Acquire ownership before registering cleanup. A pathname alone grants no right to replace or delete a file"). This matches the "lean and efficient; every token earns its place" anchor; there is no over-explanation that would justify 4. | 5 / 5 |
Actionability | Much of the guidance is concrete and checkable — "Put the disposable copy in a `mktemp -d` directory", "set `CARGO_TARGET_DIR` for the control's build", "pinned `text eol=lf` in `.gitattributes`", "a Windows sharing violation (winerror 32…)" — matching the mostly-executable anchor. It is not 5 because sections like Core Principle and Over-Engineering are abstract doctrine ("Do not trade correctness for a smaller change") with no concrete mechanism; it is above 3 because the majority of rules name specific commands, files, or error identities. | 4 / 5 |
Workflow Clarity | The skill's flow — load stack references, apply the rules, ship tests with must-fail controls, clean up — is implied by section order ("Before changing code, load the reference for each affected stack") but never laid out as a sequence with checkpoints; validation exists as doctrine ("A required gate refuses when it cannot read or evaluate its evidence") rather than as explicit checkpoints in a stated workflow. This matches the "sequence present but checkpoints missing or implicit" anchor; it is above 2 because § Prove Your Guards does describe a concrete control procedure with verification, and below 4 because no ordered workflow is ever presented. | 3 / 5 |
Progressive Disclosure | SKILL.md is an overview of core doctrine with stack-specific detail correctly split into four verified one-level-deep references (references/rust.md, bash.md, typescript.md, ui.md — all real files with substantive content), clearly signaled in § Language Discipline with load-on-demand guidance ("Load only the references for the code being changed"). This matches the "clear overview with well-signaled one-level-deep references" anchor; there is no nesting or buried content that would justify 4. | 5 / 5 |
Total | 17 / 20 Passed |