Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →webiny/webiny-full-stack-architect
Full-stack extension skeleton and registration pattern.
Passed 22 of 23 test cases with the skill, and 10 of 23 without it.
and 20 more in the full report
13 fixed9 passed either way0 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
When writing an extension under the `extensions/` folder in a Webiny project, which package paths should be used to import Api and Admin extension registration components?
| Checked | Without skill | With skill |
|---|---|---|
| Imports Api and Admin extension helpers from webiny/extensions or webiny/api | Missed | Passed |
| Avoids importing core package sources like @webiny/app-admin for extensions under extensions/ | Missed | Passed |
The instructions your model reads when the skill loads.
A full-stack extension bundles API and Admin into a single package with a shared domain layer. The top-level component registers both sides via <Api.Extension> and <Admin.Extension>, which point to separate entry-point files. Each side follows its own layered architecture pattern — see webiny-api-architect and webiny-admin-architect skills for details.
This skill applies to both extension developers (working in extensions/) and core developers (working in packages/). The architecture patterns are the same — only the import convention and registration mechanism differ.
Extensions (extensions/) | Core (packages/) | |
|---|---|---|
| Imports | webiny/api, webiny/admin, webiny/admin/ui | @webiny/feature/api, @webiny/app-admin, @webiny/admin-ui |
| Catalog paths | Use the Import: path | Use the Source: path |
| Registration | <Api.Extension src={...}> / <Admin.Extension src={...}> in webiny.config.tsx | createFeature registered directly by the package's module initializer |
| Entry point export | Files targeted by Extension src MUST use export default | No restriction — features are registered programmatically |
| Top-level component | Required — composes <Api.Extension> + <Admin.Extension> | Not applicable — each package registers its own features |
Detect which context you're in by checking the file path: extensions/ → extension mode, packages/ → core mode.
Admin extensions CANNOT be directly mounted in
webiny.config.tsxor in any child component tree without going through<Admin.Extension />.
The same rule applies to API extensions — they must go through <Api.Extension />.
These entry-point components are the only way to register code that runs inside the Admin app or the API runtime. They use the src prop to point to a file that will be loaded in the correct execution environment (browser for Admin, Lambda for API). Bypassing these entry points will fail at runtime because the Admin and API contexts (DI containers, routers, GraphQL registries, etc.) are not available outside their respective runtimes.
YOU MUST include the full file path with the .ts or .tsx extension in every src prop. For example, use src={"/extensions/lead/src/index.ts"}, NOT src={"/extensions/lead"}. Omitting the file extension will cause a build failure.
YOU MUST use export default for the createImplementation() call when the file is targeted directly by an Extension src prop. Using a named export (export const Foo = SomeFactory.createImplementation(...)) will cause a build failure. Named exports are only valid inside files registered via createFeature.
// CORRECT — always use entry-point components
<Api.Extension src={import.meta.dirname + "/api/Extension.js"} />
<Admin.Extension src={import.meta.dirname + "/admin/Extension.js"} />
// WRONG — never mount admin/api code directly
<MyAdminComponent /> // Will not have access to Admin DI container
<MyApiFeature /> // Will not have access to API DI container
test cases passed, vs 10 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.