start-vibing 4.0.2 → 4.1.1

package/template/.claude/skills/typeui-bento/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: bento
+description: Modular grid layout with card-like blocks, clear hierarchy, soft spacing, and subtle visual contrast for organized, scannable interfaces.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Bento Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Bento.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+The bento box style is an innovative design approach that uses a grid layout to present content in visually appealing blocks of varying sizes.
+
+## Style Foundations
+- Visual style: modern, clean
+- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Inter, display=Inter, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#FAD4C0, secondary=#80A1C1, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFF5E6, text=#111827
+- Spacing scale: 4/8/12/16/24/32
+
+## Component Families
+- buttons
+- inputs
+- forms
+- selects/comboboxes
+- checkboxes/radios/switches
+- textareas
+- date/time pickers
+- file uploaders
+- cards
+- tables
+- data lists
+- data grids
+- charts
+- stats/metrics
+- badges/chips
+- avatars
+- breadcrumbs
+- pagination
+- steppers
+- modals
+- drawers/sheets
+- tooltips
+- popovers/menus
+- navigation
+- sidebars
+- top bars/headers
+- command palette
+- tabs
+- accordions
+- carousels
+- progress indicators
+- skeletons
+- alerts/toasts
+- notifications center
+- search
+- empty states
+- onboarding
+- authentication screens
+- settings pages
+- documentation layouts
+- feedback components
+- pricing blocks
+- data visualization wrappers
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states
+
+## Writing Tone
+concise, confident, helpful
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid ambiguous labels
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->

package/template/.claude/skills/typeui-bold/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: bold
+description: Strong visual presence with heavyweight typography, high-contrast colors, and commanding layouts.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Bold Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Bold.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+
+
+## Style Foundations
+- Visual style: bold
+- Typography scale: desktop-first expressive scale | Fonts: primary=Archivo Black, display=Archivo Black, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, secondary | Tokens: primary=#0077BC, secondary=#009866, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#111111, text=#111827
+- Spacing scale: 4/8/12/16/24/32
+
+## Component Families
+- buttons
+- inputs
+- forms
+- selects/comboboxes
+- checkboxes/radios/switches
+- textareas
+- date/time pickers
+- file uploaders
+- cards
+- tables
+- data lists
+- data grids
+- charts
+- stats/metrics
+- badges/chips
+- avatars
+- breadcrumbs
+- pagination
+- steppers
+- modals
+- drawers/sheets
+- tooltips
+- popovers/menus
+- navigation
+- sidebars
+- top bars/headers
+- command palette
+- tabs
+- accordions
+- carousels
+- progress indicators
+- skeletons
+- alerts/toasts
+- notifications center
+- search
+- empty states
+- onboarding
+- authentication screens
+- settings pages
+- documentation layouts
+- feedback components
+- pricing blocks
+- data visualization wrappers
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states, screen-reader tested labels, reduced-motion support, 44px+ touch targets, high-contrast support
+
+## Writing Tone
+friendly, professional
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid ambiguous labels
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->

package/template/.claude/skills/typeui-clean/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: clean
+description: Simplicity-focused design with ample whitespace, legible typography, and a limited color palette to reduce visual clutter.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Clean Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Clean.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+Clean design style focuses on simplicity, minimalism, and high usability, using ample whitespace, legible typography, and limited color palettes to reduce visual clutter
+
+## Style Foundations
+- Visual style: minimal, clean
+- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Roboto, display=Poppins, mono=Inconsolata | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#3B82F6, secondary=#8B5CF6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
+- Spacing scale: 8pt baseline grid
+
+## Component Families
+- buttons
+- inputs
+- forms
+- selects/comboboxes
+- checkboxes/radios/switches
+- textareas
+- date/time pickers
+- file uploaders
+- cards
+- tables
+- data lists
+- data grids
+- charts
+- stats/metrics
+- badges/chips
+- avatars
+- breadcrumbs
+- pagination
+- steppers
+- modals
+- drawers/sheets
+- tooltips
+- popovers/menus
+- navigation
+- sidebars
+- top bars/headers
+- command palette
+- tabs
+- accordions
+- carousels
+- progress indicators
+- skeletons
+- alerts/toasts
+- notifications center
+- search
+- empty states
+- onboarding
+- authentication screens
+- settings pages
+- documentation layouts
+- feedback components
+- pricing blocks
+- data visualization wrappers
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, screen-reader tested labels, reduced-motion support, 44px+ touch targets
+
+## Writing Tone
+clear, friendly
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- keep interaction states explicit
+- design for empty/loading/error states
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid decorative motion without purpose
+- avoid ambiguous labels
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->

