CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

webiny-admin-architect

Admin-side architecture patterns for Webiny extensions. Use this skill when building frontend features with headless features (UseCase/Repository/Gateway), presentation features (Presenter/ViewModel/hooks/components), MobX-based presenters, RegisterFeature, and Admin BuildParams. Covers the admin/ directory structure for both features/ and presentation/ layers.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A dense, high-signal architecture reference: almost everything is proprietary Webiny convention rather than general knowledge, and the code examples are concrete and executable. Its main weaknesses are the monolithic all-inline structure with no reference files and a few incomplete example snippets.

Suggestions

Split the long implementation templates (Repository, Gateway, Observable Service, ~150 lines of near-duplicate class code) into one-level-deep files under references/ with clearly signaled pointers from SKILL.md.

Complete the elided snippets — finish CurrentThingPresenter.init() and add the missing useCurrentThing.ts hook example shown in the directory tree.

Add a short ordered 'building a new feature' checklist (abstractions -> implementation -> feature.ts with resolve -> RegisterFeature -> hook/component) to tie the pattern sections into a single build sequence.

DimensionReasoningScore

Conciseness

Nearly every section teaches project-specific conventions Claude cannot know (mandatory resolve, the createReactiveComponent/observer rule, decoratee-last constructor), but the Observable Service and Repository sections repeat the same makeAutoObservable/runInAction pattern and the JSX Bad/Good trio is slightly padded — minor trims keep it below 5.

4 / 5

Actionability

Code is near copy-paste ready with real imports and types across abstractions, feature registration, useFeature hooks, presenters, and a fully typed GraphQL gateway; minor gaps — CurrentThingPresenter.init() ends in '// ... update vm' and the useCurrentThing.ts hook shown in the directory tree is never demonstrated — hold it at 4 rather than 5.

4 / 5

Workflow Clarity

Not a sequential or destructive workflow, so the validation cap does not apply; there is a clear decision point (extensions/ vs packages/ detection) and a logical progression from working context to directory structure to entry point to feature patterns to rules. It lacks an ordered 'build a new feature' sequence or verification step, which keeps it below 5 but comfortably above 3.

4 / 5

Progressive Disclosure

No references/, scripts/, or assets/ files exist — all content is inlined in a single ~640-line SKILL.md. Sections are well-organized with clear headers and a Key Rules summary, but full implementation templates (Repository/Gateway/Observable Service class code) are inline content that belongs in one-level-deep reference files, matching the 3 anchor.

3 / 5

Total

15

/

20

Passed

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it states a clear what and an explicit 'Use this skill when...' trigger clause with concrete, domain-accurate capability names. The main residual issues are minor — a few natural trigger terms are absent and there is slight overlap with closely related Webiny skills.

Suggestions

Add the core API names users would naturally mention (createFeature, useFeature, createReactiveComponent) to the trigger list to broaden natural keyword coverage.

Clarify the boundary with sibling skills, e.g. note that BuildParam *declarations* belong to webiny-full-stack-architect while this skill covers *reading* Admin BuildParams.

DimensionReasoningScore

Specificity

Names several concrete capabilities — 'headless features (UseCase/Repository/Gateway), presentation features (Presenter/ViewModel/hooks/components), MobX-based presenters, RegisterFeature, and Admin BuildParams' — but stops short of naming key actions like createFeature, useFeature, or decorators, leaving minor coverage gaps between the 4 and 5 anchors.

4 / 5

Completeness

Explicitly answers both what ('Admin-side architecture patterns for Webiny extensions... Covers the admin/ directory structure for both features/ and presentation/ layers') and when ('Use this skill when building frontend features with headless features...') with concrete trigger constructs, matching the 5 anchor.

5 / 5

Trigger Term Quality

'Webiny', 'admin', 'MobX', 'presenter', 'hooks', 'RegisterFeature', and 'BuildParams' are the natural phrases a Webiny admin developer would say, giving good keyword coverage; a few natural terms (React components, createFeature, useFeature, extension) are missing, so it sits at 4 rather than 5.

4 / 5

Distinctiveness Conflict Risk

The niche is clearly distinct (Webiny admin-side features/presentation layering), but sibling skills like webiny-full-stack-architect (which owns BuildParam declarations) and webiny-admin-ui-extensions create minor overlap risk at the edges — e.g., the description claims 'Admin BuildParams' that the body delegates elsewhere.

4 / 5

Total

17

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (647 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository

webiny/webiny-js

Path

skills/user-skills/admin/admin-architect/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.