What this prompt does
This prompt scaffolds a complete, production-ready Vue 3 feature using the Composition API with TypeScript. You name the [feature_name], spell out [feature_requirements], and set your [styling_approach], [api_pattern], [persist_state], and [test_count], and it generates a coordinated set of files: a composable, a Pinia store, the component, TypeScript interfaces, and Vitest unit tests.
The structure works because it pins the output to modern Vue conventions instead of leaving them to chance. By requiring <script setup>, typed return objects (not tuples), defineProps/defineEmits, and adherence to the Vue Style Guide's Priority A and B rules, the generated code lands close to how an experienced Vue developer would hand-write it — which makes review fast. The [feature_requirements] field drives the actual behavior, while [persist_state] and [test_count] control the persistence plugin and how thoroughly the tests cover happy path, error states, and edge cases.
When to use it
- You're building a new Vue 3 feature and want a full slice — composable, store, types, tests — in one pass.
- You want to enforce
<script setup>and Composition API patterns across a team's output. - You need typed Pinia stores with
$reset()support and optimistic updates as a starting point. - You're adding a feature that needs
[persist_state]for some data (like user preferences) but not others. - You want Vitest tests scaffolded alongside the code so coverage isn't an afterthought.
- You're onboarding to a Vue codebase and want idiomatic reference code that follows the Style Guide.
Example output
You get five coordinated files: a use<FeatureName>.ts composable with reactive state, computed properties, watchers, and typed returns; a [feature_name]Store.ts Pinia store with CRUD actions, getters, and $reset(); a <FeatureName>.vue component using <script setup lang="ts"> with proper props, emits, and scoped styles in your [styling_approach]; a types/[feature_name].ts file with DTOs and union types; and a spec file with at least [test_count] Vitest cases plus integration notes for routing and i18n.
Pro tips
- Make
[feature_requirements]detailed and behavioral — the richer the requirements, the more complete the composable and component logic. - Set
[test_count]to a realistic floor; bump it up if your feature has many error and edge-case branches. - Use
[persist_state]to distinguish what belongs in localStorage (preferences) from transient data (live lists). - Match
[styling_approach]to your real setup so the scoped styles don't need rewriting. - Specify your
[api_pattern]precisely; the composable's loading and error handling is generated around it. - Review the generated tests for genuine assertions — regenerate or extend any that only check that something rendered.