package/template/.claude/skills/typeui-dashboard/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: dashboard
+description: Dark-themed cloud-platform aesthetic with modular grids, glass-like panels, and strong data hierarchy for productivity dashboards.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Dashboard Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Dashboard.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+Dashboard design emphasizes grids, modular components, and strong visual hierarchy to present complex data in a clear and accessible way. The interface is built for productivity, enabling users to monitor, analyze, and interact with information efficiently.
+
+## Style Foundations
+- Visual style: modern, clean, cloud-platform aesthetic (Heroku/Vercel/GitHub inspired), dark theme, subtle gradients, soft shadows, glass-like panels, rounded components
+- Typography scale: 12/14/16/20/24/32 | Fonts: primary=IBM Plex Sans, display=IBM Plex Sans, mono=IBM Plex Sans | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#0C5CAB, secondary=#0a4a8a, success=#10b981, warning=#f59e0b, danger=#ef4444, surface=#09090b, text=#fafafa
+- Spacing scale: 8pt baseline grid
+
+## Component Families
+- buttons
+- inputs
+- forms
+- selects/comboboxes
+- checkboxes/radios/switches
+- textareas
+- date/time pickers
+- file uploaders
+- cards
+- tables
+- data lists
+- data grids
+- charts
+- stats/metrics
+- badges/chips
+- avatars
+- breadcrumbs
+- pagination
+- steppers
+- modals
+- drawers/sheets
+- tooltips
+- popovers/menus
+- navigation
+- sidebars
+- top bars/headers
+- command palette
+- tabs
+- accordions
+- carousels
+- progress indicators
+- skeletons
+- alerts/toasts
+- notifications center
+- search
+- empty states
+- onboarding
+- authentication screens
+- settings pages
+- documentation layouts
+- feedback components
+- pricing blocks
+- data visualization wrappers
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, screen-reader tested labels, reduced-motion support, 44px+ touch targets, high-contrast support
+
+## Writing Tone
+concise, confident, helpful, clear, friendly, professional, action-oriented, low-jargon
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+- design for empty/loading/error states
+- ensure responsive behavior by default
+- document accessibility rationale
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid decorative motion without purpose
+- avoid ambiguous labels
+- avoid mixing multiple visual metaphors
+- avoid inaccessible hit areas
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->

package/template/.claude/skills/typeui-doodle/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: doodle
+description: Hand-drawn, sketch-like style with doodles, handwritten fonts, and imperfect lines for a playful, informal feel.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Doodle Design System Skill (Universal)
+
+## Mission
+
+You are an expert design-system guideline author for Doodle.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+
+a creative, playful, and informal style that utilizes doodles, sketches, handwritten fonts, and imperfect lines to foster emotional connection and a raw, artistic feel
+
+## Style Foundations
+
+- Visual style: playful
+- Typography scale: 14/16/18/24/32/40 | Fonts: primary=Delius Swash Caps, display=Delius Swash Caps, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#49B6E5, secondary=#263D5B, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
+- Spacing scale: 4/8/12/16/24/32
+
+## Component Families
+
+- buttons
+- inputs
+- forms
+- selects/comboboxes
+- checkboxes/radios/switches
+- textareas
+- date/time pickers
+- file uploaders
+- cards
+- tables
+- data lists
+- data grids
+- charts
+- stats/metrics
+- badges/chips
+- avatars
+- breadcrumbs
+- pagination
+- steppers
+- modals
+- drawers/sheets
+- tooltips
+- popovers/menus
+- navigation
+- sidebars
+- top bars/headers
+- command palette
+- tabs
+- accordions
+- carousels
+- progress indicators
+- skeletons
+- alerts/toasts
+- notifications center
+- search
+- empty states
+- onboarding
+- authentication screens
+- settings pages
+- documentation layouts
+- feedback components
+- pricing blocks
+- data visualization wrappers
+
+## Accessibility
+
+WCAG 2.2 AA, keyboard-first interactions, visible focus states
+
+## Writing Tone
+
+concise, confident, helpful
+
+## Rules: Do
+
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+
+## Rules: Don't
+
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid ambiguous labels
+
+## Expected Behavior
+
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+
+When generating design-system guidance, use this structure:
+
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->