Content
81%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.
Highly actionable content with an exemplary validated workflow for a batch-orchestration skill — executable commands, explicit pre-flight gates, and robust failure/recovery loops throughout. The main weakness is token efficiency: duplicated guidance across three sections and internal migration/history notes that could be consolidated or removed.
Suggestions
Consolidate the "When to Use", "Comparison with /run-experiment" table, and the trailing "Rule" line into one section — the ≤5 vs ≥10 job guidance is currently stated three times.
Merge "Why This Exists" and "Rationale / Source" into a single short rationale; the dated 2026-04-16 audit narrative and wall-clock/token/cognitive sink lists largely repeat each other.
Move the "Phase 3.3 (Arch C)" migration history and legacy "os.execv shim" details out of the main workflow (e.g., a brief "Deprecated paths" note) so the launch instructions stay lean.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly dense and earning its place, but includes unnecessary duplication and padding: the ≤5 vs ≥10 jobs rule is stated three times ("When to Use", the "Comparison with /run-experiment" table, and the "Rule" line), "Why This Exists" repeats "Rationale / Source", and internal migration/date-stamped details ("Phase 3.3 (Arch C)", "os.execv shims", the 2026-04-16 session audit) inflate the token budget without guiding execution. It is above the noticeably-verbose anchor (2) but has clear tightening opportunities. | 3 / 5 |
Actionability | Guidance is fully executable: real bash for binding run identifiers (`PROJECT_DIR="${PROJECT_DIR:?...}"`), ARIS_REPO resolution with explicit error branches, scp/nohup launch commands, `%q`-escaped run_meta persistence, a jq one-liner for status rollup, concrete YAML manifest/grid/phase syntax, and the exact OOM regex `torch\.OutOfMemoryError: CUDA out of memory`. Common cases are covered with copy-paste-ready commands, with placeholders clearly flagged. | 5 / 5 |
Workflow Clarity | The five-step workflow (Parse → Pre-flight → Launch → Monitoring → Post-completion) is clearly sequenced with explicit validation checkpoints: pre-flight gates (SSH, conda env, cwd, preconditions, GPU availability), expected-output-based completion verification, a bounded OOM detect→kill→delay→requeue feedback loop, stale-screen re-evaluation, wave-settlement conditions, and idempotent resume-on-restart. Batch-operation validation is present, so no cap applies. | 5 / 5 |
Progressive Disclosure | Good structure with clear section headers and well-signaled one-level-deep references (`../shared-references/compute-env-contract.md`, `../shared-references/external-cadence.md`, canonical script paths in See Also); no bundle files exist to nest. It falls short of 5 because scheduler internals, the comparison table, and the rationale narrative are inlined in a ~400-line SKILL.md where some content (e.g., legacy-shim migration notes) could be split out or dropped. | 4 / 5 |
Total | 17 / 20 Passed |