Content
73%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 an unusually rigorous operational spec: concrete commands, refusal semantics, ledger schemas, validation gates, and feedback loops leave little ambiguity about what to execute or when to refuse. Its weaknesses are padding — dead-seam history, a Korean SSOT quotation, and token-discipline meta-commentary — and the absence of any example payloads (decision.json, synchronous_approval) that would make the model-mediated checks copy-paste verifiable.
Suggestions
Move the design-history context (the dead-in-production findings, the Korean SSOT quote, the two-round critique summary) into a short Background reference file or compress to one line each; the executing model only needs the invariants, not the rationale trail.
Add a minimal example decision.json and its synchronous_approval object so the marker-provenance and execution-meta checks can be verified against a concrete shape rather than prose descriptions.
Consider splitting the M4 VERIFY stage (verify.sh policy + /moai gate superset, ~50 lines) into a VERIFY.md reference — it is a distinct stage and its detail competes with the APPLY-pipeline core in the main body.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The pipeline mechanics are repo-specific and legitimately unknown to Claude, but the body pads with historical justification ("was dead in production: `Applier.Apply` never ran... `CuratorDispatch` had 0 production callers"), a Korean design-report quotation, and a meta "Token discipline" paragraph — mostly efficient but could be tightened. | 3 / 5 |
Actionability | Concrete throughout — `lsel-apply.sh <decision.json>` with exit codes 2/3, the ledger row schema, `verify.sh --proposal-dir <p> --repo-root <r> [--timeout SECS] [--feedback-file <f>]`, the commit message format, and runnable verification commands (`sed -n '22p' internal/harness/applier.go`, grep/tail) — but minor gaps remain, e.g. no example decision.json or synchronous_approval object. | 4 / 5 |
Workflow Clarity | The five-step pipeline is clearly sequenced with hard-refusal checkpoints (exit 2/3, no write), the model-mediated layer adds explicit validations (blocked-status check, marker-provenance check, write-flag re-verify), and VERIFY has a 2-attempt policy, auto-revert, a mandatory `/moai gate` superset, and blocker-report feedback loops — explicit validation with error-recovery loops throughout. | 5 / 5 |
Progressive Disclosure | No bundle files exist, so all content lives in a ~200-line SKILL.md, but it is well-sectioned and every external pointer (spec, design report, characterization tests, hook, curator skill) is clearly signaled and one level deep in a Cross-references section; the inlined M4 VERIFY stage is the main content that arguably belongs in a separate reference file. | 4 / 5 |
Total | 16 / 20 Passed |