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.
A well-structured operational skill with genuinely executable commands, explicit guardrails, and thorough failure handling. Its main weaknesses are the redundant Scheduling-era scaffolding that describes the skill instead of instructing, and a References section whose items are scattered across multiple headings.
Suggestions
Collapse 'Goal', 'Intent signature', and 'Control-flow features' into the existing 'When to use / When NOT to use' sections; they restate the same routing information in abstract terms ('Branches by prompt ambiguity, vendor auth, cost threshold...') without adding actionable content.
Reorganize so all resource links live under the single 'References' heading — currently invocation.md sits alone there while execution-protocol.md, vendor-matrix.md, prompt-tips.md, and checklist.md appear as loose bullets after the Configuration section.
In 'Failure and recovery', add an explicit retry path (e.g., re-run oma image doctor after auth setup, or re-validate the manifest after a timeout retry) to close the validate-fix-retry loop for batch generation runs.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and never explains known concepts, but the 'Scheduling' scaffolding ('Goal', 'Intent signature', 'Control-flow features') is meta-description of the skill rather than instruction, and 'Intent signature' largely duplicates 'When to use'. It fits anchor 3 (mostly efficient, could be tightened) better than 4, where only minor trims would be needed. | 3 / 5 |
Actionability | Concrete executable commands are given ('oma image doctor', 'oma image generate "<prompt>" --vendor auto --size auto --quality auto --output json', the --reference invocation) plus explicit exit codes, env vars, config keys, and a $0.20 cost threshold with bypass flags. Not a 5 because --size/--quality values and vendor-specific invocation details are deferred to resources rather than covered for common cases. | 4 / 5 |
Workflow Clarity | Entry, Transitions, Failure and recovery, and Exit form a coherent sequence with checkpoints (auth check, cost guardrail, doctor, manifest verification) and per-route failure handling. Not a 5: recovery steps mostly report or surface errors rather than closing a validate-fix-retry loop. | 4 / 5 |
Progressive Disclosure | References are one level deep and purpose-annotated ('resources/invocation.md (selected vendor or reference-image operation only)'), keeping the body an overview. Not a 5: the reference list is split awkwardly — one item under 'References', then a Configuration section, then four more bare resource bullets — and no bundle files are present here to verify the referenced paths resolve. | 4 / 5 |
Total | 15 / 20 Passed |