Content
63%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 thorough, well-sequenced orchestration skill with genuinely executable commands, explicit validation gates, and real error-recovery loops. Its weaknesses are repetition of the checkpoint semantics across phases, dense jargon-heavy evidence-gate prose, and a monolithic inline structure where templates and gate mechanics belong in separate reference files.
Suggestions
Collapse the repeated per-phase 'When AUTO_PROCEED=true/false' blocks into a single reference to the 'Checkpoint execution rule' section, keeping only phase-specific prompts, to cut significant redundant tokens.
Move the evidence-gate/provisional-receipt mechanics (run_state commands, same-family vs different-family receipt rules) and the markdown templates (Research Brief, REF_PAPER_SUMMARY, final report) into one-level-deep reference files and link them from the body.
Make helper resolution self-contained by inlining the resolver pattern (or a short example invocation) instead of delegating it to '/research-pipeline', so the commands are copy-paste executable from this skill alone.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly skill-specific operational detail Claude would not already know (constants, evidence gates, reviewer receipts), but the AUTO_PROCEED blocking/non-blocking semantics are fully restated at Phase 1, Phase 2, and Phase 4.5 despite the dedicated 'Checkpoint execution rule' section, and the evidence-gate prose (e.g., '--provisional-advances is required because these same-family receipts are explicitly provisional') is dense and repetitive. This matches anchor 3 ('mostly efficient but includes some unnecessary explanation or could be tightened'), not anchor 4 which has only minor trimmable instances. | 3 / 5 |
Actionability | Concrete, near-executable commands are provided throughout: '/research-lit "$ARGUMENTS" — composed: idea-stage/IDEA_REPORT.md', 'python3 <resolved-run_state.py> mark-provisional . <run_id> novelty-check --verdict-id "<agent-or-trace-id>" --reviewer "<actual-reviewer-model>"', and '/render-html "idea-stage/IDEA_REPORT.md" --no-review', plus full output templates and concrete artifact paths. It falls short of anchor 5 because key placeholders (<resolved-run_state.py>, <run_id>) are only resolvable via the external '/research-pipeline' resolver pattern, leaving a dependency gap — anchor 4 ('mostly executable guidance; concrete code or commands with minor gaps'). | 4 / 5 |
Workflow Clarity | Phases 0 through 5.6 are clearly sequenced with explicit validation (the per-stage evidence gate with PASS/BLOCKED outcomes, verdict-gated 'done' marking, 'resume <run_id> from the first non-terminal phase') and genuine feedback loops (negative verdict → 're-run that reviewer-bearing phase'; reviewer unavailable → BLOCKED). This is anchor 4 ('clear sequence with most checkpoints present; minor validation gaps') rather than 5 because helper resolution and reviewer routing depend on external context ('the same resolver pattern as /research-pipeline') that makes the flow not fully self-contained or trivially followable. | 4 / 5 |
Progressive Disclosure | Structure is good: clear section headers, and one-level-deep references that are clearly signaled with markdown links ('[output-composition.md](../shared-references/output-composition.md)', the Output Protocols block, '[Selectable Reviewers](../shared-references/reviewer-backends.md)'). However, the body is a monolithic ~490-line file with the Research Brief template, REF_PAPER_SUMMARY template, final report template, and the dense evidence-gate/receipt mechanics all inlined, content that would be better split into separate files — anchor 4 ('good structure; most content appropriately placed; references mostly clear; minor organization gaps'), short of anchor 5's clean overview-plus-split pattern. | 4 / 5 |
Total | 15 / 20 Passed |