@mrciphersmith/keryx 0.3.0 → 0.3.1

package/src/gdskills/bundled/stacks/vue/governance/scout.json

@@ -0,0 +1,42 @@
+[
+  {
+    "query": "Use when building or changing a Vue 3 Single File Component, composable, or Pinia store -- covers <script setup> with type-based defineProps/defineEmits, choosing ref vs reactive, computed vs watch/watchEffect, composable extraction, and Pinia store/action design. Not for Options API legacy components (use vue2-to-vue3-migration) or Node.js service/CLI code with no .vue file (use nodejs-implementation).",
+    "decision": "fork",
+    "topMatch": "vue/vue2-to-vue3-migration",
+    "recordedAt": "2026-09-25T06:25:21.007Z",
+    "skillName": "vue-implementation",
+    "justification": "Top match vue2-to-vue3-migration (0.417) shares vue/pinia/component vocabulary inherent to any two skills in the same framework pack, but is scoped to converting legacy Options API code to Composition API, not authoring new Composition API code -- distinct trigger surface (upgrade/convert/migrate prompts vs build/implement prompts), confirmed by clean trigger-accuracy eval. Second match vue-code-review (0.350) is read-only review, not authoring."
+  },
+  {
+    "query": "Use when a Vue 3 component or composable's test suite needs writing, extending, or fixing with Vue Test Utils and Vitest -- covers mount vs. shallowMount, querying by test id/role, awaiting trigger()/nextTick for async DOM updates, asserting wrapper.emitted() payloads, and Pinia test-store isolation with createTestingPinia. Not for plain Node.js/TypeScript unit tests with no .vue mount (use nodejs-testing) or React Testing Library tests (use react-testing).",
+    "decision": "fork",
+    "topMatch": "nextjs-nuxt/nextjs-nuxt-testing",
+    "recordedAt": "2026-09-25T06:25:27.390Z",
+    "skillName": "vue-testing",
+    "justification": "Top matches are sibling vue/* skills sharing pack-level vocabulary (component, pinia, script); nodejs-testing and react-testing (named explicitly as exclusions in the description) target a different mount surface (no .vue SFC / React JSX respectively). Confirmed distinct by clean trigger-accuracy eval against both a react-testing-library prompt and a plain node vitest prompt."
+  },
+  {
+    "query": "Use when reviewing changed Vue 3 Single File Component or composable code (.vue) for reactivity bugs -- lost reactivity from destructuring reactive()/props, missing watch cleanup, prop mutation instead of emit, v-for key misuse, v-html injection risk, and Pinia store boundary violations. Read-only, no repository convention-doc lookup and no MobX/React store review. Not for authoring or fixing the component (use vue-implementation or vue-build-fix).",
+    "decision": "fork",
+    "topMatch": "react/react-code-review",
+    "recordedAt": "2026-09-25T06:25:34.017Z",
+    "skillName": "vue-code-review",
+    "justification": "Overlap is with sibling vue/* skills (shared pack vocabulary) and existing review skills (review-frontend, code-mobx-store-review) that this description explicitly excludes (no MobX/React store review). This skill's scope -- Vue reactivity/prop-emit/Pinia boundary bugs in .vue diffs -- has no existing catalog equivalent. Confirmed distinct by clean trigger-accuracy eval."
+  },
+  {
+    "query": "Use when resolving a vue-tsc template type error, an eslint-plugin-vue lint failure, or a Vite build error in a Vue 3 project -- covers template expression type mismatches, defineProps/defineEmits type errors, unresolved SFC/component imports, and Vite plugin/HMR build failures. Applies the smallest root-cause fix and never silences the checker with an any cast or an eslint-disable. Not for a generic tsc error in a .ts file with no .vue involved (use nodejs-build-fix) or a JSX/React build failure (use react-build-fix).",
+    "decision": "fork",
+    "topMatch": "ts-js-node/nodejs-build-fix",
+    "recordedAt": "2026-09-25T06:25:40.079Z",
+    "skillName": "vue-build-fix",
+    "justification": "Explicitly excludes and is distinct from nodejs-build-fix (plain .ts, no .vue) and react-build-fix (JSX/React) which the description names outright; overlap with sibling vue/* skills is pack-level vocabulary. Confirmed distinct by clean trigger-accuracy eval against both a plain-tsc negative and a react-build negative."
+  },
+  {
+    "query": "Use when migrating a Vue 2 (Options API) codebase or component to Vue 3 -- covers converting Options API to <script setup> Composition API, replacing the removed filters and $listeners/$children APIs, Vuex-to-Pinia store migration, v-model breaking changes (single default to multiple named bindings), global API changes (createApp vs new Vue), and Vue 2 lifecycle hook renames (beforeDestroy -> beforeUnmount). Not for a fresh Vue 3 component with no legacy code (use vue-implementation).",
+    "decision": "fork",
+    "topMatch": "nextjs-nuxt/nextjs-nuxt-upgrade-migration",
+    "recordedAt": "2026-09-25T06:25:46.482Z",
+    "skillName": "vue2-to-vue3-migration",
+    "justification": "Top match vue-implementation (same pack) shares Composition API/script-setup vocabulary but is explicitly excluded (fresh components, no legacy code) and scoped oppositely -- authoring new vs converting legacy. No existing catalog skill covers Vue 2->3 migration specifics (filters, $listeners/$children, Vuex->Pinia, v-model contract change). Confirmed distinct by clean trigger-accuracy eval."
+  }
+]

