Content
92%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 well-orchestrated, confirmation-heavy SOP: clear phase sequencing with validation and feedback loops, highly actionable specifics (exact paths, endpoints, request fields), and excellent progressive disclosure into a well-organized reference bundle. The only cost is redundancy in the Core Rules section, where several rules are restated in the phases they govern.
Suggestions
State the 'no second confirmation before submitting the generation job' rule only once — either in Core Rules or in Phase 5 — instead of near-verbatim in both places.
Collapse the three overlapping API-key rules ('Do not default to asking the user to paste API keys into chat' / 'Prefer guiding the user to edit local config files themselves' / 'Do not offer to write API keys into config files') into a single rule such as 'Never handle API keys in chat; have the user edit config files themselves'.
Merge the four Core Rules about server-side model configuration into one sentence — e.g., 'Provider selection is controlled only by OpenMAIC's server-side configuration (openmaic.yml / web app model settings), never by the agent's own key or request-time overrides'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly lean phase-based SOP with no concept explanations Claude already knows, but there is real duplication: the no-second-confirmation rule appears nearly verbatim in Core Rules and again in Phase 5 ('Once setup is complete and the user clearly asks to generate a classroom, do not ask for a second confirmation before submitting the generation job'); the API-key handling is triple-stated ('Do not default to asking the user to paste API keys into chat' / 'Prefer guiding the user to edit local config files themselves' / 'Do not offer to write API keys into config files'); and the server-side-model rule is stated four ways in Core Rules. Not level 3: there is no padding or over-explanation, just redundant rules. Not level 5: not every token earns its place. | 4 / 5 |
Actionability | For an instruction-only skill the guidance is fully actionable: exact config path '~/.openclaw/openclaw.json' with a copy-paste JSONC example, exact verification command 'GET {url}/api/health', exact supported request fields ('requirement', 'materialIds'), cookie-jar reuse instructions, and precise UI steps for obtaining an access code. All remaining executable specifics are deliberately and clearly delegated to the per-phase reference files, which is appropriate rather than a gap. | 5 / 5 |
Workflow Clarity | Phases 0-5 are clearly sequenced with explicit routing at each decision point (mode choice → live-demo/local/extend branches), and validation checkpoints are present throughout: check existing local state and ask whether to keep it, health-check the service before generation, poll the generation loop until success or failure, retry failed jobs, and return to Phase 3 if generation fails on provider/model/auth issues — an explicit feedback loop for error recovery. | 5 / 5 |
Progressive Disclosure | The body is a clean router: each phase signals 'Load [references/x.md]' with a one-line 'use this when' condition, and all six directly referenced files (live-demo, clone, startup-modes, provider-keys, generate-flow, extend) exist in the bundle. The remaining two bundle files (extend-cookbook.md, extend-sdk.md) are reached via extend.md's clearly-signaled branch routing, and live-demo.md reuses generate-flow.md rather than duplicating it. Structure is shallow, easy to navigate, and content is appropriately split. | 5 / 5 |
Total | 19 / 20 Passed |