Vue composition api architecture review

Vue Composition API Architecture Review

Purpose

Review Vue 3 composables and <script setup> components for the specific defect classes Vue's own documentation calls out — reactivity lost through destructuring, lifecycle hooks registered outside the synchronous setup window, impure computed() getters, and script-setup components that mix data-fetching, business logic, and presentation with no composable extraction — without re-litigating component prop design, template markup, styling, or SSR/hydration concerns in every response. This skill exists so those adjacent concerns stay out of scope and the review stays focused on the documented reactivity-boundary and composable-extraction catalog.

When to use

Use this skill when the user asks to:

• review a new or refactored composable (a use*-prefixed function) before merge,
• diagnose a report that "reactive state doesn't update in the UI" after destructuring a composable's return value,
• review a <script setup> component for organization and whether logic should be extracted into a composable,
• decide whether a given computed() or lifecycle-hook usage is correct.

Do not use this skill for:

• Options API-only codebases with no Composition API usage and no stated migration plan — there is no reactivity-boundary or composable-extraction surface to review,
• SSR-specific security concerns (session/auth-token handling inside composables, hydration mismatches) — hand off to vue-ssr-security-review,
• a bug that requires live reproduction (Vue Devtools reactivity inspection, browser profiling) to confirm — static analysis can identify the missing toRefs()/guard, not prove which specific runtime instance broke.

Context7 Documentation Protocol

• Resolve the Vue library ID with resolve-library-id (matched result: /vuejs/vue) before labeling any specific pattern as a reactivity-loss bug or a composable-convention violation.
• /vuejs/vue is Vue's core source-and-test repository, not the prose docs site. Use query-docs against it to corroborate exact runtime behavior (e.g., the computed({ get, set }) writable-computed shape, reactive()/ref() tracking mechanics) from source and unit tests. It does not reliably surface the narrative guidance in the Composables and Reactivity Fundamentals guides — for that guidance, use the official_docs URLs in this skill's metadata.json and label the claim documentation-based.
• Before asserting a specific destructuring pattern loses reactivity, confirm which construct is being destructured: destructuring a reactive()-returned proxy loses reactivity on primitive-valued properties; destructuring a ref() or a toRefs()-wrapped object does not, because each extracted value is itself a ref. Do not apply a blanket "destructuring is unsafe" rule — check the return type first.
• Read package.json first to confirm Vue 3.x is in use; Composition API and its documented composable conventions (including <script setup>) are Vue 3 features, not Vue 2.
• If Context7 is unavailable, fall back to the official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.

Lean operating rules

• For every composable in scope, first determine whether its return value is intended to be destructured by consumers. If yes, verify it returns individual refs or a toRefs()-wrapped reactive object — a plain reactive() object returned for destructuring is the documented reactivity-loss pitfall, not a style preference.
• For every composable, verify the use* naming convention and verify that lifecycle hooks (onMounted, onUnmounted, watch, etc.) and other composables are called synchronously during the composable's/component's initial setup()/<script setup> execution — not inside an async callback, await-continuation, conditional, loop, or event handler registered after setup has returned. Vue's synchronous-registration requirement is a hard rule, not a lint nicety: a hook registered after an await silently fails to attach to the correct component instance.
• For every computed() in scope, verify the getter is a pure read with no side effects (no state mutation, no async calls, no logging with side effects). A writable computed (computed({ get, set })) is the documented pattern for two-way-bindable derived state — do not flag its set function as an impurity; that is its intended role.
• Review <script setup> components for responsibility mixing: data-fetching, validation/business logic, and presentation-only state all inline with no composable extraction. Flag extraction candidates only when the mixed logic is non-trivial and would reduce duplication or improve testability if extracted — do not flag a component for using one or two local ref()s that have no reuse potential.
• Do not fabricate a reactivity-loss finding without showing the exact destructuring line and the specific property that would stop updating. A finding that only says "this might lose reactivity" without the concrete assignment is not a valid finding.
• Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only).
• Load only the reference needed for the concern in scope.

References

Load these only when needed:

• Review workflow and findings contract — use for the step-by-step review procedure, the reactivity/composable decision tree, and the required output shape.
• Reactivity boundaries — load only when reviewing ref()/reactive()/computed() usage, a suspected destructuring-loses-reactivity bug, or toRef()/toRefs()/unref() interop code.
• Composable and script-setup conventions — load only when reviewing composable naming/structure, lifecycle-hook registration timing, or <script setup> responsibility mixing and extraction candidates.

Response minimum

Return, at minimum:

• the composable(s) and/or component(s), files, and specific call sites in scope,
• ranked findings with file:line evidence, defect category (reactivity-loss, lifecycle-timing, computed-impurity, or extraction candidate), and a concrete fix sketch matching the docs' recommended pattern,
• for every reactivity-loss finding, the exact destructuring line and the property that would stop updating,
• evidence level per finding (repo evidence, documentation-based, or inference),
• verdict (approve / approve-with-notes / block),
• open questions or scope the review could not cover (e.g., "requires Vue Devtools reactivity inspection to confirm at runtime").