package/src/gdskills/bundled/stacks/vue/pack.json

@@ -0,0 +1,42 @@
+{
+  "id": "vue",
+  "family": "framework",
+  "extends": "ts-js-node",
+  "modules": ["vue-rules", "vue-skills"],
+  "detectionMarkers": ["vue"],
+  "provenance": {
+    "origin": "authored",
+    "sourceRef": "flow 318, Wave 4 batch 2"
+  },
+  "stability": "experimental",
+  "skills": {
+    "implement": ["vue-implementation"],
+    "test": ["vue-testing"],
+    "review": ["vue-code-review"],
+    "build-fix": ["vue-build-fix"],
+    "migrate": ["vue2-to-vue3-migration"]
+  },
+  "agentProfile": {
+    "displayName": "Vue",
+    "auditFocus": [
+      "reactivity lost by destructuring a reactive()/props object instead of using refs, toRefs, or (Vue 3.5+) defineProps destructuring",
+      "a watch/watchEffect with a missing or wrong dependency, or one left running past the component's lifecycle with no cleanup",
+      "props or emitted events with no type-based defineProps<T>()/defineEmits<T>() declaration, or a mutated prop instead of emitting a change",
+      "v-html rendering unsanitized or user-controlled content",
+      "a Pinia store action mutating another store's state directly instead of calling its own actions, or state read outside a component/setup reactivity scope",
+      "a v-for list with no stable :key, or :key bound to the array index where the list can reorder"
+    ],
+    "buildCommands": [
+      "the project's type-check script (vue-tsc --noEmit or its package.json equivalent)",
+      "the project's lint script (eslint with eslint-plugin-vue enabled)",
+      "the project's test script (Vitest run of Vue Test Utils suites)",
+      "the project's build (vite build, or the framework's own production build)"
+    ],
+    "fixGuardrails": [
+      "never disable or downgrade an eslint-plugin-vue rule to silence a warning",
+      "never cast a component's props, emits, or template expression to any to satisfy vue-tsc",
+      "never delete or loosen a failing assertion in a Vue Test Utils test to make it pass",
+      "never mutate a prop in place as a build-fix instead of emitting an update event"
+    ]
+  }
+}

package/src/gdskills/bundled/stacks/vue/rules/coding-style.mdc

