Content
85%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 strong, disciplined body: a clear staged workflow with real validation and re-render feedback loops, well-signaled one-level-deep references to actual files, and almost no padding or explanation of known concepts. The main weaknesses are repeated statements of the 'tools provide facts, not verdicts' principle and bash blocks that rely on variables ($INPUT_DOCX, $FINAL_DOCX, $WORKSPACE) the document never defines.
Suggestions
State the 'the CLI provides facts, not a content-quality verdict; judgment belongs to the model's review' principle once (e.g., in Review) and drop the near-duplicate restatements in the Understand/Build and Deliver sections.
Define or annotate the shell variables used in the command blocks (e.g., INPUT_DOCX=input.docx, WORKSPACE/tmp/candidate.docx) so the inspect/validate/render/deliver snippets are copy-paste ready.
Add one minimal task-specific python-docx example in the Build section (a few lines showing a localized edit) so the core stage matches the concreteness of the CLI stages.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and assumes competence — no library tutorials or format explainers — but the "tools provide facts, never a verdict" principle is stated three times ("The optional CLI provides facts and images, never a content-quality verdict", "Judge the document against the user's requested outcome, not whether a tool ran successfully", "It does not decide whether the prose, facts, design... are good enough; that judgment belongs to the model's review"), which is trimmable repetition. Not 5: those repeated sentences are tokens not earning their place; not 3: everything else is efficient and unpadded. | 4 / 5 |
Actionability | Concrete, executable bash blocks for inspect/validate/render/deliver with real flags, but variables like "$INPUT_DOCX", "$FINAL_DOCX", and "$WORKSPACE/tmp/candidate.docx" are used without ever being defined in the document, and the core Build stage gives no example task-specific Python. Not 5: the commands are not fully copy-paste ready without resolving undefined variables and the build guidance stays at the directive level (though flexibility is justified by "Choose the script structure... that make the current task simplest and most reliable"). | 4 / 5 |
Workflow Clarity | A clear Understand → Build → Review → Deliver sequence with explicit validation checkpoints and feedback loops: render/validate commands, "After changing the candidate, prior images no longer describe the current document; render the new candidate if visual evidence still matters", and "Open relevant full-size page images before making visual claims." The Review section's evidence bullet list acts as a checklist, and destructive operations (source replacement) are guarded ("Replace that exact source only when explicitly requested"). | 5 / 5 |
Progressive Disclosure | The ~90-line body is an appropriate overview, and both references are real files (references/word-specifics.md, references/optional-tools.md), one level deep, each linked at its point of need with an explicit conditional signal: "read [word-specifics.md](references/word-specifics.md) only when relevant" and "See [optional-tools.md](references/optional-tools.md) when one is needed." Advanced commands (compare, annotate, finalize, sanitize) are correctly deferred to the reference instead of inlined. | 5 / 5 |
Total | 18 / 20 Passed |