Content
88%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, well-sequenced orchestration skill: it assumes Claude's competence, provides copy-paste invocation strings and fill-in templates for every phase, and includes explicit checkpoints, feedback loops, and a hardware safety gate. The main costs are structural repetition of the robotics taxonomy and reliance on out-of-bundle shared references rather than a self-contained references/ directory.
Suggestions
Define the embodiment/task/observation/action taxonomy once (Phase 0) and have the Overview and Phase 1 matrix reference it instead of restating overlapping field lists, trimming roughly 30 lines of repetition.
Move the 'Good Robotics Idea Patterns', 'Weak Robotics Idea Patterns', and 'Filtering Rules' blocks (~50 lines) into a references/idea-filtering.md file, keeping a 3-bullet summary inline in Phase 2.
Vendor the shared protocols (reviewer backends, output versioning/manifest/language) into the skill's own references/ directory so the bundle is self-contained and the links are verifiable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is almost entirely imperative, template-driven content with no explanations of concepts Claude already knows (no 'what is RL/benchmark' padding). It stays at 4 rather than 5 because the embodiment/task/observation/action taxonomy recurs in three places (Overview bullets, the Phase 0 Robotics Problem Frame, and the Phase 1 Landscape Matrix), the pipeline diagram appears in both Overview and 'Composing with Later Work', and the 'Key Rules' section recapitulates constants and filtering rules already stated. | 4 / 5 |
Actionability | Every phase gives copy-paste-ready invocation strings with fully specified arguments (e.g. '/research-lit "$ARGUMENTS — focus venues: CoRL, RSS, ICRA, IROS, RA-L, TRO, Science Robotics"'), plus fill-in templates for the problem frame, pilot design, and final report, and literal checkpoint message templates. Not 4: there are no gaps in executable guidance for the common execution paths. | 5 / 5 |
Workflow Clarity | Phases 0-6 are strictly sequenced with an explicit Execution Rule, checkpoints after Phases 1 and 2 enumerate user-response handling (approve / request changes / no response + AUTO_PROCEED), a degenerate path is handled explicitly ('continue to Phase 4 even if you only produced a pilot plan'), and the one risky operation (real-robot execution) has an explicit confirmation gate. Feedback loops for re-running earlier phases on user request are present, matching the anchor-5 example. | 5 / 5 |
Progressive Disclosure | Structure is good: heavy detail is delegated to sub-skills and shared protocols are behind clearly labeled one-level-deep links ('[Output Versioning Protocol](../shared-references/output-versioning.md)' etc.). It does not reach 5 because the skill ships no local bundle files (no references/, scripts/, or assets/), its protocol links point outside the skill directory to ../shared-references/ which cannot be verified from this bundle, and the ~50 lines of Good/Weak Idea Patterns and Filtering Rules inlined in Phase 2 could live in a reference file. | 4 / 5 |
Total | 18 / 20 Passed |