Content
82%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 high-quality, pattern-focused skill body: fully executable code for every scenario it claims to cover, explicit non-obvious rules (decoratee ordering, extension requirements, forbidden Result methods), and a mandatory type-resolution gate. The main gaps are the absence of a build/verify feedback loop after implementation and heavy inline content that could be partially moved to reference files.
Suggestions
Add a post-implementation validation step (e.g. typecheck or a local build command) so implementations can be verified and fixed before `yarn webiny deploy api --env=dev` — this closes the missing feedback loop in workflow_clarity.
Move detailed sections (domain error taxonomy, decorator registration, CMS use-case import catalog) into a references/ file and link them from SKILL.md to reduce always-loaded context and improve progressive disclosure.
Deduplicate the default-export rule, which is stated in the Registration section and repeated in the UseCase and Repository Rules lists — state it once authoritatively and reference it.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with executable code and short rules lists, with almost no padding of concepts Claude already knows — e.g. "Never use `result.isError()`, `result.getError()`, or `result.getValue()` — these do not exist" is exactly the kind of non-obvious knowledge a skill should carry. Not 5 because there is mild repetition (the default-export rule appears in Registration and again in two Rules lists; the 'Export as `default`' bullet recurs) and the 8-line one-import-per-line CMS import block could be condensed. Not 3 because the verbosity is minor trimming, not unnecessary explanation. | 4 / 5 |
Actionability | Every section provides complete, copy-paste-ready TypeScript (handler wiring, override, error classes, abstractions with typed error unions, use case implementation, CMS repository, mapper, decorator, feature registration) plus a concrete deploy command (`yarn webiny deploy api --env=dev`) and explicit rules ("decoratee is LAST", "dependencies array does NOT include the decoratee"). Not 4 because the examples are complete and cover all common cases the skill itself enumerates. | 5 / 5 |
Workflow Clarity | The sections form a coherent build sequence (use → override → register → errors → implementation → repository → decorator), and 'Resolving Types (MANDATORY)' gives an explicit 3-step verification sequence with a hard gate ("Only use properties and method signatures confirmed in the source"). Registration warnings ("Omitting the file extension will cause a build failure") act as partial checkpoints. Not 5 because there is no post-implementation validation/feedback loop — no build, typecheck, or test step to confirm the written code compiles, so a failed implementation has no recovery path in the skill. | 4 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are absent), and the body is well-structured with clear section headers; it appropriately delegates permissions to the **webiny-api-permissions** skill and lists five related skills under 'Related Skills', all one level deep and clearly signaled. Not 5 because ~450 lines of pattern detail (error taxonomy, decorators, CMS repository patterns) live entirely inline in SKILL.md where some could be split into reference files to reduce always-loaded context; not 3 because what splitting does exist is clearly signaled and the inline content is cohesive, not buried. | 4 / 5 |
Total | 17 / 20 Passed |