Content
86%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-architected dispatcher body: lean, safe by default (interactive intake plus a hard rule against running destructive operations itself), with a mode table that names real files and scripts and an output contract that forces validation and rollback into every response. The only weakness is that executable commands for the common modes are entirely delegated to the reference file, so the body alone is not copy-paste ready.
Suggestions
Inline one or two copy-paste commands for the most common path (e.g., the exact `restore-drill.sh` invocation and one schedule-creation command) so the body is immediately executable without opening the reference file.
Make the validate-then-proceed checkpoint visible in the body itself, e.g., after a restore wait for workloads to report Ready before comparing elapsed time to the recovery time objective, instead of leaving the full feedback loop in the reference.
State what to do when a drill exceeds the RTO (tune the schedule vs. escalate) so the drill mode closes its feedback loop at dispatch level rather than only inside the reference.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~35-line body is lean and assumes Claude's competence: it never explains what Kubernetes, Velero, or Flux are, the opening line "A backup is only as good as the last time it was restored" is a single-sentence framing principle rather than padding, and the safety rule "Never run a restore, delete a namespace, or patch a backup location yourself: produce the commands and let the user run them" packs a dense behavioral constraint into one line. This matches the 5 anchor (lean, every token earns its place); the 4 anchor would require trimmable over-explanation, and none is identifiable. | 5 / 5 |
Actionability | Concrete, followable guidance is present — "Run and interpret `restore-drill.sh`", "`velero backup/restore describe --details`", "The protected backup bucket from `examples/backup-dr/bucket`", and specific intake questions ("what must be recoverable (namespaces, volumes, the whole cluster), the recovery point and recovery time objectives"). It falls short of the 5 anchor because the body contains no copy-paste command blocks for install/schedule/restore/dr; the executable detail is delegated to `references/backup-dr.md`, leaving minor gaps at body level rather than the "specific examples cover the common cases" bar. | 4 / 5 |
Workflow Clarity | There is a clear dispatch-level sequence (read reference → dispatch mode → gather RPO/RTO and scope when no args → run mode → end with the output contract) with an explicit validation mandate — "Every mode ends with: … **Validation**, as commands (a drill counts)" — and a measure-against-target loop in "compare the measured time with the recovery time objective"; the `dr` row is ordered ("Flux bootstrap first, read-only backup location, then application namespaces"). The destructive-operations cap does not apply since validation is explicitly required. It does not reach the 5 anchor because the full validate→fix→retry loops and per-mode step detail are not in the body — they live in the reference file. | 4 / 5 |
Progressive Disclosure | The body is a concise overview that delegates all detail to one clearly-signaled, one-level-deep reference with a content map ("Read `references/backup-dr.md` before responding. It holds what Velero does and does not capture (and how GitOps changes that), configuration decisions, the restore drill, cross-cluster DR, rollback and troubleshooting") plus working files in `examples/backup-dr`. This matches the 5 anchor (clear overview, well-signaled one-level-deep references, easy navigation). No bundle files were provided in this review set to verify against, so the score reflects the body's structure as written. | 5 / 5 |
Total | 18 / 20 Passed |