Conciseness

The body is dense with project-specific knowledge Claude cannot know (entry-point components, BuildParam placement rules, extension vs. core import conventions) and avoids explaining general concepts. It is not a 5 because the ~30-line MyEntity value-object class in 'Shared Domain Layer' is boilerplate Claude could write itself — only the convention that entities live in shared/ needed stating.

Actionability

Mostly executable, copy-paste-ready guidance: the top-level component, BuildParam declaration as React props, consumption in webiny.config.tsx, package structure, and checklist all give concrete code. Not a 5 because the src-extension guidance is contradictory — the RULE section demands ".ts or .tsx extension in every src prop" with a `.ts` example, while all code blocks and the checklist mandate `.js` extensions ("Use .js extensions in all import paths (ESM)"), leaving the reader to guess which is correct.

Workflow Clarity

The six-item Checklist gives a clear construction sequence, and the RULE section supplies strong preventive checkpoints by naming exact failure modes ("Omitting the file extension will cause a build failure", "Bypassing these entry points will fail at runtime"). Below a 5 because there is no explicit verification step (e.g., run the build to confirm registration) after the steps.

Progressive Disclosure

The body is a well-organized overview with TL;DR, rules, structure, code, checklist, and quick reference, and it consistently delegates layer-specific depth to sibling skills ("see webiny-api-architect", "see webiny-admin-architect") — one level deep, clearly signaled in the body, checklist, and Quick Reference. No bundle files exist to house further detail, and none are needed at this scope; navigation is easy.

Specificity

The description lists several concrete structural elements — "the top-level component with Api.Extension and Admin.Extension entry points, shared domain layer, BuildParam declarations, and package structure" — which comprehensively mirror the body's coverage. It stops short of a 5 because these are named components rather than concrete actions (e.g., 'create', 'register', 'declare'), leaving minor coverage gaps in what the skill actually does.

Completeness

It explicitly answers both questions: the 'what' is concrete ("Full-stack extension skeleton and registration pattern... top-level component with Api.Extension and Admin.Extension entry points, shared domain layer, BuildParam declarations, and package structure") and the 'when' is an explicit trigger clause ("Use this skill when creating an extension that spans both API and Admin"), matching the anchor-5 example pattern.

Trigger Term Quality

Good natural keyword coverage: "creating an extension that spans both API and Admin", "full-stack", "extension", "API and Admin" — phrases a developer would plausibly say. However it never mentions "Webiny" or familiar artifacts like "webiny.config.tsx", so a few natural trigger terms users would actually use are missing.

Distinctiveness Conflict Risk

The niche is clearly delimited: 'spans both API and Admin' distinguishes it from single-side skills, and it explicitly states "References webiny-api-architect and webiny-admin-architect for layer-specific details", which both sharpens the boundary and reduces wrong-skill triggering. Not below 5: no generic language that would overlap with unrelated skills.