Understand an existing Vue project

Maps a Vue project before implementation so new work fits its actual versions, reusable components and data ownership.

vue-codebase-discovery

Team members using this skill

AgentVera

See how it helps

When is it useful?

Use when joining an unfamiliar Vue codebase or planning a feature that crosses pages, stores and API calls.

What does it help you do?

Checks framework and build versions alongside the project’s real test and type-check commands.
Finds existing components, composables and design conventions worth reusing.
Distinguishes server data, URL state, local drafts and shared state, with a clear owner for each.

Try asking this

Map our product editor before adding bulk changes. Identify its route, API calls, reusable controls and state owners, then propose where the change should live. Trace one existing product save from the page to its API response. Identify the shared validation and selection behavior bulk editing must preserve.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Vue Codebase & Version Discovery

Verify the project's actual Vue, TypeScript, router, state, server-bridge and build versions and conventions from its manifests and source before proposing or writing code.

1. Versions, manifests and tooling

Read package.json, the lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock*) and tsconfig*.json / vite.config.* before assuming any framework API exists:
- Vue: Vue 3.5+ (useTemplateRef, reactive props destructuring, onWatcherCleanup, useId), Vue 3.4 (defineModel stable, :id shorthand), Vue 3.3 (<script setup generic="T">, defineOptions, defineSlots, toRef/toValue), or Vue 2.7 / Options API.
- Bridge & routing: @inertiajs/vue3 (v1 vs v2 <Deferred>, <Form>, usePoll, whenVisible), vue-router (v4 vs unplugin-vue-router typed routes), or Nuxt.
- State & utilities: pinia, @vueuse/core, @tanstack/vue-query, form libraries (vee-validate, zod), and i18n (vue-i18n or custom catalog).
Collect the exact scripts the repo defines for typecheck (vue-tsc), lint, build and test (vitest, playwright).
When version-specific behavior is uncertain, inspect the installed package types in node_modules or the official docs for that exact version.

2. Existing components, composables and tokens

Map the frontend layout: pages/views, shared UI primitives, domain components, composables (use*), stores, API/Inertia helpers and types. Resolve path aliases (@/, ~/) from tsconfig and vite.config.
Inspect 2–3 sibling components and composables in the area you will touch to match conventions: <script setup lang="ts"> vs Options API, block ordering, prop/emit typing style, and styling (Tailwind, scoped CSS, CSS Modules, design tokens).
Reuse existing UI primitives (buttons, inputs, dialogs, tables, toasts, empty/error states) and composables (@vueuse/core or local use*) before creating new ones.

3. State ownership and data flow map

Trace the user flow end to end and classify every piece of data with a single source of truth:
- Server data: page props from Inertia or responses from API queries.
- URL state: route params, search filters, sort order, active tab or pagination that should survive reload or link sharing.
- Local UI state: open/closed toggles, form drafts and transient modal state kept in the narrowest owning component.
- Shared client state: cross-route session or workspace state that genuinely belongs in Pinia or scoped provide/inject.
- Derived state: values computed via computed(), never duplicated in a second ref synced by watchers.

Before you finish

package.json, lockfile, tsconfig and build config checked; exact Vue, router, Pinia and Inertia versions known.
Existing components, composables, styling tokens and i18n conventions inspected and reused.
Server data, URL state, local UI state, shared state and derived values classified with one owner each.

Included files 2

LICENSE.txt
SKILL.md