What this prompt does
This prompt asks the model to act as a senior Vue engineer and produce production-grade Composition API patterns applied to a real feature, returning working code rather than pseudocode. You set the [feature], the [state_library], the [api_layer], and the [ts_strictness], and it returns reusable composables, a store design, component-communication patterns, async data handling, typed routes, and the feature wired together end to end.
The structure works because Composition API code rots fast when every developer invents their own composable and store shape. By pinning composables like useFetch and useForm against [api_layer], a clear [state_library] store design, and typed routes under [ts_strictness], the prompt locks a consistent pattern the whole team can follow. The [feature] ties it together so the patterns are demonstrated in context, not in the abstract. The component-communication guidance — when to use props, emits, or provide/inject — removes the guesswork that usually leads each developer to a slightly different convention.
When to use it
- You're starting a Vue 3 feature and want a consistent Composition API pattern.
- Your team keeps inventing different composable and store shapes.
- You need composables for fetching and forms with loading and error state.
- You want a clear rule for what the store owns versus derives.
- You need typed routes checked at build under strict TypeScript.
- You want async data with Suspense, fallbacks, and cancellation on unmount.
- You want a reference implementation future features can copy from.
Example output
Expect the composables, the store, and the feature components, each fenced and copy-ready. You'll get useFetch and useForm built against your [api_layer] with loading and error state, a [state_library] store with structure, getters, and actions, component-communication patterns (props, emits, provide/inject) with guidance on when to use each, Suspense-based async handling, typed routes under [ts_strictness], and your [feature] wired together using all of it. Each block is fenced and copy-ready, so you can lift the pieces directly into the project and adapt them to the feature you're actually building.
Pro tips
- Spend your effort on the store design — a clear rule for what
[state_library]owns versus derives is what keeps state from sprawling as the app grows. - Set
[api_layer]to your real client (e.g. a typed Axios client) so the composables match how you actually call the backend. - Use a concrete
[feature]like an authenticated dashboard so the patterns are demonstrated in a realistic context. - Set
[ts_strictness]to your true config (e.g. strict mode, no implicit any) so typed routes are checked the way your build will check them. - Don't skip cancellation on unmount; async data without it leaks and causes stale updates.
- Treat the output as the team's reference pattern, not a one-off, so future composables follow the same shape.
