Content
71%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 dense, disciplined orchestration skill: concrete commands, ordered per-lane workflows, explicit verification gates, and clear conditional boundaries, with almost no token waste in the prose itself. Its two real weaknesses are structural — a 345-line single-file body that inlines lane-specific and tracker-specific material which belongs in reference files, and duplicated handoff/sync contract text repeated across four sections.
Suggestions
Move lane-specific detail into reference files (e.g. references/tracker-rules.md for GitHub/Linear sync-back and changeset blocks, references/editor-candidates.md for the Plate/Slate/Lexical mapping) and keep SKILL.md as the overview, which would cut the body roughly in half.
State the PR/tracker-sync and final-handoff contract once in a single section and reference it from the other sections instead of restating it in Tracked Task Rules, Verification, Post Back To Tracker, and Final Handoff.
Add an explicit error-recovery loop for code-changing work (e.g. "if targeted tests fail, fix and re-run before creating the PR") to close the workflow-clarity gap.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is terse, imperative, and never explains concepts Claude already knows, but the PR/tracker-sync contract is restated in Tracked Task Rules, Verification ("If verified work changed code, create or update the PR before tracker sync-back"), Post Back To Tracker, and Final Handoff, and editor-candidate guidance repeats across Intake, Performance, and Framework Comparison. Anchor 4 fits; not 5 because that duplication could be consolidated, not 3 because there is no padding or over-explanation. | 4 / 5 |
Actionability | Concrete, executable guidance dominates: the autogoal bash invocation ("node .agents/skills/autogoal/scripts/create-goal-scratchpad.mjs --template major-task"), "gh issue view" / "gh pr view" fetch rules, the exact changeset auto-release blocks, and specific paths like "@docs/analysis/editor-architecture-candidates.md". Anchor 4 fits; not 5 because key contracts are delegated without content ("follow the same terse final handoff contract as task.mdc") and a few directives stay abstract ("Keep comment-back QA-focused"). | 4 / 5 |
Workflow Clarity | Intake is a 17-step numbered sequence with input classification, each execution lane is an ordered list, and the Verification section plus Success Criteria checklist provide explicit checkpoints. Anchor 4 fits; not 5 because error-recovery feedback loops (e.g. "if verification fails, fix and re-run") are never made explicit, and the flow frequently branches on conditions stated across distant sections. | 4 / 5 |
Progressive Disclosure | There are no bundle files at all, and the entire skill is one ~345-line monolith in which lane-specific detail that belongs in reference files is inlined: the editor-framework candidate mapping, the GitHub/Linear tracked-task rules, and the changeset auto-release markup. Anchor 3 fits; not 2 because section structure is clear and well-organized rather than minimal or buried, not 4 because substantial content that should be split out is inline with no one-level-deep references. | 3 / 5 |
Total | 15 / 20 Passed |