Content
67%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.
The body is a well-structured, jargon-consistent orchestration skill: two explicit numbered workflows, real feedback loops (fix findings → rerun proof), and a hard approval gate before any mutation. Weaknesses are redundancy — the same no-review-branches and approval-scope rules are repeated across three sections — and subjective thresholds ("meaningful code changed", "clean enough") where explicit criteria or example commands would help.
Suggestions
Consolidate the repeated rules (no `autoresearch-review/*` branches, explicit-approval scope, session-artifact exclusion) into one "Boundaries" section referenced from the workflows instead of restating them in Contract, Current Tree, and Review And Commit.
Replace subjective gates with explicit criteria or heuristics — e.g. define "meaningful code changed" (touched files outside `autoresearch.*`/dashboards) and what "clean enough" means (no open P0/P1 in scope).
Add one example invocation each for the proof gate and the autoreview run so the pre-commit path's steps 2-3 are copy-adaptable rather than only named.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and free of concept-explaining filler, but the same rules are restated across sections: "Do not create `autoresearch-review/*` branches" appears in Contract, Current Tree (via "Do not run `finalize-autoresearch.mjs <plan>` unless the user explicitly asks"), and Review And Commit; the explicit-approval scope is spelled out twice (Contract and Review And Commit). Consolidating these repetitions would tighten the ~128-line body, matching the 'mostly efficient but could be tightened' anchor. | 3 / 5 |
Actionability | Concrete sub-command references are given: "`finalize-current-tree --exclude-session-artifacts` preview/readiness only", "run `autoreview` against the uncommitted `.tmp/slate-v2` diff", "`finalize-autoresearch.mjs <plan>`", and "use normal repo `git` commands directly". Not 5 because gate execution and thresholds are left as judgment calls ("the narrowest relevant `slate-ar-gate` proof", "when meaningful code changed", "clean enough") with no example invocations; not 3 because the guidance names specific tools, flags, and paths rather than staying abstract. | 4 / 5 |
Workflow Clarity | Two clearly sequenced numbered flows (the 8-step default no-arg path and the 7-step pre-commit current-tree path) with explicit checkpoints and a feedback loop: "fix accepted P0/P1 findings that are in scope, then rerun the focused proof" and "only after review/proof is clean or blocked with accepted residual risk, print `READY TO COMMIT` and pause". The destructive step (commit) is properly gated by the approval pause, so the level-3 cap does not apply; held at 4 because gates like "clean enough" and "when meaningful code changed" remain subjective rather than explicit validation criteria. | 4 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are absent), and the body is instead well-sectioned (Contract, Current Tree, Pre-Commit Current-Tree Review, Review And Commit, Handoff) with no nested references, delegating detail to named sub-skills (`slate-ar`, `slate-ar-finalize`, `slate-ar-gate`, `autoreview`). This fits 'good structure; most content appropriately placed; minor organization gaps' — the main gap is that repeated cross-section rules are inlined rather than consolidated, and at 128 lines it exceeds the under-50-line simple-skill case that would warrant a 5 from sections alone. | 4 / 5 |
Total | 15 / 20 Passed |