Content
70%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-engineered orchestrator skill with an exceptionally clear staged workflow, explicit gates, and acceptance criteria, plus mostly concrete invocations. Its weaknesses are redundancy (heartbeat doctrine and helper-resolution chains repeated inline) and a long monolithic body that inlines content the referenced shared files already carry.
Suggestions
State the external-cadence/heartbeat doctrine once (in the dedicated 'Overnight heartbeat' section) and reduce the opening blockquote to a two-line pointer to shared-references/external-cadence.md — the full doctrine currently appears twice.
Collapse the three repetitions of the canonical helper-resolution chain into one: define it once (or in a referenced integration-contract file) and refer to it from the heartbeat and resumable-runs sections.
Define the runtime variables ($ROOT, $RUN_ID, $STAGE, $N_NEW_FINDINGS, $CHOSEN_IDEA_TITLE) once at the top of the body, and write the run_state.py state-transition commands with their full script prefix so they are copy-paste executable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense operational instruction rather than concept explanation, but there is noticeable duplication: the external-cadence/heartbeat doctrine appears both in the opening blockquote and again in full in the "Overnight heartbeat" section, and the canonical helper-resolution chain (`.aris/tools → tools → $ARIS_REPO`) is stated three times, including a 7-line shell block. This fits the 3 anchor (mostly efficient but could be tightened) better than 2 (no pervasive padding) or 4 (only minor trims needed). | 3 / 5 |
Actionability | Mostly executable guidance: exact slash-command invocations with argument passthrough (e.g. `/experiment-bridge "$CHOSEN_IDEA_TITLE" — code review: $CODE_REVIEW, base repo: $BASE_REPO`), concrete `run_state.py` invocations, and a filled-in report template. Minor gaps keep it below 5: state transitions are written in shorthand (`set <run_id> <phase> running` without the script prefix) and variables like `$ROOT`, `$RUN_ID`, `$STAGE`, `$N_NEW_FINDINGS` are used without being defined anywhere. | 4 / 5 |
Workflow Clarity | Stages 1-5 are clearly sequenced with explicit gates, each gate's blocking vs non-blocking behavior is spelled out under AUTO_PROCEED, acceptance criteria are tabulated per phase, and there are feedback loops throughout (re-run failed stages, re-audit done-but-unaccepted stages, review rounds with an explicit STOP condition, bounded 3-attempt debugging). This matches the 5 anchor (clear sequence, explicit validation, feedback loops, checklists). | 5 / 5 |
Progressive Disclosure | References are clearly signaled with markdown links (external-cadence.md, resumable-runs.md, output-versioning/manifest/language protocols), but no bundle files exist in the skill directory and the linked shared-references/templates are not resolvable here. Moreover, material that belongs in those referenced files — the full heartbeat doctrine and the multi-line shell helper-resolution chain — is duplicated inline in the ~390-line body. This fits the 3 anchor (references present, but content that should be separate is inline) rather than 4's 'appropriately placed' or 2's 'references buried'. | 3 / 5 |
Total | 15 / 20 Passed |