@@ -0,0 +1,73 @@
+---
+extends: common
+paths: ["**/*.vue"]
+metadata:
+  origin: authored
+---
+
+# Vue coding style
+
+Narrows `core-common-rules`' stack-agnostic style rules to Vue Single File
+Component conventions. Applies only to `*.vue` files -- the `<script>`
+block's own TypeScript style still comes from `ts-js-node`'s coding-style
+rule, which this file `extends` transitively through the pack's `extends`.
+
+## Script setup and typing
+
+- Use `<script setup lang="ts">` for new components; do not introduce the
+  Options API or a bare (non-setup) `<script>` block in new files unless the
+  project has no `<script setup>` components at all yet.
+- Declare props with the type-only form, `defineProps<{ ... }>()`, not the
+  runtime-object form (`defineProps({ foo: String })`), so prop types are
+  checked against actual usage instead of a separate runtime shape. Use
+  `withDefaults(defineProps<Props>(), { ... })` for default values rather
+  than mutating the returned props object.
+- Declare emits with the type-only form: `defineEmits<{ change: [id: number]
+  }>()` (named-tuple syntax) rather than the untyped string-array form
+  (`defineEmits(['change'])`).
+- On Vue 3.5+ projects, destructuring `defineProps()` directly
+  (`const { title } = defineProps<Props>()`) is reactive and preferred over
+  a separate `props.title` reference; on pre-3.5 projects, keep the props
+  object intact (`props.title`, or `toRefs(props)`) since a destructured
+  prop is a frozen snapshot, not a live binding.
+- Type `ref<T>()` explicitly when the initial value's inferred type is
+  narrower than the eventual type (`ref<string | null>(null)`, not a bare
+  `ref(null)` that infers `Ref<null>`).
+
+## Naming and structure
+
+- Component file and `name` (when set) in `PascalCase`
+  (`OrderSummary.vue`); composable files and exported function names in
+  `camelCase` prefixed with `use` (`useOrderTotals.ts`).
+- One component per `.vue` file; a template that needs its own local
+  sub-markup repeated more than once becomes its own child component, not a
+  `v-for` over inline duplicated markup.
+- Order SFC blocks `<script setup>`, `<template>`, `<style>` (or the
+  project's existing established order) consistently across the codebase;
+  do not invent a third ordering in new files.
+- Multi-word component names (`UserCard`, not `Card`) to avoid clashing
+  with current and future HTML elements, matching `eslint-plugin-vue`'s
+  `multi-word-component-names` rule.
+
+## Formatting and imports
+
+- Format with the project's configured formatter (Prettier or the
+  project's own config); do not hand-format around a formatter that is
+  already configured.
+- Run the project's configured `eslint` (with `eslint-plugin-vue`) instead
+  of hand-checking template directive order, unused template refs, or
+  v-for/v-if precedence; fix what it flags rather than adding a blanket
+  disable comment.
+- Prefer auto-imported composables/components only when the project has
+  `unplugin-auto-import`/`unplugin-vue-components` (or Nuxt) configured;
+  otherwise import explicitly -- do not assume auto-import is active.
+
+## Errors
+
+- Surface a composable or store action's failure to the caller (thrown
+  error, or a returned error/result shape the caller checks) instead of
+  swallowing it in a bare `catch` with no rethrow and no user-visible
+  state change.
+- Use Vue's `onErrorCaptured` (component-tree scope) or a top-level
+  `app.config.errorHandler` (app-wide scope) for error boundaries, not an
+  ad hoc `try/catch` wrapped around every template-triggered call site.

package/src/gdskills/bundled/stacks/vue/rules/patterns.mdc

