Content
67%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 well-structured, actionable, and assumes Claude's competence, with concrete JSON examples and a clear worked example. Its main weakness is repetition of the write-restriction constraint and some overlap between the seed/classifier sections, which slightly hurts conciseness.
Suggestions
State the '.lha/* cannot be written by the agent' constraint once in a prominent place and refer back to it, instead of restating it in the Default seed, Add-rule, Remove-rule, Worked example, and Notes sections.
Consolidate the 'Default seed' and 'Demotable destructive commands' sections, which both describe what the seed and argv classifier cover, to remove overlap.
Fold the read-back parse-validation step explicitly into the 'add a rule' workflow as a numbered checkpoint rather than relegating it to Notes.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient and assumes Claude's intelligence, but the '.lha/* cannot be written by the agent' constraint is restated across the Default seed, Add-rule, Remove-rule, Worked example, and Notes sections, and the Default-seed and Demotable-commands sections overlap — fitting 'mostly efficient but includes some unnecessary explanation or could be tightened' rather than the trim 4 anchor. | 3 / 5 |
Actionability | Concrete, copy-paste-ready JSON rule examples and a full worked example ('block npm publish') cover the common add/remove cases; the illustrative read(".lha/policies.jsonl") notation is not a real tool call, leaving minor gaps that keep it just below the fully-executable 5 anchor. | 4 / 5 |
Workflow Clarity | Sequenced workflows (list rules → add rule → remove rule) with checkpoints — 'Confirm the target with them first' and the Notes 'read the file back after they save it' validation — give clear sequence with most checkpoints present; it is not 5 because validation is not woven as explicit numbered steps into each workflow. | 4 / 5 |
Progressive Disclosure | Well-organized with clear section headers and one-level-deep, clearly-signaled references to docs/security-model.md and docs/permission-model.md; no bundle files exist so structure is self-contained. Minor organization gaps (some inline detail that could be split) keep it just below the cleanly-split 5 anchor. | 4 / 5 |
Total | 15 / 20 Passed |