Content
77%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.
An unusually actionable orchestration procedure: exact contracts (result block, manifest schema), a copy-paste worker prompt template, and a tightly sequenced control workflow with explicit validation gates and feedback loops. The weaknesses are a monolithic ~410-line body that repeats several invariants across sections and inlines schemas/templates that would sit better in reference files.
Suggestions
State the budget-counter invariants (increment/decrement/recompute of spawned and in_flight) once in the manifest Rules section, and have Step 0 and Step 4 reference that rule instead of restating it.
Move the full control-state manifest JSON, the worker result block schema, the worker prompt template, and the reporting format into a references/ file (e.g. references/contracts.md), keeping SKILL.md as a concise overview with clearly signaled one-level-deep links.
Compress the research-unit `not-run` exception in Step 6 from layered prose into a short bulleted eligibility checklist (scope says runtime verification is out of scope; files_changed empty; evidence cites sources; no untested runtime claims).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient with no concept-teaching padding, but key invariants are restated multiple times: budget counter rules appear in the manifest Rules ("Increment `spawned` and `in_flight` on dispatch; decrement `in_flight` when a unit leaves `dispatched`; recompute it from the rows on rehydrate"), again in Step 4 ("increment `spawned` and `in_flight` together... This keeps `in_flight` equal to the count of `dispatched` rows that Step 0 recomputes"), and the subagent-hierarchy rule appears in both the worker template ("Do NOT create or steer further persistent project sessions") and Safety rules ("Worker subagents are leaf helpers — they MUST NOT create or steer further persistent sessions"). The redundancy exceeds the 'minor instances' of anchor 4, but there is no padded fluff or explanation of concepts Claude already knows, so it is above anchor 2. | 3 / 5 |
Actionability | Fully executable, copy-paste-ready guidance: a complete worker prompt template, an exact `control-result` JSON block with strict field semantics, a full control-state manifest schema with field-level rules, concrete enums (`complete | blocked | needs-decision | failed`), and specific thresholds ("Cap at 2 retries, then escalate to the user"). The specific examples cover the common cases (dispatch, result-gate, batch piloting, reporting). | 5 / 5 |
Workflow Clarity | Steps 0–8 are clearly sequenced (rehydrate → frame → detect surface → topology → dispatch → track → route → converge → consolidate) with explicit validation checkpoints: the result-gate parse/validate/reject procedure, a bounded feedback loop (one standardized re-prompt, cap of 2, then escalation), the batch_guard pause/resume loop, and the wave-join completeness gate ("the mission is complete only when every manifest worker row is in a terminal state"). Batch operations have explicit validation, so the batch-cap does not apply; checkpoints are explicit rather than implicit, keeping this above anchor 4. | 5 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are absent) and the ~410-line body inlines everything: two full JSON contract examples, the worker prompt template, and the reporting format. Section structure is good (clear headers, mental model up front, capability table) and the only reference is an internal anchor ("[Machine-checkable contracts](#machine-checkable-contracts)"), but content that clearly belongs in separate reference files is inline, matching anchor 3. Not 4 because there are no one-level-deep references at all for a 22KB skill; not 2 because the file is well-sectioned and navigable, not a monolithic wall of text. | 3 / 5 |
Total | 16 / 20 Passed |