@@ -0,0 +1,84 @@
+---
+extends: common
+paths: ["**/*.vue", "**/*.ts"]
+metadata:
+  origin: authored
+---
+
+# Vue patterns
+
+Narrows `core-common-rules`' stack-agnostic design-pattern guidance to
+idiomatic Vue 3 Composition API design and its common anti-patterns.
+Applies to `*.vue` files and plain `*.ts` files alike (R1 review, PR #719,
+M4): a composable (`useX()`) is routinely a standalone `.ts` file, not a
+`.vue` SFC, and the reactivity/composable guidance below (`ref()` vs.
+`reactive()`, lifecycle-hook-in-composables rules, the return-shape rule)
+is exactly what a `.ts` composable needs — `ts-js-node`'s own generic
+patterns rule has no notion of Vue's reactivity primitives at all.
+
+## Reactivity
+
+- Use `ref()` for a single primitive or a value that is often reassigned
+  wholesale; use `reactive()` for a fixed-shape object whose properties are
+  mutated in place. Do not wrap a `reactive()` object in a `ref()` "for
+  safety" -- pick one.
+- Never destructure a `reactive()` object or a raw (non-`defineProps`)
+  props object into loose variables (`const { count } = state`) -- that
+  copies the current value and breaks the reactive link. Use `toRefs()`
+  (whole object) or `toRef()` (one property) when a template or composable
+  needs individual reactive references out of a `reactive()` object.
+- Prefer a `computed()` over a `watch` that just re-derives and assigns a
+  value on every dependency change; reach for `watch`/`watchEffect` only
+  for a genuine side effect (a fetch, a DOM measurement, a log, syncing to
+  an external system).
+- Give every `watch` an explicit, minimal source (`watch(() => props.id,
+  ...)`, not `watch(props, ...)` with `{ deep: true }` when only one field
+  actually needs to be observed) -- a whole-object deep watch fires on every
+  unrelated field change and is expensive on large objects.
+- Stop a `watch`/`watchEffect` created outside a component's own setup
+  scope (e.g. inside a manually managed subscription) using the stop handle
+  it returns; one created directly inside `setup`/`<script setup>` is
+  auto-stopped on unmount and needs no manual cleanup.
+
+## Composables
+
+- Extract a composable (`useX()`) when the same stateful logic (a fetch +
+  loading/error state, a subscription, a computed derivation) is needed in
+  more than one component, instead of copy-pasting the `ref`/`watch` block.
+- Call composables that use lifecycle hooks (`onMounted`, `onUnmounted`,
+  `provide`/`inject`) only from another composable or directly inside
+  `setup`/`<script setup>` -- never from inside a callback, `watch`
+  handler, or `async` continuation after an `await`, where the active
+  component instance is no longer bound.
+- A composable returns refs/computed values and functions, not a plain
+  object of dereferenced values -- return `{ count, increment }` (where
+  `count` is the `ref` itself), not `{ count: count.value, increment }`,
+  or the caller loses reactivity.
+
+## Component design
+
+- Emit an event (`emit('update:modelValue', v)`) instead of mutating a
+  prop in place; a prop is one-way data flow from the parent, and Vue warns
+  at runtime when a child writes to it directly.
+- Use `v-model` (or a named `v-model:propName`) for two-way bindable state
+  instead of hand-wiring a prop plus a separately-named update event when
+  the semantics are genuinely two-way.
+- Keep template `v-if`/`v-for` on the same element simple; when both are
+  needed, wrap the `v-for` in a `<template>` with the `v-if` on each item,
+  or filter the source list in a `computed()`, rather than relying on
+  `eslint-plugin-vue`'s default precedence to make an implicit filter
+  correct.
+- Prefer `provide`/`inject` for state genuinely shared down an arbitrary
+  depth of the component tree (theme, current user); prop-drilling two or
+  three levels does not need it, and a store (Pinia) is the better fit for
+  state shared across unrelated branches of the tree.
+
+## Anti-patterns
+
+- A `ref`/`reactive` object stored in module scope and mutated from
+  multiple unrelated components as an ad hoc global store, instead of a
+  Pinia store with named actions -- it works but loses devtools tracking,
+  action naming, and testability.
+- A deeply nested `reactive()` object mutated from many call sites with no
+  action layer -- prefer a Pinia store (or a composable with named mutator
+  functions) so state changes have one discoverable entry point.

package/src/gdskills/bundled/stacks/vue/rules/security.mdc

