start-vibing 4.1.0 → 4.1.2

package/template/.claude/skills/test-coverage/reference/playwright-patterns.md

@@ -0,0 +1,260 @@
+# Playwright E2E Testing Patterns
+
+## Page Object Model (POM)
+
+### Base Page
+
+```typescript
+// tests/e2e/pages/base.page.ts
+import { Page, Locator } from '@playwright/test';
+
+export abstract class BasePage {
+	readonly page: Page;
+
+	constructor(page: Page) {
+		this.page = page;
+	}
+
+	async goto(path: string): Promise<void> {
+		await this.page.goto(path);
+	}
+
+	async waitForLoad(): Promise<void> {
+		await this.page.waitForLoadState('networkidle');
+	}
+
+	getByTestId(id: string): Locator {
+		return this.page.getByTestId(id);
+	}
+
+	async takeScreenshot(name: string): Promise<void> {
+		await this.page.screenshot({ path: `screenshots/${name}.png` });
+	}
+}
+```
+
+### Specific Page
+
+```typescript
+// tests/e2e/pages/login.page.ts
+import { BasePage } from './base.page';
+
+export class LoginPage extends BasePage {
+	readonly emailInput = this.getByTestId('email-input');
+	readonly passwordInput = this.getByTestId('password-input');
+	readonly submitButton = this.getByTestId('submit-button');
+	readonly errorMessage = this.getByTestId('error-message');
+
+	async login(email: string, password: string): Promise<void> {
+		await this.emailInput.fill(email);
+		await this.passwordInput.fill(password);
+		await this.submitButton.click();
+	}
+
+	async expectError(message: string): Promise<void> {
+		await expect(this.errorMessage).toContainText(message);
+	}
+}
+```
+
+---
+
+## Custom Fixtures
+
+### Database Fixture
+
+```typescript
+// tests/e2e/fixtures/db.fixture.ts
+import { test as base } from '@playwright/test';
+import { MongoClient, Db, ObjectId } from 'mongodb';
+
+type DbFixture = {
+	db: Db;
+	createdIds: Map<string, ObjectId[]>;
+	trackCreated: (collection: string, id: ObjectId) => void;
+};
+
+export const test = base.extend<DbFixture>({
+	db: async ({}, use) => {
+		const client = await MongoClient.connect(process.env['MONGODB_URI']!);
+		const db = client.db();
+		await use(db);
+		await client.close();
+	},
+
+	createdIds: async ({}, use) => {
+		await use(new Map());
+	},
+
+	trackCreated: async ({ createdIds }, use) => {
+		const track = (collection: string, id: ObjectId) => {
+			const ids = createdIds.get(collection) || [];
+			ids.push(id);
+			createdIds.set(collection, ids);
+		};
+		await use(track);
+	},
+});
+
+// Auto-cleanup after each test
+test.afterEach(async ({ db, createdIds }) => {
+	for (const [collection, ids] of createdIds.entries()) {
+		if (ids.length > 0) {
+			await db.collection(collection).deleteMany({
+				_id: { $in: ids },
+			});
+		}
+	}
+});
+```
+
+### Auth Fixture
+
+```typescript
+// tests/e2e/fixtures/auth.fixture.ts
+import { test as base } from '@playwright/test';
+
+type AuthFixture = {
+	authenticatedPage: Page;
+};
+
+export const test = base.extend<AuthFixture>({
+	authenticatedPage: async ({ browser }, use) => {
+		const context = await browser.newContext({
+			storageState: 'tests/e2e/.auth/user.json',
+		});
+		const page = await context.newPage();
+		await use(page);
+		await context.close();
+	},
+});
+```
+
+---
+
+## Multi-Viewport Testing
+
+### Config
+
+```typescript
+// playwright.config.ts
+import { defineConfig, devices } from '@playwright/test';
+
+export default defineConfig({
+	projects: [
+		{
+			name: 'Desktop Chrome',
+			use: { ...devices['Desktop Chrome'] },
+		},
+		{
+			name: 'Tablet',
+			use: { ...devices['iPad'] },
+		},
+		{
+			name: 'Mobile',
+			use: { ...devices['iPhone 14'] },
+		},
+	],
+});
+```
+
+### Viewport-Aware Tests
+
+```typescript
+test('navigation adapts to viewport', async ({ page, isMobile }) => {
+	await page.goto('/');
+
+	if (isMobile) {
+		// Mobile: hamburger menu
+		await expect(page.getByTestId('hamburger-menu')).toBeVisible();
+		await page.getByTestId('hamburger-menu').click();
+		await expect(page.getByTestId('mobile-nav')).toBeVisible();
+	} else {
+		// Desktop: sidebar
+		await expect(page.getByTestId('sidebar')).toBeVisible();
+	}
+});
+```
+
+---
+
+## API Testing
+
+### REST
+
+```typescript
+test.describe('REST API', () => {
+	test('requires authentication', async ({ request }) => {
+		const response = await request.get('/api/users');
+		expect(response.status()).toBe(401);
+	});
+
+	test('validates input', async ({ request }) => {
+		const response = await request.post('/api/users', {
+			data: { email: 'invalid' },
+		});
+		expect(response.status()).toBe(400);
+		const body = await response.json();
+		expect(body.errors).toBeDefined();
+	});
+});
+```
+
+### tRPC
+
+```typescript
+test.describe('tRPC API', () => {
+	test('handles validation errors', async ({ request }) => {
+		const response = await request.post('/api/trpc/user.create', {
+			data: { json: { name: '' } },
+		});
+		const body = await response.json();
+		expect(body.error.data.code).toBe('BAD_REQUEST');
+	});
+});
+```
+
+---
+
+## Best Practices
+
+### Use data-testid
+
+```tsx
+// Component
+<button data-testid="submit-button">Submit</button>;
+
+// Test
+await page.getByTestId('submit-button').click();
+```
+
+### Wait for Network
+
+```typescript
+// Wait for all network requests to finish
+await page.waitForLoadState('networkidle');
+
+// Wait for specific request
+await page.waitForResponse('/api/users');
+```
+
+### Retries for Flaky Tests
+
+```typescript
+// playwright.config.ts
+export default defineConfig({
+	retries: process.env.CI ? 2 : 0,
+});
+```
+
+### Screenshots on Failure
+
+```typescript
+// playwright.config.ts
+export default defineConfig({
+	use: {
+		screenshot: 'only-on-failure',
+		trace: 'on-first-retry',
+	},
+});
+```

