@fewangsit/wangsvue-gsts 2.0.0-alpha.3 → 2.0.0-alpha.30

package/mcp/skills/figma-to-code/SKILL.md

@@ -1,117 +1,118 @@
----
-name: 'figma-to-code'
-description: 'Converts Figma designs to Wangsvue code following strict mapping rules and color system. Invoke when user provides Figma section link or node ID'
----
-
-# Figma to Code Logic
-
-This skill provides strict guidelines for converting Figma designs or React/JSX code into Wangsvue Vue 3 components.
-
-## 0. Figma Discovery Protocol (Link/Node ID)
-
-**Invoke this protocol when a Figma URL or Node ID is provided:**
-
-1. **Extract Node ID:** If a URL is provided (e.g., `...node-id=1-2`), extract the ID (e.g., `1:2`).
-2. **Call `mcp_figma-dev_get_design_context`:** Use the `nodeId` to get the design metadata and code.
-3. **Analyze Variables:** Call `mcp_figma-dev_get_variable_defs` for the node to map any design tokens to the Wangsvue color system.
-
-## 1. Core Conversion Logic
-
-When converting from Figma or React:
-
-1. **Strict Conversion:** Convert all React hooks/JSX into Vue 3 Composition API.
-2. **Component Mapping:** You MUST identify and use the correct **Wangsvue Component** from the MCP. Do not use generic HTML if a Wangsvue component exists.
-3. **Style Abstraction:** **DO NOT** convert Figma color variables or design system tokens manually. Trust the Wangsvue components to provide and handle the design system.
-4. **Layout Focus:** Concentrate exclusively on:
-   - **Layout Structure:** Component hierarchy and nesting.
-   - **Layout Style:** Flex/Grid positioning, spacing, alignment, and sizing.
-   - **Custom Style:** Apply only to non-Wangsvue elements where layout-specific CSS is required.
-   - You MUST use tailwind css class instead of css in `<style>` block.
-5. **Architecture:** You MUST break flat code into the appropriate folder defined in the **Project Structure**. Logic in `components/modules/`, NOT in views.
-
-## 2. Component Discovery Protocol
-
-**ALWAYS ASK BEFORE USING GENERIC COMPONENTS OR MANUAL STYLING:**
-
-1. **Search First:** If you need functionality (Filter, Download, Bulk action, Search, Upload, Copy), search the component list first.
-2. **Structural Components:** If you need a container, card, form, modal, panel, or loading state, check if Wangsvue has a specialized component (e.g., `Card`, `Dialog`, `Form`, `Loading`).
-3. **Mental Shift:**
-   - ❌ OLD: `<div class="bg-white p-4">` → ✅ NEW: `<Card>`
-   - ❌ OLD: `<Button>` for download → ✅ NEW: `<ButtonDownload>`
-
-## 3. Figma Conversion Rules
-
-### Component Replacement Logic
-
-- **`data-name="ComponentName"`** = Replace this entire element with `<ComponentName>`
-- **NOT** wrap `<ComponentName>` inside this element.
-- **Example:** `<div data-name="Breadcrumb">...</div>` → `<Breadcrumb />`
-- **Exception:** If `data-name` is NOT in Wangsvue component list, it may be a custom layout name - keep as div with appropriate classes.
-
-### No Double Wrapping
-
-- ❌ **WRONG:** `<div><Breadcrumb /></div>` (when div only contains 1 component)
-- ✅ **CORRECT:** `<Breadcrumb />` (every Vue component has root element)
-- **Rule:** If container has only 1 component, remove the container.
-
-### Trust Component Styling
-
-- ❌ **NEVER:** Add styling to Wangsvue components.
-- ✅ **ALWAYS:** Trust component's built-in design system.
-- **Exception:** Layout positioning only (margin, positioning).
-- **Example:** `<Breadcrumb class="mb-4" />` (spacing OK), `<Breadcrumb class="flex gap-2" />` (styling NOT OK).
-
-### Figma Data-Name Decision Tree
-
-```
-Figma element has data-name="SomeName"
-    ↓
-Check: Is "SomeName" in Wangsvue component list?
-    ↓
-YES → Replace: <div data-name="Button"> → <Button />
-    ↓
-NO → Keep as layout: <div data-name="HeaderSection"> → <div class="...">
-```
-
-### Exact Value Preservation
-
-- ❌ **WRONG:** `h-[21px]` → `h-5` (20px ≠ 21px)
-- ✅ **CORRECT:** Keep exact values `h-[21px]`
-- **Rule:** 1px difference matters for pixel-perfect design.
-
-## 4. Color System Protocol
-
-**WANGSVUE COLOR SYSTEM RULES:**
-
-- ❌ **NEVER use CSS variables**: `bg-[var(--general/content,#ebeaf0)]`
-- ✅ **ALWAYS use Tailwind color tokens**: `bg-general-50`
-- ❌ **NEVER use hex colors directly**: `bg-[#ebeaf0]`
-- ✅ **ALWAYS map hex to color palette**: `#ebeaf0` → `general-50`
-
-### Color Palette Mapping Process
-
-1. **Find hex color** in Figma code or design.
-2. **Check `tailwind.config.js`** for the color config path.
-3. **Match hex to color token** in the referenced JSON config (e.g., `general-50`, `grayscale-50`, `primary-500`).
-
-## 5. Synthesis & Structure
-
-- **Vue SFC Structure:** Script → Template → Style.
-- **Script Organization:** Imports → Props/Emits → Lifecycle → Variables → Methods.
-- **Views Architecture:** Views are lightweight, only import and compose from modules.
-- **Logic Placement:** Business logic, data, columns, and handlers belong in modules, NOT in view components.
-- **Testing Attributes:** Always include `data-wv-name` and `data-wv-section`.
-
-## 6. Critical Failure Indicators (STOP IF ANY OCCUR)
-
-- Using generic Button when specialized component exists.
-- Using manual CSS when structural component exists.
-- Using CSS variables or hex colors instead of Tailwind color tokens.
-- Writing `<div class="bg-white p-4">` instead of `<Card>`.
-- Writing component usage without checking examples.
-- Guessing icon names or enum values.
-- Creating custom solutions when documented patterns exist.
-- Double wrapping components.
-- Adding styling to Wangsvue components.
-- Converting exact pixel values incorrectly (e.g., 21px → 20px).
-- Putting business logic in view components.
+---
+name: 'figma-to-code'
+description: 'Converts Figma designs to Wangsvue code following strict mapping rules and color system. Invoke when user provides Figma section link or node ID'
+---
+
+# Figma to Code Logic
+
+This skill provides strict guidelines for converting Figma designs or React/JSX code into Wangsvue Vue 3 components.
+
+## 0. Figma Discovery Protocol (Link/Node ID)
+
+**Invoke this protocol when a Figma URL or Node ID is provided:**
+
+1. **Extract Node ID:** If a URL is provided (e.g., `...node-id=1-2`), extract the ID (e.g., `1:2`).
+2. **Call `mcp_figma-dev_get_design_context`:** Use the `nodeId` to get the design metadata and code.
+3. **Analyze Variables:** Call `mcp_figma-dev_get_variable_defs` for the node to map any design tokens to the Wangsvue color system.
+
+## 1. Core Conversion Logic
+
+When converting from Figma or React:
+
+1. **Strict Conversion:** Convert all React hooks/JSX into Vue 3 Composition API.
+2. **Component Mapping:** You MUST identify and use the correct **Wangsvue Component** from the MCP. Do not use generic HTML if a Wangsvue component exists.
+3. **Style Abstraction:** **DO NOT** convert Figma color variables or design system tokens manually. Trust the Wangsvue components to provide and handle the design system.
+4. **Layout Focus:** Concentrate exclusively on:
+   - **Layout Structure:** Component hierarchy and nesting.
+   - **Layout Style:** Flex/Grid positioning, spacing, alignment, and sizing.
+   - **Custom Style:** Apply only to non-Wangsvue elements where layout-specific CSS is required.
+   - You MUST use tailwind css class instead of css in `<style>` block.
+5. **Architecture:** You MUST break flat code into the appropriate folder defined in the **Project Structure**. Logic in `components/modules/`, NOT in views.
+
+## 2. Component Discovery Protocol
+
+**ALWAYS ASK BEFORE USING GENERIC COMPONENTS OR MANUAL STYLING:**
+
+1. **Search First:** If you need functionality (Filter, Download, Bulk action, Search, Upload, Copy), search the component list first.
+2. **Structural Components:** If you need a container, card, form, modal, panel, or loading state, check if Wangsvue has a specialized component (e.g., `Card`, `Dialog`, `Form`, `Loading`).
+3. **Mental Shift:**
+   - ❌ OLD: `<div class="bg-white p-4">` → ✅ NEW: `<Card>`
+   - ❌ OLD: `<Button>` for download → ✅ NEW: `<ButtonDownload>`
+
+## 3. Figma Conversion Rules
+
+### Component Replacement Logic
+
+- **`data-name="ComponentName"`** = Replace this entire element with `<ComponentName>`
+- **NOT** wrap `<ComponentName>` inside this element.
+- **Example:** `<div data-name="Breadcrumb">...</div>` → `<Breadcrumb />`
+- **Exception:** If `data-name` is NOT in Wangsvue component list, it may be a custom layout name - keep as div with appropriate classes.
+
+### No Double Wrapping
+
+- ❌ **WRONG:** `<div><Breadcrumb /></div>` (when div only contains 1 component)
+- ✅ **CORRECT:** `<Breadcrumb />` (every Vue component has root element)
+- **Rule:** If container has only 1 component, remove the container.
+
+### Trust Component Styling
+
+- ❌ **NEVER:** Add styling to Wangsvue components.
+- ✅ **ALWAYS:** Trust component's built-in design system.
+- **Exception:** Layout positioning only (margin, positioning).
+- **Example:** `<Breadcrumb class="mb-4" />` (spacing OK), `<Breadcrumb class="flex gap-2" />` (styling NOT OK).
+
+### Figma Data-Name Decision Tree
+
+```
+Figma element has data-name="SomeName"
+    ↓
+Check: Is "SomeName" in Wangsvue component list?
+    ↓
+YES → Replace: <div data-name="Button"> → <Button />
+    ↓
+NO → Keep as layout: <div data-name="HeaderSection"> → <div class="...">
+```
+
+### Exact Value Preservation
+
+- ❌ **WRONG:** `h-[21px]` → `h-5` (20px ≠ 21px)
+- ✅ **CORRECT:** Keep exact values `h-[21px]`
+- **Rule:** 1px difference matters for pixel-perfect design.
+
+## 4. Color System Protocol
+
+**WANGSVUE COLOR SYSTEM RULES:**
+
+- ❌ **NEVER use CSS variables**: `bg-[var(--general/content,#ebeaf0)]`
+- ✅ **ALWAYS use Tailwind color tokens**: `bg-general-50`
+- ❌ **NEVER use hex colors directly**: `bg-[#ebeaf0]`
+- ✅ **ALWAYS map hex to color palette**: `#ebeaf0` → `general-50`
+
+### Color Palette Mapping Process
+
+1. **Find hex color** in Figma code or design.
+2. **Check `tailwind.config.js`** for the color config path.
+3. **Match hex to color token** in the referenced JSON config (e.g., `general-50`, `grayscale-50`, `primary-500`).
+
+## 5. Synthesis & Structure
+
+- **Vue SFC Structure:** Script → Template → Style.
+- **Script Organization:** Imports → Props/Emits → Lifecycle → Variables → Methods.
+- **Views Architecture:** Views are lightweight, only import and compose from modules.
+- **Logic Placement:** Business logic, data, columns, and handlers belong in modules, NOT in view components.
+- **Testing Attributes:** Always include `data-wv-name` and `data-wv-section`.
+- **Accessibility:** Interactive elements must have `aria-label`, `aria-labelledby`, or `aria-describedby`.
+
+## 6. Critical Failure Indicators (STOP IF ANY OCCUR)
+
+- Using generic Button when specialized component exists.
+- Using manual CSS when structural component exists.
+- Using CSS variables or hex colors instead of Tailwind color tokens.
+- Writing `<div class="bg-white p-4">` instead of `<Card>`.
+- Writing component usage without checking examples.
+- Guessing icon names or enum values.
+- Creating custom solutions when documented patterns exist.
+- Double wrapping components.
+- Adding styling to Wangsvue components.
+- Converting exact pixel values incorrectly (e.g., 21px → 20px).
+- Putting business logic in view components.