@@ -0,0 +1,60 @@
+---
+extends: common
+paths: ["**/*.vue"]
+metadata:
+  origin: authored
+---
+
+# Vue security
+
+Narrows `core-common-rules`' stack-agnostic security rules to Vue-specific
+render-time and routing risks. Applies only to `*.vue` files; server-side
+Node.js concerns (request validation, dependency risk) still come from
+`ts-js-node`'s security rule.
+
+## Template injection (XSS)
+
+- Never bind `v-html` to a value that includes user-controlled or
+  unsanitized content -- `v-html` renders raw HTML with no escaping, so a
+  string containing `<script>`/`onerror=`/etc. executes. Sanitize with a
+  library such as DOMPurify immediately before the `v-html` binding if raw
+  HTML rendering is genuinely required, and keep the sanitize call next to
+  the binding so it cannot be bypassed by a later edit.
+- Prefer interpolation (`{{ value }}`) or bound attributes (`:title="value"`)
+  over `v-html` whenever the content is plain text -- both are
+  auto-escaped by Vue's compiler, `v-html` is not.
+- Treat a dynamic `:href`/`:src` bound to user-controlled input as
+  untrusted: reject or allowlist the scheme (`http:`/`https:`/`mailto:`)
+  before binding it, since a `javascript:` URI in an anchor's `href` still
+  executes on click.
+- Never pass a user-controlled string into `render()`'s `h()` calls as a
+  raw HTML string; `h()` treats string children as text, but a manually
+  constructed VNode tree that re-injects raw markup reintroduces the same
+  risk `v-html` has.
+
+## Routing and SSR
+
+- Validate and narrow a Vue Router dynamic segment (`route.params.id`)
+  before using it in a query, redirect target, or `v-html`-rendered value
+  -- a route param is attacker-controlled input, not a trusted internal
+  value.
+- In a server-rendered (Nuxt or custom SSR) app, never read a secret,
+  session token, or unsanitized request header directly into a `ref`/
+  `reactive()` value that gets serialized into the client-hydrated state --
+  anything in the initial state payload is visible in the page source.
+- Guard a navigation guard's redirect target (`next('/somewhere')` or
+  `router.push()`) built from a query parameter against open-redirect: only
+  redirect to a same-origin, allowlisted path, never an unvalidated
+  `redirect` query value passed straight through.
+
+## Store and state exposure
+
+- Do not store a raw auth token or other secret in a Pinia store field
+  that is included in a `persist`/localStorage plugin without explicit
+  review -- persisted store state survives in the browser's storage past
+  the session and is readable by any script with DOM access on that
+  origin.
+- Scope a Pinia store's `$reset()` (or manual reset) to run on logout for
+  any store holding user-specific data, so a shared browser session (or a
+  test suite reusing app state) does not leak the previous user's data
+  into the next session.

package/src/gdskills/bundled/stacks/vue/rules/testing.mdc

