These 14 Vue prompts help ChatGPT, Claude, Claude Code and Codex write Vue 3 code the way the current docs describe it: <script setup>, defineModel(), reactivity that survives destructuring, composables, Pinia stores, SSR-safe state, Vitest tests and Vue 2 upgrades. Each prompt is a fill-in template you can paste as is.
General jobs like explaining code or reading a stack trace are in the coding prompts, and plain JavaScript work is in the JavaScript prompts. Nothing here repeats them.
How to use these prompts
Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{language:TypeScript}} means TypeScript unless you change it.
Tell the model your setup before anything else. The Vue 3 minor version matters: defineModel() and the previous-value argument in computed() need Vue 3.4 or later, and reactive props destructure needs 3.5. Also say whether you use the Composition API or the Options API, TypeScript or not, Vite or Nuxt, and Pinia or something else. Put this in your project's instructions file so you don't repeat it in every chat.
Paste the whole single-file component, including <template>, <script> and <style>. Most Vue bugs live in the gap between the template and the script. In an agent, name the file and ask it to run vue-tsc and your test command after each change.
Point the model at the source. The guide at vuejs.org is the reference for current patterns, and naming a specific page in the prompt is the easiest way to steer it away from Vue 2 answers.
How do you write Vue components with the Composition API?
1. Convert an Options API component to script setup
The Vue introduction says: "Go with Composition API + Single-File Components if you plan to build full applications with Vue." This prompt moves one component across without changing what it does.
Convert this Vue {{vue_version:3.5}} Options API component to the
Composition API with <script setup lang="ts">:
{{component}}
Map data to ref, computed to computed, watch to watch, methods to plain
functions and lifecycle hooks to their onX equivalents. Replace props and
emits options with defineProps and defineEmits using type-based
declarations. Keep the template and the public API (props, events, slots)
identical. Then list anything that behaves differently after the change,
such as this-based access in the template or mixins that need a
composable.
2. Design props, emits and v-model
The component v-model guide says that starting in Vue 3.4 the recommended approach is the defineModel() macro.
I'm building a reusable {{component:DateRangePicker}} for our Vue 3 app.
It's used in these places: {{use_cases}}
Design its interface in {{language:TypeScript}}:
- Props with types, defaults and which are required
- Which values should be two-way bound with defineModel (including any
named models like v-model:start) and which should be plain props
- Emitted events with typed payloads
- Slots, with what each slot receives
Show the <script setup> block, a usage example from a parent, and list
the props you decided not to add and why.
3. Split a large single-file component
For the 600-line .vue file that fetches, filters, validates and renders.
This single-file component is too large to maintain:
{{component}}
Propose a split: which child components to extract, which logic should
become composables, and what props, emits and slots connect them. Keep
state as close as possible to where it's used, and give every new
component a multi-word name. Don't change behavior or the parent-facing
API. Show the new files, then a short table of what moved where.
How do you get reactivity right in Vue?
4. Find where reactivity is lost
The props guide notes that passing a destructured prop into watch() "will not work as expected" because you pass a value, not a reactive source. The fix is a getter.
In this component, {{symptom:the chart doesn't update when the filter prop changes}}.
{{component}}
Check every place reactivity could be lost: destructuring a reactive()
object, passing a destructured prop to watch or a composable without a
getter, reassigning a reactive() variable, reading .value too early, and
copying props into local refs once. For each problem, show the line, why
it breaks, and the fix. Then give the corrected component.
5. Replace watchers with computed properties
The computed properties guide says computed getters should only perform pure computation, and that you should not mutate other state, make async requests or touch the DOM inside them.
Review the watch, watchEffect and computed calls in this component:
{{component}}
For each watcher, say whether it only derives a value from other state.
If so, replace it with a computed property. For each computed getter,
flag side effects (mutating state, fetching, DOM access) and move them
into a watcher or an event handler. Keep watchers that sync with
something outside Vue. Show the rewritten script and explain each change
in one line.
6. Write a composable
The composables guide recommends use-prefixed names, accepting refs or getters and normalizing them with toValue(), returning a plain object of refs, and undoing side effects in onUnmounted().
These components repeat the same logic for {{logic:paginated fetching from our API}}:
{{components}}
Extract it into a composable named {{name:usePaginatedList}} in
{{language:TypeScript}}. Requirements:
- Accept plain values, refs or getters for its inputs and read them with
toValue() inside watchEffect or watch so changes are tracked
- Return a plain object of refs so callers can destructure
- Put DOM-only side effects in onMounted and clean them up in onUnmounted
- Handle loading, error and stale responses when inputs change quickly
Show the composable, the updated components and one test.
How should you manage state in a Vue app?
7. Move shared state into a Pinia store
The state management guide recommends Pinia for new applications and notes it is maintained by the Vue core team.
These components share {{state:the cart and its totals}} by passing props
and emitting events through several layers:
{{components}}
Design a Pinia setup store for it. Decide what belongs in state, what
should be a getter (computed), and which actions change it, named after
what the user did. Keep server data fetching in actions, not components.
Show the store in {{language:TypeScript}}, the updated components using
storeToRefs where they destructure, and a unit test for one action.
8. Migrate a Vuex module to Pinia
The same guide says Vuex "is now in maintenance mode. It still works, but will no longer receive new features."
Migrate this Vuex module to a Pinia store:
{{vuex_module}}
Map state, getters, mutations and actions to their Pinia equivalents and
remove mutations by folding them into actions. Keep the same public
names where components rely on them, and list every component call site
that has to change (mapState, mapGetters, this.$store.dispatch and so
on). If the module is namespaced or uses rootState, explain how that
becomes a store-to-store call. Show the new store and a migration
checklist I can follow one module at a time.
9. Fix shared state leaking between SSR requests
The state guide warns that a module-level reactive() store used with server-side rendering is a singleton shared across requests.
We render this Vue app on the server with {{ssr:Nuxt}}. Users sometimes
see another user's data for a moment before the page loads.
Here is how shared state is created:
{{store_code}}
Explain how cross-request state pollution happens here, step by step.
Then rewrite the state so each request gets its own instance (a Pinia
store created per app, or provide/inject from the app root), and show
how the server state is passed to the client without leaking secrets.
List any other module-level variables in the code that have the same
problem.
How do you fix common Vue bugs?
10. Fix list rendering against the style guide
The essential style guide rules say key with v-for is always required on components, and: "Never use v-if on the same element as v-for."
Review the list rendering in this component:
{{component}}
Check every v-for: does it have a stable, unique :key (not the array
index when items can be added, removed or reordered)? Is v-if on the
same element? Fix filtering with a computed list and move whole-list
conditions to a wrapper element. Then show the bugs the old keys could
cause, such as input text or component state jumping to the wrong row.
11. Explain a Vue warning or error
For console warnings you don't understand, from prop mutation to extraneous attributes and hydration mismatches.
I get this warning in the browser console in development:
{{warning}}
Here is the component it points to and its parent:
{{components}}
Explain in plain language what Vue is complaining about and why it
matters. Find the exact line that causes it, give the fix that follows
Vue 3 conventions (for example emitting an event or using defineModel
instead of mutating a prop), and say whether the warning hides a real
bug or is only noise in this case.
How do you test Vue components?
12. Test a component through its public interface
The testing guide recommends Vitest for Vite projects and @vue/test-utils for component tests, and says to "test what a component does, not how it does it": props, emitted events and slots.
Write component tests for this Vue component using {{runner:Vitest}} and
@vue/test-utils:
{{component}}
Rules: test only the public interface (props in, rendered output,
emitted events, slots). Don't assert on internal refs or call private
functions. Don't mock child components; interact the way a user would.
Cover the main flow, an empty state, an error state and one event with
its payload. Use await after triggers so the DOM has updated.
13. Test a composable on its own
Composables that don't render can be tested without mounting a component, unless they use lifecycle hooks or inject.
Write tests for this composable with {{runner:Vitest}}:
{{composable}}
If it only uses reactivity APIs, test it directly. If it relies on
lifecycle hooks or inject, mount it inside a minimal host component and
explain why. Cover: initial state, a reactive input changing, an error
path and cleanup on unmount. Mock only the network or browser APIs it
touches, and use fake timers for anything time based.
How do you upgrade an old Vue 2 app?
14. Plan a Vue 2 to Vue 3 migration
The vuejs.org introduction states that Vue 2 support ended on Dec 31, 2023, and links to the official migration guide.
We have a Vue 2.{{minor:7}} app with {{size:about 300}} components,
using {{stack:Vuex, Vue Router 3 and a UI library}}. Plan the move to
Vue 3.
Here is package.json and a representative component:
{{files}}
Give me: the breaking changes from the official migration guide that
affect this code, ordered by how much work they cause; which
dependencies block the upgrade and their Vue 3 versions or
replacements; a step-by-step plan that keeps the app shippable between
steps; and the first three pull requests I should open. Mark anything
you are unsure applies to our code.
Turn your favorite one into a skill
If you paste the same Vue rules into every chat, make them a skill so Claude Code or Codex applies them whenever the task matches. The composable and reactivity prompts are good first picks. Paste one into the free SKILL.md generator to get a valid SKILL.md in your browser. For accessible markup in your components, the accessibility prompts work with any framework, and the Tailwind CSS prompts help if you style with utility classes.
To keep these prompts one shortcut away, save them in Kipt. Your prompts live as Markdown in a private GitHub repo you own, blanks like {{vue_version:3.5}} stay fillable, and Cmd+K search finds any prompt by name or tag.