# Aurelia Expert > Use ONLY when working in an Aurelia v2 project — branch picks the right pillar skill for scaffold, resolve, assemble, slice, lift, package, or wire questions on Aurelia 2.x MVVM SPAs. Use when starting an Aurelia app, choosing between Aurelia skills, structuring a large SPA, dependency injection, routing, migration from v1, debugging, performance, building a component library, packaging a plugin, wiring first-party plugins (fetch-client, validation, dialog, state, i18n), forms, testing, SSR/prerendering, or AI-assisted Aurelia scaffolding. Front-loads the leading word "branch". - Skill: `expert-vision-software/aurelia-expert` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add expert-vision-software/aurelia-expert` - Raw SKILL.md: https://api.skillmd.com/api/skills/expert-vision-software/aurelia-expert/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - License: MIT - Author: Expert-Vision-Software (https://skillmd.com/u/expert-vision-software) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/expert-vision-software/aurelia-expert --- For SDK and API questions, prefer GitHub (aurelia/aurelia `master` branch) as the canonical source for the latest. Use the DeepWiki MCP server (`deepwiki_ask_question` against `aurelia/aurelia`) when available — it provides AI-grounded answers rooted in current source. Fall back to docs.aurelia.io for overview content only. # Aurelia Expert — Router A thin router. It reads the prompt, classifies it as one of seven branches, and hands off to the named pillar skill. It holds no Aurelia domain content itself. The seven branches — scaffold, resolve, assemble, slice, lift, package, wire — map one-to-one to the seven pillar skills. The router's job is to pick the right one and stop. ## Branch detection ladder Read the prompt. Match the first branch whose trigger is present. Use the order below so more specific branches win over generic ones. 1. **scaffold → `aurelia-foundation`.** Triggers: "start an Aurelia project", "what is Aurelia's philosophy", "name a component", "scaffold a new feature", "create a custom element", "use AI to scaffold Aurelia". 2. **resolve → `aurelia-runtime`.** Triggers: "inject a service", "resolve dependency", "add a route", "configure AppTask", "share state between features", "navigate programmatically". 3. **assemble → `aurelia-component-library`.** Triggers: "component library", "design system", "UI kit", "extract components into a library", "CSS variables for components", "tokens", "Tailwind component library", "shared button kit". 4. **slice → `aurelia-largespa`.** Triggers: "structure a large Aurelia app", "feature-first layout", "organize folders", "split into features", "share code across features", "configure Agents.md", "scale an Aurelia SPA". 5. **lift → `aurelia-migration`.** Triggers: "migrate from Aurelia 1", "lift v1 code", "what changed in v2", "debug this Aurelia error", "optimize performance", "find the canonical doc". 6. **package → `aurelia-plugin`.** Triggers: "create an Aurelia plugin", "ship a plugin to npm", "package.json for an Aurelia plugin", "register(container) plugin", ".customize() plugin options", "turn my component library / feature slice / shared dir into a plugin", "IRenderer / IRendering plugin", "registerHostNode", "peerDependencies aurelia". 7. **wire → `aurelia-ecosystem`.** Triggers: "fetch-client", "HTTP client", "IHttpClient", "validation", "& validate", "dialog", "modal", "IDialogService", "state store", "@aurelia/state", "i18n", "translate", "locale", "form binding", "checkbox", "radio", "select", "model.bind", "matcher.bind", "submit.trigger", "test", "Vitest", "createFixture", "@aurelia/testing", "SSR", "prerender", "hydrate", "SEO render", "sitemap", "robots", "client takeover". ## Handoff Once classified, branch to the named pillar via the `skill` tool. Pass the user's prompt through unchanged. ``` skill({ name: "aurelia-foundation" }) // scaffold skill({ name: "aurelia-runtime" }) // resolve skill({ name: "aurelia-component-library" }) // assemble skill({ name: "aurelia-largespa" }) // slice skill({ name: "aurelia-migration" }) // lift skill({ name: "aurelia-plugin" }) // package skill({ name: "aurelia-ecosystem" }) // wire ``` Hand off the user's prompt unchanged. Leave the pillar's domain to the pillar. Pick one branch; answer from that pillar alone. When two branches both fit (e.g. "migrate this large Aurelia app"), branch to the more specific one first: `aurelia-migration` owns the structural lift, and `aurelia-largespa` answers the post-migration organisation questions that surface once the lift lands. Default to migration; defer to largespa only when the prompt is purely about layout, not the lift itself. Library-building is a third axis of overlap. When the prompt mixes library construction with v1→v2 migration ("move my v1 buttons into a v2 component library"), the more constrained case wins: branch to `aurelia-migration` first so v1 syntax becomes v2-current, then load `aurelia-component-library` to assemble the lifted v2 code into the kit. The component-library pillar's migrate procedure runs the v1-syntax gate before any structural move; honour that gate by lifting first. Plugin-packaging is a fourth axis of overlap, with three sub-rules: - **`aurelia-component-library` vs `aurelia-plugin`:** "assemble" builds the styled kit inside one app; "package" ships resources for cross-app npm distribution. "Build a button kit" → assemble. "Ship my kit as an npm plugin" → package. "Build and ship from scratch" → assemble first, then package. If source is v1 → lift first (migration). - **`aurelia-largespa` vs `aurelia-plugin`:** largespa owns in-app feature-first layout + the `shared/` admission rule; plugin owns the npm distribution boundary. "Organize my shared folder" → slice. "Publish my shared folder as a plugin" → package. - **`aurelia-migration` vs `aurelia-plugin`:** v1 source being packaged → lift first (`aurelia-migration`), then package v2-current code. The plugin pillar's `extract.md` Gate enforces this. ## Precedence The active project's local Aurelia instructions file (its `AGENTS.md`, `CLAUDE.md`, or repo-level conventions) overrides anything this package says. The router does not enforce project rules — the pillar skills do. See [REFERENCE.md](REFERENCE.md) for the precedence surface and where each pillar lives. ## V1 contamination guard `au-northwind` is v1. Reference it for structural patterns only — folder layout, slice boundaries, hierarchical `Agents.md`. Its API surface is v1; lift each adopted pattern through `aurelia-migration` so the result is v2-current. When a v1 API shows up in a prompt or a draft answer (`.delegate`, ``, `PLATFORM.moduleName`, `configureRouter`, ``, `@inject`, `activate/deactivate`), branch to the migration pillar to convert it before answering. ## Closing This router's leading word is **branch**. Same word in the description, in the body, in each handoff, and at the bottom of [REFERENCE.md](REFERENCE.md) — so prompts that say "branch to the right Aurelia skill" land here reliably. The router picks the branch; the pillar owns the answer.