Content
61%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 a compact, well-structured instruction skill with a genuinely concrete output contract (file tree, JSON schemas, ownership tiers, risk levels). Its weaknesses are the missing how-to procedure — no ordered authoring steps, no worked example of a step entry, and only a weak convergence check as validation — plus dangling references to spec sections and an implementation file that add noise without navigation value.
Suggestions
Add an ordered authoring procedure with validation checkpoints, e.g. 1) classify every file from `code/index.json` into an ownership tier, 2) verify coverage (no file unclassified, no file in two steps unless `shared`), 3) emit steps ordered leaf → shared → route → shell, 4) confirm a `build-test` step is last.
Include one worked example of a `steps.json` entry and an `ownership.json` row so the format is unambiguous and copy-paste ready.
Move or trim the 'Spec §20.3 / §21.3.2' citation and the implementation-file pointer in Status — either cut them or label them clearly as provenance so they don't read as navigable references.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean — sections are short, the output format is specified compactly as a file tree with inline JSON shapes, and it assumes competence without explaining basics. The opening paragraph justifying why the plan exists ("without it the patch path slides into 'refactor everything that looks wrong'") is mild padding that could be trimmed, keeping it below the 'every token earns its place' anchor. | 4 / 5 |
Actionability | The output contract is concrete (file tree, `steps.json` entries as `{ id, files[], rationale, risk }`, ownership tiers, risk levels) and inputs are named, but guidance on *how* to author the plan is incomplete: no ordering strategy, no granularity rules beyond three anti-patterns, and no example of a well-formed step. It is not a 2 because the deliverable spec is specific and checkable, not high-level hints. | 3 / 5 |
Workflow Clarity | The flow is implicit (inputs → author → convergence check) and a convergence criterion is stated ("plan.md is non-empty AND steps.json contains at least one step"), but there is no ordered procedure with validation checkpoints for producing the plan — e.g. verify the ownership classification covers every file in `code/index.json`, or that every step's `files[]` is disjoint. The convergence check is too weak to count as a real validation checkpoint for a multi-file batch operation. | 3 / 5 |
Progressive Disclosure | The skill is under 50 lines with no bundle files, and the sections (Inputs, Output, Convergence, Anti-patterns, Status) are well-organized and appropriately sized for inline content. It falls short of 5 because the body points to resources a consumer cannot navigate from the skill — "Spec §20.3 / §21.3.2" and the implementation path `apps/daemon/src/plugins/atoms/rewrite-plan.ts` — without signaling what to do with them. | 4 / 5 |
Total | 14 / 20 Passed |