package/template/.claude/skills/test-coverage/scripts/coverage-check.sh

@@ -0,0 +1,52 @@
+#!/bin/bash
+# Test Coverage Check Script
+# Usage: bash .claude/skills/test-coverage/scripts/coverage-check.sh [threshold]
+
+set -e
+
+THRESHOLD=${1:-80}
+
+echo "========================================"
+echo "      TEST COVERAGE CHECK"
+echo "      Threshold: ${THRESHOLD}%"
+echo "========================================"
+echo ""
+
+# Run tests with coverage
+echo "Running tests with coverage..."
+bun test --coverage 2>&1 | tee coverage-output.txt
+
+# Extract coverage percentage (adjust regex based on your test framework)
+COVERAGE=$(grep -E "All files.*\|" coverage-output.txt | awk '{print $4}' | tr -d '%' || echo "0")
+
+echo ""
+echo "========================================"
+echo "           RESULTS"
+echo "========================================"
+
+if [ -z "$COVERAGE" ] || [ "$COVERAGE" = "0" ]; then
+    echo "⚠ Could not determine coverage percentage"
+    echo "Check coverage-output.txt for details"
+    exit 1
+fi
+
+echo "Coverage: ${COVERAGE}%"
+echo "Threshold: ${THRESHOLD}%"
+echo ""
+
+# Compare (using bc for decimal comparison)
+PASS=$(echo "$COVERAGE >= $THRESHOLD" | bc -l 2>/dev/null || echo "0")
+
+if [ "$PASS" = "1" ]; then
+    echo "✓ Coverage meets threshold!"
+    rm -f coverage-output.txt
+    exit 0
+else
+    echo "✗ Coverage below threshold!"
+    echo ""
+    echo "Files needing more coverage:"
+    grep -E "^\s+[a-zA-Z].*\|.*\|.*\|.*\|" coverage-output.txt | \
+        awk -F'|' '{if ($2 < '$THRESHOLD' || $3 < '$THRESHOLD') print $1, $2"%", $3"%"}' || true
+    rm -f coverage-output.txt
+    exit 1
+fi

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

@@ -0,0 +1,133 @@
+---
+name: ant
+description: Structured, enterprise-focused design system emphasizing clarity, consistency, and efficiency for data-dense web applications.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Ant Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Ant.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+Ant Design follows a structured, enterprise-focused design system that emphasizes clarity, consistency, and efficiency in complex web applications.
+
+## Style Foundations
+- Visual style: data-dense, enterprise
+- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Plus Jakarta Sans, display=Plus Jakarta Sans, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#1677ff, secondary=#8B5CF6, 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, 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-application/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: application
+description: Vercel/GitHub-inspired app dashboard with purple-themed aesthetic, top-bar navigation, card-based layouts, and developer-first workflows.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Application Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Application.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+A modern, Vercel/GitHub-inspired application dashboard designed for clarity, speed, and developer-first workflows. The interface focuses on simplicity and visual hierarchy, allowing teams to monitor, deploy, and manage applications effortlessly from a single control center. Features a top-bar only navigation (no sidebar) and a clean purple-themed aesthetic.
+
+## Style Foundations
+- Visual style: modern, clean, high-contrast, glass-like panels, soft shadows, rounded components
+- 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 (purple), neutral, success, warning, danger | Tokens: primary=#9333ea, secondary=#a855f7, success=#10b981, warning=#f59e0b, danger=#ef4444, surface=#FFFFFF, text=#09090b
+- Layout: Top-bar only navigation, structured grid layout, card-based content
+- 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-artistic/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: artistic
+description: High-contrast, expressive style with creative typography and bold color choices for visually striking interfaces.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Artistic Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Artistic.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+
+
+## Style Foundations
+- Visual style: high-contrast, artistic
+- Typography scale: 12/14/16/18/24/30/36 | Fonts: primary=Limelight, display=Limelight, mono=JetBrains Mono | 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: 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, semantic HTML before ARIA, screen-reader tested labels, reduced-motion support, 44px+ touch targets, high-contrast support
+
+## Writing Tone
+concise, confident, professional, action-oriented
+
+## 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 -->