Content
77%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 well-orchestrated router body: concrete commands, explicit bounded verification, clear routing and recovery paths, and disciplined token economy. Its major defect is that the entire disclosed detail layer — all referenced reference/*.md files carrying the actual design guidance — is missing from the bundle, breaking navigation and leaving the core instruction content unverifiable.
Suggestions
Ship the reference/ bundle: all ~26 linked paths (reference/new-work.md, reference/craft-floor.md, reference/routing.md, and every per-command reference in the Commands table) are absent from the provided bundle, so every navigation link in the body dead-ends.
State the 'craft is a deprecated alias for ordinary new-work' note once — either the Commands-table row or the Routing bullet — instead of duplicating it in both places.
Split the overloaded Setup step 1 into the core instruction (run `scripts/impeccable context` once per session) plus a short fallback note covering the Windows `.cmd` launcher and the no-base-dir path, so the primary command is scannable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and assumes competence — no space is spent explaining design concepts Claude already knows — but there is trimmable redundancy: "craft is a deprecated alias for ordinary new-work" is stated both in the Commands table row and again in Routing ("`craft` is a deprecated alias for ordinary new-work and adds nothing"), and Setup step 1 buries the core command in a long chain of qualifications. This is the level-4 anchor ('minor instances ... that could be trimmed'), not level 5, because of that duplication and the overloaded setup sentence. | 4 / 5 |
Actionability | Concrete, executable commands are present throughout — `scripts/impeccable context`, `impeccable pin <pin|unpin> <command>`, `$impeccable hooks <on|off|status|...>`, `$impeccable doctor`, plus a 23-row Commands table and explicit routing rules and a launcher-failure fallback. It falls short of level 5 because the substantive design guidance for the common cases is entirely delegated to reference files ("load its reference ... and follow it") that are not present in the provided bundle, so the executable chain dead-ends in practice. | 4 / 5 |
Workflow Clarity | Setup is a clear numbered sequence (1–3) with an explicit recovery path for launcher failure ("send a separate message before the next tool call ... read existing PRODUCT.md and DESIGN.md"), and verification is an explicit bounded feedback loop ("Build fully, inspect once with a batched round ... fix everything it shows in one batch, confirm with at most one more round, and stop polishing"). Edge-case sequencing is also handled (resume without rerunning `impeccable context` after init; `CONTEXT_STALE` handling). This matches the level-5 anchor: clear sequence, explicit validation steps, and feedback loops for error recovery. | 5 / 5 |
Progressive Disclosure | The body's structure is textbook one-level-deep disclosure — a Commands table mapping every command to a named reference, plus clearly signaled pointers like "read [routing.md](reference/routing.md) and present its context-aware menu" — but scoring against the actual bundle, none of the ~26 referenced `reference/*.md` files exist in the provided bundle (only `scripts/` ships). Every navigation link dead-ends, so the otherwise well-signaled structure is not usable as-is; this sits below level 4's 'references mostly clear' and at level 3's 'some structure but could be better organized'. | 3 / 5 |
Total | 16 / 20 Passed |