devskill 2.0.2

package/skills/vercel-cli-with-tokens/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/web-design-guidelines/skills/vercel-cli-with-tokens`
+- **Git SHA:** `9aec8ee6aaf702e49312a071e672f1c1b7b7e948`
+- **Synced:** 2026-03-24

package/skills/vue/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: vue
+description: Vue 3 Composition API — <script setup>, reactivity (shallowRef/ref), props without destructure, computed, watch, provide/inject, and composables. Use when the project uses modern Vue 3 Composition API style.
+metadata:
+  author: Vũ Lưu
+  version: "2026.3.23"
+  source: Hand-written based on https://vuejs.org and instructions/vue.md
+---
+
+# Vue 3 (Composition API)
+
+> This skill focuses on the **Composition API** and **`<script setup>`** explicitly strongly typed with TypeScript.
+
+## Key Rules (from instructions)
+
+- **Prefer TypeScript** over JavaScript (`<script setup lang="ts">`).
+- **Always use Composition API** over Options API.
+- **Prefer `<script setup>`** over explicit `setup()` functions.
+- **Prefer `shallowRef` over `ref`** for performance if deep reactivity is not used.
+- **Discourage Reactive Props Destructure** (use `props.myProp` instead).
+
+## Core
+
+| Topic | Description | Reference |
+|-------|-------------|-----------|
+| State & Reactivity | `shallowRef`, `ref`, `computed`, `watch` | [state](references/state.md) |
+| Props & Emits | `defineProps` (no destructuring), `defineEmits` | [props-emits](references/props-emits.md) |
+| Lifecycle Hooks | `onMounted`, `onUpdated`, `onUnmounted` | [lifecycle](references/lifecycle.md) |
+
+## Features & Patterns
+
+| Topic | Description | Reference |
+|-------|-------------|-----------|
+| Composables | State logic reuse (instead of Mixins) | [composables](references/composables.md) |
+| Provide / Inject | Dependency injection across deep component trees | [provide-inject](references/provide-inject.md) |
+
+## Quick Reference
+
+### Full SFC Template (`<script setup>`)
+
+```vue
+<script setup lang="ts">
+import { shallowRef, computed, watch, onMounted } from 'vue'
+
+// -- Props & Emits --
+interface Props {
+  title: string
+  count?: number
+}
+// ❌ Do NOT destructure props, keep the `props` object
+const props = withDefaults(defineProps<Props>(), {
+  count: 0
+})
+
+const emit = defineEmits<{
+  update: [newCount: number]
+}>()
+
+// -- State --
+// ✅ Prefer shallowRef if deep tracking isn't needed
+const localCount = shallowRef(props.count)
+
+// -- Computed --
+const doubled = computed(() => localCount.value * 2)
+
+// -- Watchers --
+watch(() => props.count, (newVal) => {
+  localCount.value = newVal
+})
+
+// -- Methods --
+function increment() {
+  localCount.value++
+  emit('update', localCount.value)
+}
+
+// -- Lifecycle --
+onMounted(() => {
+  console.log('Component mounted')
+})
+</script>
+
+<template>
+  <div>
+    <h1>{{ props.title }}</h1>
+    <p>Count: {{ localCount }} | Doubled: {{ doubled }}</p>
+    <button @click="increment">Increment</button>
+  </div>
+</template>
+```

package/skills/vue/references/composables.md

@@ -0,0 +1,54 @@
+# Composables
+
+**Rule:** Always use Composables instead of Mixins.
+
+Composables are plain functions that use the Composition API to encapsulate and reuse stateful logic.
+
+## 1. Defining a Composable
+
+By convention, composable functions start with `use`. They should return `refs` or `computed` properties so components can choose what to expose or destructure.
+
+```ts
+// composables/useMouse.ts
+import { shallowRef, onMounted, onUnmounted } from 'vue'
+
+export function useMouse() {
+  // Encapsulated state
+  const x = shallowRef(0)
+  const y = shallowRef(0)
+
+  // Encapsulated logic & side-effects
+  function update(event: MouseEvent) {
+    x.value = event.pageX
+    y.value = event.pageY
+  }
+
+  onMounted(() => window.addEventListener('mousemove', update))
+  onUnmounted(() => window.removeEventListener('mousemove', update))
+
+  // Return values (not reactive destructuring here, returning the refs directly)
+  return { x, y }
+}
+```
+
+## 2. Using the Composable
+
+```vue
+<script setup lang="ts">
+import { useMouse } from './composables/useMouse'
+
+// Consume the composable
+const { x, y } = useMouse()
+</script>
+
+<template>
+  Mouse position: {{ x }}, {{ y }}
+</template>
+```
+
+## Mixins vs Composables
+
+Why Composables are strictly preferred:
+- **No Property Name Conflicts:** You dynamically rename destructured properties when calling the composable.
+- **Clear Origins:** You can easily trace exactly which state/method came from which composable.
+- **TypeScript Support:** Composables are regular functions and type-check perfectly without advanced trickery.

package/skills/vue/references/lifecycle.md

@@ -0,0 +1,31 @@
+# Lifecycle Hooks (`<script setup>`)
+
+In Composition API, lifecycle hooks are imported functions that you call inside `setup()`.
+
+## Core Hooks
+
+```vue
+<script setup lang="ts">
+import { onMounted, onUpdated, onUnmounted } from 'vue'
+
+onMounted(() => {
+  console.log('The component is now mounted to the DOM.')
+  // E.g., fetch data, initialize third-party libraries, attach global listeners
+})
+
+onUpdated(() => {
+  console.log('Component updated its DOM because reactive state changed.')
+})
+
+onUnmounted(() => {
+  console.log('The component is being removed from the DOM.')
+  // E.g., cleanup intervals, remove event listeners (if not scoped to the element)
+})
+</script>
+```
+
+## Usage Rules
+
+- Hooks **must be called synchronously** during the `setup()` execution.
+- You can call a hook multiple times in the same component, and all callbacks will be executed in the order they were registered.
+- Avoid placing heavy initialization tasks directly in the component root; place DOM-dependent logic inside `onMounted`.

package/skills/vue/references/props-emits.md

@@ -0,0 +1,62 @@
+# Props and Emits (`<script setup>`)
+
+## `defineProps` (No Reactive Destructure!)
+
+**Rule:** Discourage using Reactive Props Destructure. Destructuring `props` removes primitive reactivity, leading to bugs. Always use the `props.` object prefix instead.
+
+```vue
+<script setup lang="ts">
+// ❌ BAD: Destructuring the props object breaks reactivity!
+// const { title } = defineProps<{ title: string }>()
+
+// ✅ GOOD: Keep the `props` reference intact.
+const props = defineProps<{
+  title: string
+  items: string[]
+}>()
+
+console.log(props.title) // Safe
+</script>
+
+<template>
+  <h1>{{ props.title }}</h1>
+</template>
+```
+
+### With Default Values (`withDefaults`)
+
+```vue
+<script setup lang="ts">
+interface MenuProps {
+  id: number
+  isActive?: boolean
+  label?: string
+}
+
+// ✅ Provide default values safely without destructuring
+const props = withDefaults(defineProps<MenuProps>(), {
+  isActive: false,
+  label: 'Unknown Item'
+})
+</script>
+```
+
+## `defineEmits`
+
+Use TypeScript syntax to strictly type the events your component can emit.
+
+```vue
+<script setup lang="ts">
+// Best Practice: Type-based declaration
+const emit = defineEmits<{
+  // eventName: [payloadType1, payloadType2]
+  open: [id: number]
+  update: [value: string, timestamp: Date]
+  close: []
+}>()
+
+function triggerUpdate() {
+  emit('update', 'Success!', new Date())
+}
+</script>
+```

package/skills/vue/references/provide-inject.md

@@ -0,0 +1,47 @@
+# Provide / Inject (`<script setup>`)
+
+Provide and Inject are used for **dependency injection** to pass data deep into the component tree without prop drilling.
+
+## Usage
+
+### 1. In the Ancestor Component (`provide`)
+
+```vue
+<!-- App.vue -->
+<script setup lang="ts">
+import { provide, shallowRef } from 'vue'
+
+const theme = shallowRef('dark')
+
+// Provide the value (it remains reactive if passed directly)
+provide('theme-context', theme)
+
+function toggleTheme() {
+  theme.value = theme.value === 'dark' ? 'light' : 'dark'
+}
+</script>
+```
+
+### 2. In the Descendant Component (`inject`)
+
+```vue
+<!-- DeepChild.vue -->
+<script setup lang="ts">
+import { inject, Ref } from 'vue'
+
+// Inject the value, providing a fallback default
+const theme = inject<Ref<string>>('theme-context', shallowRef('light'))
+</script>
+
+<template>
+  <div :class="`theme-${theme}`">
+    Current theme is {{ theme }}
+  </div>
+</template>
+```
+
+## Best Practices
+
+- Always type your injected properties clearly or specify defaults.
+- Ideally, **keep mutations in the provider** to preserve the one-way data flow. If the descendant needs to change the data, provide an update function alongside the state.
+- Use `Symbol` keys for enterprise scale apps to avoid naming collisions.

package/skills/vue/references/state.md

@@ -0,0 +1,65 @@
+# State & Reactivity (`<script setup>`)
+
+The Composition API allows you to declare reactive state flexibly. 
+
+## `shallowRef` vs `ref` (Rule: Prefer `shallowRef` if possible)
+
+By default, `ref` will make the entire structure deeply reactive, which can have an unintended performance cost for large datasets that only get replaced entirely.
+
+```ts
+import { ref, shallowRef } from 'vue'
+
+// ✅ PREFERRED: Using shallowRef when deep reactivity isn't needed
+// Use this if you only intend to overwrite the .value property and don't mutate its inner contents.
+const rawDataList = shallowRef<Item[]>([])
+
+// Updating shallowRef (must reassign .value)
+rawDataList.value = [...newData]
+
+// ⚠️ Use `ref` only when you specifically need to mutate inner nested object properties
+const user = ref({ name: 'Alice', age: 30 })
+user.value.age++ // Deeply reactive, triggers updates
+```
+
+## `computed` (Derived State)
+
+Computed properties automatically update when their reactive dependencies change.
+
+```ts
+import { shallowRef, computed } from 'vue'
+
+const count = shallowRef(1)
+const doubled = computed(() => count.value * 2)
+```
+
+## `watch` & `watchEffect` (Side Effects)
+
+Use `watch` to run side effects in response to reactive state changes.
+
+```ts
+import { shallowRef, watch, watchEffect } from 'vue'
+
+const question = shallowRef('')
+const answer = shallowRef('Thinking...')
+
+// watch (explicit target, old/new values)
+watch(question, async (newQuestion, oldQuestion) => {
+  if (newQuestion.includes('?')) {
+    answer.value = 'Fetching answer!'
+    // call an API...
+  }
+})
+
+// watch a getter for specific property access
+const state = shallowRef({ id: 1, name: 'bob' })
+
+watch(
+  () => state.value.id,
+  (newId) => { console.log('ID triggered watch:', newId) }
+)
+
+// watchEffect (auto-track dependencies used synchronously inside the callback)
+watchEffect(() => {
+  console.log(`Current answer is: ${answer.value}`)
+})
+```

package/skills/vue-antdv-tailwind/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: vue-antdv-tailwind
+description: Best practices for mixing Ant Design Vue components with Tailwind CSS utility classes. Use this skill to keep styling consistent without custom CSS files.
+metadata:
+  author: Vũ Lưu
+  version: "2026.3.23"
+  source: Hand-written based on builderx_spa conventions
+---
+
+# Ant Design Vue + Tailwind CSS
+
+> BuilderX SPA mixes Ant Design Vue's robust component library with Tailwind CSS's utility engine.
+
+## Core
+
+| Topic | Description | Reference |
+|-------|-------------|-----------|
+| Styling Rules | How to properly mix AntD and Tailwind | [styling-rules](references/styling-rules.md) |
+
+## Quick Reference
+
+```vue
+<template>
+  <div class="flex items-center justify-between p-4 bg-white rounded shadow">
+    <h3 class="text-lg font-bold text-gray-800">Settings</h3>
+    
+    <!-- Override/extend AntD with Tailwind -->
+    <a-button type="primary" class="bg-blue-600 hover:bg-blue-700">
+      Save
+    </a-button>
+  </div>
+</template>
+```

package/skills/vue-antdv-tailwind/references/styling-rules.md

@@ -0,0 +1,61 @@
+# Styling Rules (AntD + Tailwind)
+
+## 1. Respect Component Responsibilities
+
+- **Ant Design Vue (`<a-...>`)**: Use for functional structure (Drawers, Modals, Forms, Buttons, Selects, Tables).
+- **Tailwind CSS (`class="..."`)**: Use for layout (`flex`, `grid`, `absolute`), spacing (`m-4`, `p-2`), typography (`text-center`, `text-lg`), and colors.
+
+## 2. Avoid Custom `<style>` Blocks
+
+Whenever possible, avoid writing custom `.scss` or `.css`. Instead of:
+
+```vue
+<!-- ❌ BAD: Writing custom CSS classes for layout -->
+<template>
+  <div class="header-container">
+    <a-button>Click Me</a-button>
+  </div>
+</template>
+
+<style scoped>
+.header-container {
+  display: flex;
+  justify-content: flex-end;
+  padding: 16px;
+  background-color: #f8f9fa;
+}
+</style>
+```
+
+Do this:
+
+```vue
+<!-- ✅ GOOD: Use Tailwind directly -->
+<template>
+  <div class="flex justify-end p-4 bg-gray-50">
+    <a-button>Click Me</a-button>
+  </div>
+</template>
+```
+
+## 3. Styling Ant Design Internals
+
+Sometimes AntD wraps elements deeply and you need to style inner parts. Use Tailwind's arbitrary selectors or general cascading, rather than `::v-deep`.
+
+However, for simple spacing, you can always apply Tailwind directly to the Ant component.
+
+```vue
+<!-- Adds margin right to the AntD button -->
+<a-button class="mr-2">Cancel</a-button>
+```
+
+## 4. Theme Integration
+
+If modifying AntD primary colors globally, do so in Vue/Vite configuration configuration. If you need dynamic or context-specific color overrides in a template, Tailwind arbitrary values are highly reliable:
+
+```vue
+<a-button class="!bg-[#FF5722] !border-none !text-white">
+  Danger Actions
+</a-button>
+```
+*(Notice the `!` to force `!important` so it overrides AntD's core rules)*

package/skills/vue-best-practices/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 hyf0, SerKo <https://github.com/serkodev>
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/vue-best-practices/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: vue-best-practices
+description: MUST be used for Vue.js tasks. Strongly recommends Composition API with `<script setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.
+license: MIT
+metadata:
+  author: github.com/vuejs-ai
+  version: "18.0.0"
+---
+
+# Vue Best Practices Workflow
+
+Use this skill as an instruction set. Follow the workflow in order unless the user explicitly asks for a different order.
+
+## Core Principles
+- **Keep state predictable:** one source of truth, derive everything else.
+- **Make data flow explicit:** Props down, Events up for most cases.
+- **Favor small, focused components:** easier to test, reuse, and maintain.
+- **Avoid unnecessary re-renders:** use computed properties and watchers wisely.
+- **Readability counts:** write clear, self-documenting code.
+
+## 1) Confirm architecture before coding (required)
+
+- Default stack: Vue 3 + Composition API + `<script setup lang="ts">`.
+- If the project explicitly uses Options API, load `vue-options-api-best-practices` skill if available.
+- If the project explicitly uses JSX, load `vue-jsx-best-practices` skill if available.
+
+### 1.1 Must-read core references (required)
+
+- Before implementing any Vue task, make sure to read and apply these core references:
+  - `references/reactivity.md`
+  - `references/sfc.md`
+  - `references/component-data-flow.md`
+  - `references/composables.md`
+- Keep these references in active working context for the entire task, not only when a specific issue appears.
+
+### 1.2 Plan component boundaries before coding (required)
+
+Create a brief component map before implementation for any non-trivial feature.
+
+- Define each component's single responsibility in one sentence.
+- Keep entry/root and route-level view components as composition surfaces by default.
+- Move feature UI and feature logic out of entry/root/view components unless the task is intentionally a tiny single-file demo.
+- Define props/emits contracts for each child component in the map.
+- Prefer a feature folder layout (`components/<feature>/...`, `composables/use<Feature>.ts`) when adding more than one component.
+
+## 2) Apply essential Vue foundations (required)
+
+These are essential, must-know foundations. Apply all of them in every Vue task using the core references already loaded in section `1.1`.
+
+### Reactivity
+
+- Must-read reference from `1.1`: [reactivity](references/reactivity.md)
+- Keep source state minimal (`ref`/`reactive`), derive everything possible with `computed`.
+- Use watchers for side effects if needed.
+- Avoid recomputing expensive logic in templates.
+
+### SFC structure and template safety
+
+- Must-read reference from `1.1`: [sfc](references/sfc.md)
+- Keep SFC sections in this order: `<script>` → `<template>` → `<style>`.
+- Keep SFC responsibilities focused; split large components.
+- Keep templates declarative; move branching/derivation to script.
+- Apply Vue template safety rules (`v-html`, list rendering, conditional rendering choices).
+
+### Keep components focused
+
+Split a component when it has **more than one clear responsibility** (e.g. data orchestration + UI, or multiple independent UI sections).
+
+- Prefer **smaller components + composables** over one “mega component”
+- Move **UI sections** into child components (props in, events out).
+- Move **state/side effects** into composables (`useXxx()`).
+
+Apply objective split triggers. Split the component if **any** condition is true:
+
+- It owns both orchestration/state and substantial presentational markup for multiple sections.
+- It has 3+ distinct UI sections (for example: form, filters, list, footer/status).
+- A template block is repeated or could become reusable (item rows, cards, list entries).
+
+Entry/root and route view rule:
+
+- Keep entry/root and route view components thin: app shell/layout, provider wiring, and feature composition.
+- Do not place full feature implementations in entry/root/view components when those features contain independent parts.
+- For CRUD/list features (todo, table, catalog, inbox), split at least into:
+  - feature container component
+  - input/form component
+  - list (and/or item) component
+  - footer/actions or filter/status component
+- Allow a single-file implementation only for very small throwaway demos; if chosen, explicitly justify why splitting is unnecessary.
+
+### Component data flow
+
+- Must-read reference from `1.1`: [component-data-flow](references/component-data-flow.md)
+- Use props down, events up as the primary model.
+- Use `v-model` only for true two-way component contracts.
+- Use provide/inject only for deep-tree dependencies or shared context.
+- Keep contracts explicit and typed with `defineProps`, `defineEmits`, and `InjectionKey` as needed.
+
+### Composables
+
+- Must-read reference from `1.1`: [composables](references/composables.md)
+- Extract logic into composables when it is reused, stateful, or side-effect heavy.
+- Keep composable APIs small, typed, and predictable.
+- Separate feature logic from presentational components.
+
+## 3) Consider optional features only when requirements call for them
+
+### 3.1 Standard optional features
+
+Do not add these by default. Load the matching reference only when the requirement exists.
+
+- Slots: parent needs to control child content/layout -> [component-slots](references/component-slots.md)
+- Fallthrough attributes: wrapper/base components must forward attrs/events safely -> [component-fallthrough-attrs](references/component-fallthrough-attrs.md)
+- Built-in component `<KeepAlive>` for stateful view caching -> [component-keep-alive](references/component-keep-alive.md)
+- Built-in component `<Teleport>` for overlays/portals -> [component-teleport](references/component-teleport.md)
+- Built-in component `<Suspense>` for async subtree fallback boundaries -> [component-suspense](references/component-suspense.md)
+- Animation-related features: pick the simplest approach that matches the required motion behavior.
+  - Built-in component `<Transition>` for enter/leave effects -> [transition](references/component-transition.md)
+  - Built-in component `<TransitionGroup>` for animated list mutations -> [transition-group](references/component-transition-group.md)
+  - Class-based animation for non-enter/leave effects -> [animation-class-based-technique](references/animation-class-based-technique.md)
+  - State-driven animation for user-input-driven animation -> [animation-state-driven-technique](references/animation-state-driven-technique.md)
+
+### 3.2 Less-common optional features
+
+Use these only when there is explicit product or technical need.
+
+- Directives: behavior is DOM-specific and not a good composable/component fit -> [directives](references/directives.md)
+- Async components: heavy/rarely-used UI should be lazy loaded -> [component-async](references/component-async.md)
+- Render functions only when templates cannot express the requirement -> [render-functions](references/render-functions.md)
+- Plugins when behavior must be installed app-wide -> [plugins](references/plugins.md)
+- State management patterns: app-wide shared state crosses feature boundaries -> [state-management](references/state-management.md)
+
+## 4) Run performance optimization after behavior is correct
+
+Performance work is a post-functionality pass. Do not optimize before core behavior is implemented and verified.
+
+- Large list rendering bottlenecks -> [perf-virtualize-large-lists](references/perf-virtualize-large-lists.md)
+- Static subtrees re-rendering unnecessarily -> [perf-v-once-v-memo-directives](references/perf-v-once-v-memo-directives.md)
+- Over-abstraction in hot list paths -> [perf-avoid-component-abstraction-in-lists](references/perf-avoid-component-abstraction-in-lists.md)
+- Expensive updates triggered too often -> [updated-hook-performance](references/updated-hook-performance.md)
+
+## 5) Final self-check before finishing
+
+- Core behavior works and matches requirements.
+- All must-read references were read and applied.
+- Reactivity model is minimal and predictable.
+- SFC structure and template rules are followed.
+- Components are focused and well-factored, splitting when needed.
+- Entry/root and route view components remain composition surfaces unless there is an explicit small-demo exception.
+- Component split decisions are explicit and defensible (responsibility boundaries are clear).
+- Data flow contracts are explicit and typed.
+- Composables are used where reuse/complexity justifies them.
+- Moved state/side effects into composables if applicable
+- Optional features are used only when requirements demand them.
+- Performance changes were applied only after functionality was complete.

package/skills/vue-best-practices/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/vuejs-ai/skills/vue-best-practices`
+- **Git SHA:** `f3dd1bf4d3ac78331bdc903e4519d561c538ca6a`
+- **Synced:** 2026-03-24