package/mcp/skills/import-validator/SKILL.md

@@ -1,54 +1,54 @@
----
-name: 'import-validator'
-description: 'Enforces strict import protocols for Wangsvue components and types. Invoke when writing imports or fixing import errors.'
----
-
-# Import Protocol Validator
-
-This skill ensures that all imports follow the strict Wangsvue Import Protocol.
-
-## The Golden Rules
-
-1.  **NEVER Guess:** Always use `mcp_wangsvue_mcp_analyze_component` and `mcp_wangsvue_mcp_resolve_type_definition` to get the correct paths.
-2.  **Exact Paths:** Do not modify the import paths returned by MCP tools.
-3.  **Type Keyword:** Always add `type` keyword for type imports.
-
-## Common Mistakes & Corrections
-
-### 1. Component Imports
-
-**❌ WRONG:** `import { Button } from '@fewangsit/wangsvue/button';`
-**✅ RIGHT:** `import { Button } from '@fewangsit/wangsvue';`
-_Rule: Components usually come from the main package._
-
-### 2. Type Imports
-
-**❌ WRONG:** `import { MenuItem } from '@fewangsit/wangsvue/menuitem';`
-**✅ RIGHT:** `import type { MenuItem } from '@fewangsit/wangsvue/menuitem';`
-_Rule: Types usually come from specific modules and MUST use `import type`._
-
-### 3. Mixing Imports
-
-**❌ WRONG:** `import { Button, ButtonProps } from '@fewangsit/wangsvue';`
-**✅ RIGHT:** Separate them.
-
-```typescript
-import { Button } from '@fewangsit/wangsvue';
-import type { ButtonProps } from '@fewangsit/wangsvue/button'; // Verify path with MCP!
-```
-
-## Verification Process
-
-Before writing any import:
-
-1.  **Call MCP Tools:** `analyze_component` for components, `resolve_type_definition` for types.
-2.  **Copy Exact Paths:** Use the path provided in the MCP result.
-3.  **Add 'type':** If it is a type definition, ensure `type` keyword is used.
-4.  **Group Properly:** Keep components and types separate.
-
-## Checklist
-
-- [ ] Did I get this path from MCP tools?
-- [ ] Is this a component? (Use main package path)
-- [ ] Is this a type? (Use specific module path + `type`)
-- [ ] Did I copy the exact path?
+---
+name: 'import-validator'
+description: 'Enforces strict import protocols for Wangsvue components and types. Invoke when writing imports or fixing import errors.'
+---
+
+# Import Protocol Validator
+
+This skill ensures that all imports follow the strict Wangsvue Import Protocol.
+
+## The Golden Rules
+
+1.  **NEVER Guess:** Always use `mcp_wangsvue_mcp_analyze_component` and `mcp_wangsvue_mcp_resolve_type_definition` to get the correct paths.
+2.  **Exact Paths:** Do not modify the import paths returned by MCP tools.
+3.  **Type Keyword:** Always add `type` keyword for type imports.
+
+## Common Mistakes & Corrections
+
+### 1. Component Imports
+
+**❌ WRONG:** `import { Button } from '@fewangsit/wangsvue/button';`
+**✅ RIGHT:** `import { Button } from '@fewangsit/wangsvue';`
+_Rule: Components usually come from the main package._
+
+### 2. Type Imports
+
+**❌ WRONG:** `import { MenuItem } from '@fewangsit/wangsvue/menuitem';`
+**✅ RIGHT:** `import type { MenuItem } from '@fewangsit/wangsvue/menuitem';`
+_Rule: Types usually come from specific modules and MUST use `import type`._
+
+### 3. Mixing Imports
+
+**❌ WRONG:** `import { Button, ButtonProps } from '@fewangsit/wangsvue';`
+**✅ RIGHT:** Separate them.
+
+```typescript
+import { Button } from '@fewangsit/wangsvue';
+import type { ButtonProps } from '@fewangsit/wangsvue/button'; // Verify path with MCP!
+```
+
+## Verification Process
+
+Before writing any import:
+
+1.  **Call MCP Tools:** `analyze_component` for components, `resolve_type_definition` for types.
+2.  **Copy Exact Paths:** Use the path provided in the MCP result.
+3.  **Add 'type':** If it is a type definition, ensure `type` keyword is used.
+4.  **Group Properly:** Keep components and types separate.
+
+## Checklist
+
+- [ ] Did I get this path from MCP tools?
+- [ ] Is this a component? (Use main package path)
+- [ ] Is this a type? (Use specific module path + `type`)
+- [ ] Did I copy the exact path?

