Content
78%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-structured, lean overview with concrete commands, sensible defaults, and appropriate offloading of examples to a real reference file. Main gaps: no inline ExecConfig/map-reduce example, no explicit error-recovery loop for failed jobs, and an unpinned-version dependency stated inline.
Suggestions
Add a minimal inline ExecConfig example (YAML) in the Map And Reduce section so the map.compile/map.job/reduce structure is executable without opening the reference file.
Add a validation feedback loop after job execution, e.g. check job output/trial artifacts for failures and how to retry or adjust (validation → fix → re-run) to strengthen workflow clarity for batch runs.
Consider moving or framing the Harbor >=0.17.1 version requirement near the First Checks as an explicit compatibility gate (or deprecation note) so time-sensitive version info doesn't read as evergreen guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and imperative with no padding or explanations of known concepts, e.g. "Treat `harbor exec` as agentic map-reduce: it turns loose inputs into Harbor tasks, runs Harbor jobs over those tasks". Not 5: the version pin ("Require Harbor `>=0.17.1`...") is time-sensitive information not placed in a deprecation section, which the guidelines penalize. | 4 / 5 |
Actionability | Concrete executable commands are present ("harbor --version", "harbor exec --help", "harbor exec -p ./input -i \"Write /app/answer.json\" -f /app/answer.json") plus specific flag guidance (--scan/--no-scan, --tasks-dir, --jobs-dir). Not 5: the Map And Reduce section describes config keys (map.compile, map.job) without an inline ExecConfig example, deferring all concrete examples to the reference file. | 4 / 5 |
Workflow Clarity | Clear sequence: First Checks (verify version, inspect command surface) → confirm run parameters → execute → verify artifacts ("Should usually define reducer artifacts explicitly, then verify them"), with checkpoints like "show the exact launch command before running it". Not 5: no explicit feedback loop for handling failed or invalid job output (validate → fix → retry) despite this being a batch-execution workflow. | 4 / 5 |
Progressive Disclosure | Well-organized sections with a single, well-signaled one-level-deep reference: "Read `references/examples.md` when writing concrete commands, config files, or map-reduce examples" — the file exists (172 lines of executable examples) and the purpose/condition for reading it is stated. Not 4: there are no organization gaps; the split between overview body and example file is appropriate. | 5 / 5 |
Total | 17 / 20 Passed |