@@ -0,0 +1,69 @@
+---
+extends: common
+paths: ["**/*.vue"]
+metadata:
+  origin: authored
+---
+
+# Vue testing
+
+Narrows `core-common-rules`' stack-agnostic testing rules to Vue component
+and composable testing with Vitest and Vue Test Utils. Applies only to
+`*.vue` files' own tests; a plain `.ts` composable's unit tests follow
+`ts-js-node`'s testing rule unless they mount a component.
+
+## Layout and runner
+
+- Co-locate a component's test next to it (`OrderSummary.vue` /
+  `OrderSummary.spec.ts` or the project's existing `__tests__` convention)
+  -- match whatever the project already does rather than introducing a
+  second layout.
+- Use the project's configured runner (Vitest is standard for Vue 3 /
+  Vite projects) and its already-configured DOM environment (`happy-dom`
+  or `jsdom`); do not add a second test runner or DOM environment for new
+  tests.
+- Use `@vue/test-utils`'s `mount()` for a component that needs its full
+  render tree and child components resolved, and `shallowMount()` only
+  when child components are irrelevant to the behavior under test and
+  stubbing them meaningfully reduces noise.
+
+## Querying and interaction
+
+- Query by test id, role, or visible text (`wrapper.find('[data-testid=...]')`,
+  or `@testing-library/vue`'s `getByRole`/`getByText` when the project uses
+  it) instead of a CSS class or DOM structure selector that changes with
+  styling.
+- Trigger user interaction through Test Utils' `trigger()` (`await
+  wrapper.find(selector).trigger('click')`) or `@testing-library/vue`'s
+  `fireEvent`, and `await` it -- Vue's DOM updates are asynchronous, so an
+  un-awaited trigger asserts against stale DOM.
+- Assert on rendered output and emitted events (`wrapper.emitted('update')`),
+  not on a component's internal reactive state reached through
+  `wrapper.vm` -- `vm` access ties the test to implementation details that
+  change without changing behavior.
+
+## Props, emits, and stores
+
+- Pass required props explicitly through `mount(Component, { props: {...}
+  })`; do not rely on defaults silently covering a prop the test never
+  sets when its value actually matters to the assertion.
+- Assert an emitted event with `wrapper.emitted('eventName')` and check
+  the payload array, not just that the event fired -- a wrong payload is a
+  real bug an emitted-only check misses.
+- For a component that uses Pinia, create a fresh test Pinia instance per
+  test (`createTestingPinia()` from `@pinia/testing`, or `createPinia()` +
+  `setActivePinia()`) rather than reusing one instance across tests, so
+  store state from one test cannot leak into the next.
+
+## Mocking and determinism
+
+- Mock network calls at the request boundary (the composable/service
+  function, or MSW at the fetch layer) the project already uses, not deep
+  inside a component's internals.
+- Use Vitest's fake timers (`vi.useFakeTimers()`) for a component that
+  debounces, polls, or delays, and restore real timers afterward
+  (`vi.useRealTimers()`) so later tests are not affected.
+- Flush pending reactivity updates with `await nextTick()` (or the
+  awaited `trigger()`/`flushPromises()` the project already imports)
+  before asserting on DOM that changes after an async composable call
+  resolves, instead of adding an arbitrary `setTimeout` wait.

package/src/gdskills/bundled/stacks/vue/skills/vue-build-fix/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: vue-build-fix
+description: "Use when resolving a vue-tsc template type error, an eslint-plugin-vue lint failure, or a Vite build error in a Vue 3 project -- covers template expression type mismatches, defineProps/defineEmits type errors, unresolved SFC/component imports, and Vite plugin/HMR build failures. Applies the smallest root-cause fix and never silences the checker with an any cast or an eslint-disable. Not for a generic tsc error in a .ts file with no .vue involved (use nodejs-build-fix) or a JSX/React build failure (use react-build-fix)."
+triggers:
+  - "fix this vue-tsc template type error"
+  - "vite build is failing on this vue component"
+  - "eslint-plugin-vue is failing on this component"
+  - "defineProps type error in this vue component"
+  - "cannot find module for this .vue import"
+  - "this vue component's template type check is failing"
+metadata:
+  origin: authored
+  category: build-fix
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Vue build-fix (vue-tsc / eslint-plugin-vue / Vite)
+
+Resolve a `vue-tsc` template type error, an `eslint-plugin-vue` lint
+failure, or a Vite build failure blocking a Vue 3 build. Applies the
+smallest change that fixes the actual root cause. See
+`rules/coding-style.mdc` for the prop/emit typing conventions a correct
+fix should restore.
+
+## Workflow
+
+### Step 1: Reproduce the failure
+
+```bash
+npx vue-tsc --noEmit
+npx eslint .
+npx vite build
+```
+
+Run the project's own `package.json` scripts if they wrap these with
+extra flags (path aliases, multiple tsconfig projects). Capture the
+exact error, including the `.vue` file, line, and (for a template error)
+whether it points inside `<template>` or `<script setup>`.
+
+### Step 2: Classify the failure
+
+- **Template type error**: `vue-tsc` reports a type mismatch inside
+  `<template>` -- a prop/expression type that does not match what the
+  template does with it (e.g. calling `.toFixed()` on a value typed
+  `string | number`), or a bound event handler with the wrong signature.
+- **`defineProps`/`defineEmits` type error**: the type-only declaration
+  itself does not compile (an invalid generic, a prop default that does
+  not satisfy `withDefaults`' inferred type).
+- **Import/resolution error**: `Cannot find module '...vue'`, an
+  unresolved `@/` alias, or a component registered but never imported.
+- **Lint error**: an `eslint-plugin-vue` rule violation -- read the rule
+  name, not just the message.
+- **Vite build error**: a plugin failure, an asset that cannot be
+  resolved, or an HMR-only issue that does not reproduce in `vite build`.
+
+### Step 3: Find the root cause
+
+**Template type errors**: trace the expression's value back to its
+`ref`/`computed`/prop declaration; a union type reaching the template
+usually means the narrowing needs to happen before the template (a
+computed that narrows, or an inline type cast per Vue's documented
+`(x as T)` pattern only when the narrowing is genuinely safe at that
+point) -- not a broadened type on the source declaration that hides a
+real case the template does not otherwise handle.
+
+**`defineProps`/`defineEmits` errors**: check the interface/type literal
+passed to the generic; a `withDefaults` default that does not structurally
+satisfy the prop's declared type is usually the type declaration being
+wrong about optionality, not a checker bug.
+
+**Import/resolution errors**: check `vite.config.ts`'s `resolve.alias`
+matches `tsconfig.json`'s `paths`, and that the `.vue` extension is
+covered by `moduleFileExtensions`/`vueCompilerOptions` where the runner
+needs it explicitly (Vitest, not Vite itself, which resolves `.vue`
+via its Vue plugin).
+
+**Lint errors**: read what the specific `eslint-plugin-vue` rule
+enforces (e.g. `vue/no-mutating-props` wants an emit instead of a prop
+write, not a suppression) before changing the code to satisfy it.
+
+### Step 4: Apply the smallest correct fix
+
+- A template type error: narrow the value correctly (a `computed()` that
+  returns the narrowed type, or a scoped inline cast at the point the
+  narrowing is actually safe) -- not a broadened prop/ref type that
+  silently accepts a case the template cannot actually handle.
+- A `defineProps`/`defineEmits` error: correct the type literal or the
+  `withDefaults` default so it genuinely matches -- not a cast to `any`
+  on the destructured value.
+- An import/resolution error: fix the alias/extension config that
+  genuinely matches the project's build target -- not a blanket
+  `skipLibCheck`/`moduleResolution` change that papers over the real
+  mismatch.
+- A lint error: change the code to satisfy the rule's actual intent
+  (e.g. replace a direct prop mutation with an emit for
+  `vue/no-mutating-props`).
+
+### Step 5: Verify and report
+
+Re-run the exact command from Step 1; confirm it exits 0. Report the
+root cause and the fix, not just "error resolved".
+
+## Rules
+
+- Follow `rules/coding-style.mdc` for the prop/emit typing conventions a
+  fix should restore, not just silence.
+- ALWAYS fix the root cause with the smallest change; never widen the
+  fix beyond the file(s) the failure actually touches.
+- NEVER use `@ts-ignore`, a cast to `any`, or an `eslint-disable` comment
+  on a `.vue` file's `<script>` or template expression to make an error
+  disappear.
+- NEVER mutate a prop in place as a "quick fix" for a `vue/no-mutating-
+  props` lint failure -- add the emit the rule is asking for.
+- NEVER delete or skip a failing test to turn the build green.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll cast this template expression `(x as any).toFixed(2)` to unblock vue-tsc" | Erases the type entirely at that call site; the union the checker flagged usually needs an actual narrowing branch, not a blanket escape hatch |
+| "eslint-disable this `vue/no-mutating-props` line, the mutation is harmless here" | The rule exists because a prop mutation is invisible to the parent and Vue warns about it at runtime too; add the emit the rule is asking for instead of suppressing it |
+| "I'll widen the prop's type to `any` so `defineProps` stops complaining" | Removes type checking from every consumer of that prop, not just this one call site |
+| "This `.vue` import fails to resolve, I'll just add `skipLibCheck: true` and move on" | `skipLibCheck` skips checking `.d.ts` files, it does not fix a genuinely broken alias or missing extension resolution -- the import still fails at runtime |
+
+## Verification
+
+Do not report the fix done until all of the following hold:
+
+- The exact command that reproduced the failure in Step 1 now exits 0.
+- No `@ts-ignore`, `any` cast, or `eslint-disable` was added to the
+  `.vue` file.
+- No unrelated `tsconfig.json`/`vite.config.ts`/`eslint` config was
+  loosened.
+- A `vue/no-mutating-props` fix added an emit, not a suppression.
+- The report states the actual root cause, not just "fixed the error".

package/src/gdskills/bundled/stacks/vue/skills/vue-build-fix/evals.json

@@ -0,0 +1,72 @@
+{
+  "triggers": {
+    "positive": [
+      "our CI pipeline breaks on a type mismatch coming from vue-tsc, pointing at an expression inside this component's template block -- how do I resolve it",
+      "vite refuses to bundle this vue single file component because it can't resolve one of the imports inside it",
+      "our vue.js CI job fails because eslint's no-mutating-props check rejects a change in this component",
+      "defineProps type error, generic doesn't match the props being passed",
+      "vite's build step can't locate this single file component when something else imports it, and throws a not found error",
+      "vue template type check fails calling toFixed on this value"
+    ],
+    "negative": [
+      "fix this tsc error in a plain typescript service file",
+      "fix this tsx build error in this react component",
+      "review this vue component diff for reactivity bugs",
+      "write a vitest test for this vue component",
+      "implement a new vue component with typed props and emits",
+      "migrate this vue 2 component to vue 3 composition api"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "no-mutating-props-lint-fix",
+      "prompt": "eslint-plugin-vue reports `vue/no-mutating-props` on this line inside a child component: `props.count = props.count + 1`. What's the right fix?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer fixes the vue/no-mutating-props violation by replacing the direct prop write with an emitted event so the parent updates its own state, rather than suppressing the rule.",
+          "pass_criteria": [
+            "States that the prop must not be written to directly and the fix is to emit an event for the parent to update the value instead",
+            "Shows the fix as code: a defineEmits declaration and the emit() call (e.g. emit('update:count', props.count + 1)) replacing the direct assignment"
+          ],
+          "fail_criteria": [
+            "Recommends adding an eslint-disable comment (line or file level) for vue/no-mutating-props instead of removing the direct prop write. Mentioning eslint-disable only to say it is the wrong move does not count as this failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "`vue/no-mutating-props` is correct here: `props.count = props.count + 1` writes directly to a prop, which is one-way data from the parent and Vue warns about at runtime too. Fix it by emitting an event and letting the parent own the update:\n```ts\nconst emit = defineEmits<{ 'update:count': [value: number] }>()\nfunction increment() {\n  emit('update:count', props.count + 1)\n}\n```\nIn the parent, bind `v-model:count=\"count\"` (or listen for `@update:count`) so the actual state change happens where `count` is owned. Re-run eslint to confirm the rule is now satisfied without a suppression.",
+        "known_wrong": "Easiest way to unblock this: add `// eslint-disable-next-line vue/no-mutating-props` above the line. The mutation is harmless in this component since nothing else reads `count` from the parent side right now.",
+        "vague": "Don't mutate the prop, emit an event instead so the parent handles the update.",
+        "subtle_wrong": "I'd copy the prop into local component state on mount and increment that local copy instead: `const localCount = ref(props.count); function increment() { localCount.value++ }`, then render `localCount` in the template. That way nothing writes to `props.count` anymore and the lint rule passes."
+      },
+      "anti_patterns": ["eslint-disable"]
+    },
+    {
+      "id": "template-union-type-narrowing",
+      "prompt": "vue-tsc reports a template type error: `Property 'toFixed' does not exist on type 'string'` on `{{ total.toFixed(2) }}`, where `total` is typed `ref<string | number>`. How do I fix this without breaking the type check?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer explains that the template calls a number-only method on a value that can also be a string, and fixes it so the rendered result is consistently a formatted number in both cases -- either via a computed that converts the value to a number before formatting, or converting the value at its source -- rather than casting the expression to bypass the checker or narrowing only enough to satisfy the type checker while leaving the string case unformatted.",
+          "pass_criteria": [
+            "Explains that `total` being typed `string | number` means the template cannot assume it's a number, and the fix converts/narrows it before the template uses `.toFixed`",
+            "Shows a concrete fix as code that produces a consistently formatted number for BOTH the string and number cases, e.g. `computed(() => Number(total.value).toFixed(2))`, or converting the value at its source so it is genuinely a `number` at that point"
+          ],
+          "fail_criteria": [
+            "Recommends bypassing the check with a template cast to `any` (e.g. `(total as any).toFixed(2)`) or a `@ts-ignore`-equivalent instead of narrowing the type",
+            "Narrows only enough to satisfy the type checker (e.g. a template `typeof total === 'number' ? total.toFixed(2) : total` ternary) while leaving the string branch rendered as the raw unformatted string instead of a consistently formatted number"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "The template error is real: `total` is typed `ref<string | number>`, and `.toFixed()` only exists on `number`, so calling it directly on a value that could be a string is a genuine mismatch vue-tsc is right to catch. Rather than casting past it, narrow the value before the template touches it -- a computed that guarantees a number:\n```ts\nconst formattedTotal = computed(() => Number(total.value).toFixed(2))\n```\n```vue\n<template>{{ formattedTotal }}</template>\n```\nIf `total` should genuinely always be a number by the time it reaches the template, the better fix is at the source: change wherever it's assigned a string to convert it there instead, and narrow the ref's type to `ref<number>`.",
+        "known_wrong": "Quickest fix: change the template to `{{ (total as any).toFixed(2) }}`. That satisfies vue-tsc immediately and the runtime behavior doesn't change either way.",
+        "vague": "You need to make sure total is a number before calling toFixed on it in the template.",
+        "subtle_wrong": "I'd add a template-level check instead: `{{ typeof total === 'number' ? total.toFixed(2) : total }}`. This satisfies the type checker's narrowing inside the ternary and avoids a cast, without needing to add a computed property."
+      }
+    }
+  ]
+}