package/mcp/skills/wangsvue-code-review/SKILL.md

@@ -1,70 +1,72 @@
----
-name: 'wangsvue-code-review'
-description: 'Reviews generated Wangsvue code against mandatory architectural principles and enforcement checklists. Invoke after generating code or before completion.'
----
-
-# Wangsvue Code Review Protocol
-
-This skill enforces the strict quality standards for Wangsvue code. Use this checklist to review any generated code before considering the task complete.
-
-## 🚨 Mandatory Architectural Principles
-
-### 1. Total Wangsvue Exclusivity
-
-- [ ] **Strict Prohibition:** NO usage of PrimeVue, Element Plus, Vuetify, or other libraries.
-- [ ] **Compliance:** ONLY use props, slots, events, and patterns defined in Wangsvue MCP or Knowledge Base.
-
-### 2. Zero Assumption Policy
-
-- [ ] **Verification:** Are all prop names, slot names, icon names, and enum values verified via MCP?
-- [ ] **No Guessing:** If it's not in the MCP result, it doesn't exist.
-
-### 3. MCP-First Verification
-
-- [ ] **Component Discovery:** Was `list_all_components()` called to find specialized components?
-- [ ] **Type Resolution:** Were all literal values (icons, severity, sizes) verified with `resolve_type_definition`?
-- [ ] **Example Check:** Did you check `get_example` for intended usage patterns?
-
-## ✅ Final Enforcement Checklist (Every File Must Pass)
-
-### 1. SFC Structure & Organization
-
-- [ ] **Structure:** `<script setup>` → `<template>` → `<style>` (only if needed).
-- [ ] **Script Order:** Imports → Props/Emits → Lifecycle → Variables → Methods (follows Vue Code Structure MD).
-- [ ] **Project Structure:** Business logic is in `components/modules/`, NOT in views.
-- [ ] **App.vue:** Only contains `<router-view />`, no business logic.
-
-### 2. Import Protocol
-
-- [ ] **Exact Paths:** ALL imports match MCP results EXACTLY (no modifications).
-- [ ] **Type Imports:** `type` keyword used for all type imports (from `resolve_type_definition`).
-- [ ] **Separation:** Component imports (main package) separated from Type imports (specific modules).
-
-### 3. Testing & Attributes
-
-- [ ] **Data Attributes:** `data-wv-name` on root element, `data-wv-section` on significant sections.
-
-### 4. Code Quality
-
-- [ ] **Linter:** `pnpm lint` must pass with exit code 0. After fixing ESLint errors, check editor `#problems_and_diagnostics` and fix any remaining issues.
-- [ ] **No Generic HTML:** specialized components used instead of `<div>` (e.g., `Card` instead of `div.bg-white`).
-- [ ] **No Manual CSS:** No styling on Wangsvue components (trust the design system).
-- [ ] **Exact Pixel Values:** 21px remains 21px, do not round to 20px (h-5).
-
-## ❌ Automatic Failure Indicators (IMMEDIATE STOP)
-
-If ANY of these are found, the code is rejected:
-
-- **Guessing:** Guessing icon names (`edit-line` vs `edit`) or enum values.
-- **Manual Styles:** Writing `<div class="bg-white p-4">` instead of `<Card>`.
-- **CSS Vars:** Using `bg-[var(--color)]` instead of Tailwind tokens (`bg-general-50`).
-- **Wrong Imports:** Mixing component and type paths, or forgetting `type` keyword.
-- **Double Wrapping:** `<div><Breadcrumb /></div>` (remove the div).
-- **Fat Views:** Putting data, columns, or handlers in view components instead of modules.
-- **Custom Patterns:** Implementing custom solutions when documentation provides a standard approach.
-- **Optimization:** "Optimizing" documented patterns instead of following them exactly.
-
-## Review Decision
-
-- **PASS:** All checklists checked, no failure indicators.
-- **FAIL:** Any unchecked item or presence of failure indicator. **Fix immediately.**
+---
+name: 'wangsvue-code-review'
+description: 'Reviews generated Wangsvue code against mandatory architectural principles and enforcement checklists. Invoke after generating code or before completion.'
+---
+
+# Wangsvue Code Review Protocol
+
+This skill enforces the strict quality standards for Wangsvue code. Use this checklist to review any generated code before considering the task complete.
+
+## 🚨 Mandatory Architectural Principles
+
+### 1. Total Wangsvue Exclusivity
+
+- [ ] **Strict Prohibition:** NO usage of PrimeVue, Element Plus, Vuetify, or other libraries.
+- [ ] **Compliance:** ONLY use props, slots, events, and patterns defined in Wangsvue MCP or Knowledge Base.
+
+### 2. Zero Assumption Policy
+
+- [ ] **Verification:** Are all prop names, slot names, icon names, and enum values verified via MCP?
+- [ ] **No Guessing:** If it's not in the MCP result, it doesn't exist.
+
+### 3. MCP-First Verification
+
+- [ ] **Component Discovery:** Was `list_all_components()` called to find specialized components?
+- [ ] **Type Resolution:** Were all literal values (icons, severity, sizes) verified with `resolve_type_definition`?
+- [ ] **Example Check:** Did you check `get_example` for intended usage patterns?
+
+## ✅ Final Enforcement Checklist (Every File Must Pass)
+
+### 1. SFC Structure & Organization
+
+- [ ] **Structure:** `<script setup>` → `<template>` → `<style>` (only if needed).
+- [ ] **Script Order:** Imports → Props/Emits → Lifecycle → Variables → Methods (follows Vue Code Structure MD).
+- [ ] **Project Structure:** Business logic is in `components/modules/`, NOT in views.
+- [ ] **App.vue:** Only contains `<router-view />`, no business logic.
+
+### 2. Import Protocol
+
+- [ ] **Exact Paths:** ALL imports match MCP results EXACTLY (no modifications).
+- [ ] **Type Imports:** `type` keyword used for all type imports (from `resolve_type_definition`).
+- [ ] **Separation:** Component imports (main package) separated from Type imports (specific modules).
+
+### 3. Testing & Attributes
+
+- [ ] **Data Attributes:** `data-wv-name` on root element, `data-wv-section` on significant sections.
+- [ ] **Accessibility:** Every interactive element (button, input, select, toggle, link) MUST have `aria-label`, `aria-labelledby`, or `aria-describedby`.
+- [ ] **PrimeVue Passthrough:** For components wrapping PrimeVue primitives, attributes on inner PrimeVue elements MUST go through `:pt`, not directly on the wrapper tag.
+
+### 4. Code Quality
+
+- [ ] **Linter:** `pnpm lint` must pass with exit code 0. After fixing ESLint errors, check editor `#problems_and_diagnostics` and fix any remaining issues.
+- [ ] **No Generic HTML:** specialized components used instead of `<div>` (e.g., `Card` instead of `div.bg-white`).
+- [ ] **No Manual CSS:** No styling on Wangsvue components (trust the design system).
+- [ ] **Exact Pixel Values:** 21px remains 21px, do not round to 20px (h-5).
+
+## ❌ Automatic Failure Indicators (IMMEDIATE STOP)
+
+If ANY of these are found, the code is rejected:
+
+- **Guessing:** Guessing icon names (`edit-line` vs `edit`) or enum values.
+- **Manual Styles:** Writing `<div class="bg-white p-4">` instead of `<Card>`.
+- **CSS Vars:** Using `bg-[var(--color)]` instead of Tailwind tokens (`bg-general-50`).
+- **Wrong Imports:** Mixing component and type paths, or forgetting `type` keyword.
+- **Double Wrapping:** `<div><Breadcrumb /></div>` (remove the div).
+- **Fat Views:** Putting data, columns, or handlers in view components instead of modules.
+- **Custom Patterns:** Implementing custom solutions when documentation provides a standard approach.
+- **Optimization:** "Optimizing" documented patterns instead of following them exactly.
+
+## Review Decision
+
+- **PASS:** All checklists checked, no failure indicators.
+- **FAIL:** Any unchecked item or presence of failure indicator. **Fix immediately.**