opencode-skills-collection 3.1.12 → 3.1.13

package/bundled-skills/ux-copy/SKILL.md

@@ -1,83 +1,115 @@
 ---
 name: ux-copy
-description: "Generate UX microcopy in StyleSeed's Toss-inspired voice for buttons, empty states, errors, toasts, confirmations, and form guidance."
-category: design
-risk: safe
-source: community
+description: Generate UX microcopy (button labels, error messages, empty states, toasts) following a casual-but-polite voice and tone
+risk: unknown
+source: https://github.com/bitjaru/styleseed/tree/main/engine/.claude/skills/ss-copy
 source_repo: bitjaru/styleseed
 source_type: community
-date_added: "2026-04-08"
-author: bitjaru
-tags: [ux, copywriting, microcopy, frontend, styleseed]
-tools: [claude, cursor, codex, gemini]
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/bitjaru/styleseed/blob/main/LICENSE
 ---
 
-# UX Copy
-
-## Overview
-
-Part of [StyleSeed](https://github.com/bitjaru/styleseed), this skill generates concise product copy for common UI states. It follows the Toss-inspired tone: casual but polite, direct, active, and specific enough to help the user recover or proceed.
-
+# UX Microcopy Generator
 ## When to Use
-- Use when you need button labels, helper text, toasts, empty states, or error messages
-- Use when a feature has functional UI but weak or robotic wording
-- Use when you want consistent product voice across a flow
-- Use when confirmation dialogs or state feedback need better phrasing
-
-## Tone Rules
-
-- casual but polite
-- active voice over passive voice
-- positive framing where it stays honest
-- plain language instead of internal jargon
-- concise wording where every word earns its place
-
-## Common Patterns
-
-### Buttons
-
-Use a short action verb plus object when needed.
-
-### Empty States
-
-Start with a friendly observation, then suggest the next action.
-
-### Errors
-
-Explain what happened in user-facing language and what to do next. Do not surface raw internal error strings.
 
-### Toasts
-
-Confirm the result quickly. Add an undo action for reversible destructive behavior.
-
-### Forms
-
-Use clear labels, useful placeholders, specific helper text, and corrective error messages.
-
-### Confirmation Dialogs
-
-State the action in plain language and explain the consequence if the decision is risky or irreversible.
-
-## Output
-
-Return:
-1. The requested microcopy grouped by UI surface
-2. Notes on tone or localization considerations if relevant
-3. Any places where the UX likely needs a structural fix in addition to better copy
-
-## Best Practices
-
-- Make the next action obvious
-- Avoid generic labels like "Submit" or "OK" when the action can be named precisely
-- Blame the system, not the user, when something fails
-- Keep error and empty states useful even without visual context
-
-## Additional Resources
-
-- [StyleSeed repository](https://github.com/bitjaru/styleseed)
-- [Source skill](https://github.com/bitjaru/styleseed/blob/main/seeds/toss/.claude/skills/ux-copy/SKILL.md)
+Use this skill when you need generate UX microcopy (button labels, error messages, empty states, toasts) following a casual-but-polite voice and tone.
+
+
+## When NOT to use
+
+- For long-form content (blog posts, docs, marketing pages) — out of scope
+- For full feedback state design (not just text) → use `/ss-feedback`
+- For brand voice/tone definition itself — this skill consumes a voice spec, doesn't create it
+- For translations to non-English languages — single-language only
+
+Context: **$0**
+Description: $ARGUMENTS
+
+> **Read `engine/UX-WRITING.md` first** — it's the rule set this skill applies: buttons
+> name the action (not "Submit"), errors help instead of blame, empty states invite,
+> money copy stays calm, one term per concept. Korean/CJK projects: see §W8 for the
+> clear-calm-human "Toss feel" (존댓말 일관성, 사용자 관점 "내 계좌", 군더더기 빼기).
+
+## Instructions
+
+1. Read the design language reference:
+   - `DESIGN-LANGUAGE.md` sections on Microcopy Tone Guide and UX Writing
+
+2. Apply the voice principles:
+
+### Tone Rules
+- **Casual but polite**: Friendly, not robotic. Like talking to a helpful friend.
+- **Active voice**: "We saved your changes" not "Your changes have been saved"
+- **Positive framing**: "Free shipping on orders over $30" not "Orders under $30 have shipping fees"
+- **Plain language**: "Send money" not "Initiate transfer"
+- **Concise**: Every word must earn its place
+
+### Copy Patterns by Context
+
+#### Button Labels (CTA)
+```
+Format: [Action verb] + [Object] (optional)
+Good: "Place order", "Get started", "Save changes", "Try again"
+Bad:  "Submit", "OK", "Click here", "Proceed to next step"
+```
+- One primary CTA per screen
+- Label must clearly describe what happens next
+- Max 3 words for primary CTA
+
+#### Empty States
+```
+Format: [Friendly observation] + [Suggested action]
+Good: "No activity yet. Create your first project to get started."
+Bad:  "No data found."
+```
+- Always suggest a next action
+- Use a relevant icon (32px, text-text-tertiary)
+- Tone: encouraging, not blaming
+
+#### Error Messages
+```
+Format: [What happened] + [What to do]
+Good: "Couldn't load the data. Please try again."
+Bad:  "Error 500: Internal Server Error"
+```
+- Never show technical errors to users
+- Blame the system, not the user
+- Always provide a recovery action
+
+#### Toast Notifications
+```
+Format: [Confirmation of what happened]
+Good: "Saved!", "Changes applied", "Item deleted · Undo"
+Bad:  "Operation completed successfully"
+```
+- Max 2 lines
+- Include "Undo" link for reversible destructive actions
+- Info toasts: 3 seconds. Action toasts: 5 seconds.
+
+#### Form Labels & Helpers
+```
+Label: Noun phrase ("Email address", "Password")
+Placeholder: Example or hint ("name@example.com")
+Helper: Format guidance ("Must be at least 8 characters")
+Error: Specific issue ("This email is already registered")
+```
+
+#### Confirmation Dialogs
+```
+Title: [Question about the action]
+Body: [Consequence explanation]
+Primary: [Action verb] ("Delete", "Confirm")
+Secondary: "Close" (not "Cancel" — avoids confusion)
+```
+
+3. Generate copy for the requested context, providing:
+   - Primary copy (what to display)
+   - Variants (if context varies)
+   - Do's and Don'ts for the specific context
 
 ## Limitations
-- Use this skill only when the task clearly matches the scope described above.
-- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
-- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/ux-feedback/SKILL.md

@@ -1,68 +1,116 @@
 ---
 name: ux-feedback
-description: "Add loading, empty, error, and success feedback states to StyleSeed components and pages with practical mobile-first rules."
-category: design
-risk: safe
-source: community
+description: Add appropriate user feedback states (loading, success, error, empty) to a component or page
+risk: unknown
+source: https://github.com/bitjaru/styleseed/tree/main/engine/.claude/skills/ss-feedback
 source_repo: bitjaru/styleseed
 source_type: community
-date_added: "2026-04-08"
-author: bitjaru
-tags: [ux, states, loading, error-handling, styleseed]
-tools: [claude, cursor, codex, gemini]
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/bitjaru/styleseed/blob/main/LICENSE
 ---
 
-# UX Feedback
-
-## Overview
-
-Part of [StyleSeed](https://github.com/bitjaru/styleseed), this skill ensures data-dependent UI does not stop at the happy path. It adds the four core feedback states every serious product needs: loading, empty, error, and success.
-
+# UX Feedback States Generator
 ## When to Use
-- Use when a component or page fetches, mutates, or depends on async data
-- Use when a flow currently renders only the success path
-- Use when a card, list, or page needs better state communication
-- Use when the product needs clear recovery and confirmation behavior
-
-## The Four Required States
-
-### Loading
-
-Use skeletons that match the final layout. Avoid spinners inside cards unless the pattern genuinely requires them. Delay skeletons slightly to avoid flashes on fast responses.
-
-### Empty
-
-Provide a friendly explanation and a next action. Zero values should still render meaningfully instead of disappearing.
-
-### Error
 
-Use plain-language failure messages and always offer recovery where possible. Localize failures to the affected card or section if the rest of the page can still work.
-
-### Success
-
-Use toasts or equivalent lightweight confirmation for completed actions. Add undo for reversible destructive changes.
-
-## Output
-
-Return:
-1. The data-dependent areas identified
-2. The loading, empty, error, and success states added for each one
-3. Any reusable empty-state or toast patterns created
-4. Follow-up work needed for analytics, retries, or accessibility
-
-## Best Practices
-
-- Match loading placeholders to the real layout
-- Keep partial failure isolated whenever possible
-- Make recovery obvious, not hidden in logs or developer tools
-- Use success feedback sparingly but clearly
-
-## Additional Resources
-
-- [StyleSeed repository](https://github.com/bitjaru/styleseed)
-- [Source skill](https://github.com/bitjaru/styleseed/blob/main/seeds/toss/.claude/skills/ux-feedback/SKILL.md)
+Use this skill when you need add appropriate user feedback states (loading, success, error, empty) to a component or page.
+
+
+## When NOT to use
+
+- For only the words inside a state → use `/ss-copy`
+- For accessibility issues in existing states → use `/ss-a11y`
+- For brand-new component creation → use `/ss-component`
+- For analytics or error-logging plumbing — UI presentation only
+
+Target: **$ARGUMENTS**
+
+## Instructions
+
+1. Read the target file and identify all data-dependent areas.
+
+2. Read the design language reference:
+   - `DESIGN-LANGUAGE.md` sections on Loading States (Skeleton), Empty States, Error States
+
+3. For each data-dependent area, implement ALL 4 states:
+
+### State 1: Loading (Skeleton)
+```tsx
+// Skeleton must match the final layout shape
+<div className="bg-card rounded-2xl p-6 shadow-[var(--shadow-card)]">
+  <div className="flex items-center gap-2 mb-3">
+    <div className="size-7 bg-surface-muted rounded-lg animate-pulse" />
+    <div className="h-3 w-16 bg-surface-muted rounded animate-pulse" />
+  </div>
+  <div className="h-9 w-24 bg-surface-muted rounded-lg animate-pulse mb-3" />
+  <div className="h-3 w-12 bg-surface-muted rounded animate-pulse" />
+</div>
+```
+Rules:
+- Show skeleton for 300ms minimum (prevent flash)
+- Delay skeleton display by 300ms (fast loads skip skeleton entirely)
+- Use `animate-pulse` (1.5s cycle)
+- Match skeleton shapes to real content dimensions
+- Never use spinners inside cards
+
+### State 2: Empty (Zero Data)
+```tsx
+<EmptyState
+  icon={PackageIcon}
+  title="No activity yet"
+  description="Create your first project to get started."
+  action={<Button>Create Project</Button>}
+/>
+```
+Rules:
+- Center-aligned in the card
+- Icon: 32px, `text-text-tertiary`
+- Title: 14px, `text-text-secondary`
+- Always suggest a next action
+- Zero values show as "0" (don't hide or dash)
+
+### State 3: Error (Load Failed)
+```tsx
+<div className="flex flex-col items-center justify-center py-8 text-center">
+  <AlertCircle className="size-8 text-destructive mb-3" />
+  <p className="text-[14px] text-text-secondary mb-4">Couldn't load the data</p>
+  <Button variant="brandGhost" size="sm" onClick={retry}>Try again</Button>
+</div>
+```
+Rules:
+- Partial failure: only affected card shows error, rest loads normally
+- Full page failure: full-screen EmptyState with retry
+- Error message: plain language, blame the system
+- Always provide retry button
+
+### State 4: Success (Action Feedback)
+```tsx
+// Toast notification for action confirmations
+toast("Changes saved")
+
+// With undo for destructive actions
+toast("Item deleted", { action: { label: "Undo", onClick: handleUndo } })
+```
+Rules:
+- Info toast: 3s display
+- Action toast (with undo): 5s display
+- Toast position: above BottomNav
+- One toast at a time (new replaces old)
+
+4. Implementation pattern:
+```tsx
+function DataCard({ data, isLoading, error }) {
+  if (isLoading) return <DataCardSkeleton />
+  if (error) return <DataCardError onRetry={refetch} />
+  if (!data || data.length === 0) return <DataCardEmpty />
+  return <DataCardContent data={data} />
+}
+```
+
+5. Check `prefers-reduced-motion` — disable `animate-pulse` when reduced motion is preferred.
 
 ## Limitations
-- Use this skill only when the task clearly matches the scope described above.
-- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
-- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/ux-flow/SKILL.md

@@ -1,72 +1,73 @@
 ---
 name: ux-flow
-description: "Design user flows and screen structure using StyleSeed UX patterns such as progressive disclosure, hub-and-spoke navigation, and information pyramids."
-category: design
-risk: safe
-source: community
+description: Design user flows and navigation structure following proven UX patterns
+risk: unknown
+source: https://github.com/bitjaru/styleseed/tree/main/engine/.claude/skills/ss-flow
 source_repo: bitjaru/styleseed
 source_type: community
-date_added: "2026-04-08"
-author: bitjaru
-tags: [ux, flows, navigation, product-design, styleseed]
-tools: [claude, cursor, codex, gemini]
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/bitjaru/styleseed/blob/main/LICENSE
 ---
 
-# UX Flow
-
-## Overview
-
-Part of [StyleSeed](https://github.com/bitjaru/styleseed), this skill designs flows before screens. It uses proven UX patterns to define entry points, exits, screen inventory, and navigation structure so the implementation has a coherent user journey instead of a pile of disconnected pages.
-
+# UX Flow Designer
 ## When to Use
-- Use when planning onboarding, checkout, account management, dashboards, or drill-down flows
-- Use when a new feature spans multiple screens or modal states
-- Use when users need a clear path through a task instead of a single isolated page
-- Use when the UI needs navigation logic before components are built
 
-## How It Works
+Use this skill when you need design user flows and navigation structure following proven UX patterns.
 
-### Information Architecture Principles
 
-- progressive disclosure: reveal complexity only when needed
-- Miller's Law: chunk content into manageable groups
-- Hick's Law: minimize decision overload on each screen
+## When NOT to use
 
-### Common Navigation Models
+- For implementing a single page → use `/ss-page` after the flow is settled
+- For copy on each step → use `/ss-copy` after the structure is settled
+- For information architecture of an entire product — narrow scope to one flow first
+- For high-fidelity mockups — this produces a flow map, not pixel-perfect designs
 
-- hub and spoke for dashboards and detail views
-- linear flow for onboarding, forms, and checkout
-- tab navigation for 3 to 5 top-level areas
+Design a user flow: **$0**
+Description: $ARGUMENTS
 
-### Flow Rules
+## Instructions
 
-- every flow has a clear entry point
-- every flow has a clear exit or success condition
-- key features should usually be reachable within three taps from home
-- non-root screens need back navigation
-- loading, empty, and error states need explicit recovery paths
+1. Read the design system reference:
+   - `CLAUDE.md` for component inventory
+   - `DESIGN-LANGUAGE.md` for layout patterns (sections 13-14, 19-20)
+   - `components/patterns/` for available building blocks
 
-## Output
+2. Apply these UX principles:
 
-Provide:
-1. An ASCII flow diagram
-2. A screen inventory with each screen's purpose
-3. Edge cases for loading, empty, and error states
-4. Recommended page scaffolds and reusable patterns to implement next
+### Information Architecture
+- **Progressive Disclosure**: Show only what's needed at each step. Hide complexity behind logical drill-downs.
+- **Miller's Law**: Chunk information into groups of 5-9 items maximum.
+- **Hick's Law**: Minimize choices per screen. Fewer options = faster decisions.
 
-## Best Practices
+### Navigation Patterns
+- **Hub & Spoke**: Dashboard → detail pages → back to dashboard (default for mobile apps)
+- **Linear Flow**: Step 1 → Step 2 → Step 3 (for forms, onboarding, checkout)
+- **Tab Navigation**: 3-5 top-level sections via BottomNav
 
-- Optimize for clarity before density
-- Let one screen answer one primary question
-- Keep escape hatches visible for risky or destructive steps
-- Define state transitions before drawing detailed layouts
+### Screen Flow Rules
+- Every flow must have a **clear entry point** and **clear exit point**
+- Maximum **3 taps** to reach any key feature from the home screen
+- Back navigation must always be available (except root screens)
+- Error states must provide **recovery paths** (retry, go back, contact support)
+- Loading states must use skeleton screens (never spinners in cards)
 
-## Additional Resources
+### Page Composition (from DESIGN-LANGUAGE.md)
+- Follow the **Information Pyramid**: Hero → KPI Grid → Details → Lists
+- Each screen should answer ONE primary question
+- Above the fold: the most important metric or action
+- Use the 4 section types: Full Card (A), Grid (B), Carousel (C), Hero (D)
 
-- [StyleSeed repository](https://github.com/bitjaru/styleseed)
-- [Source skill](https://github.com/bitjaru/styleseed/blob/main/seeds/toss/.claude/skills/ux-flow/SKILL.md)
+3. Output format:
+   - **Flow diagram** in ASCII showing screen connections
+   - **Screen inventory** listing each screen's purpose and key components
+   - **Edge cases** (empty states, errors, loading) for each screen
+   - **Scaffolded pages** using `PageShell`, `TopBar`, `BottomNav` patterns
+
+4. Generate the actual page files using `/ss-page` conventions.
 
 ## Limitations
-- Use this skill only when the task clearly matches the scope described above.
-- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
-- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/vitest-skill/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: vitest-skill
+description: 'Generates Vitest tests in JavaScript/TypeScript with Vite-native speed. Jest-compatible API with ESM support and HMR. Use when user mentions "Vitest", "vi.mock", "vitest.config". Triggers on: "Vitest", "vi.mock", "vi.fn", "Vite test", "vitest config".'
+risk: unknown
+source: https://github.com/LambdaTest/agent-skills/tree/main/vitest-skill
+source_repo: LambdaTest/agent-skills
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/LambdaTest/agent-skills/blob/main/LICENSE
+---
+
+# Vitest Testing Skill
+## When to Use
+
+Use this skill when you need generates Vitest tests in JavaScript/TypeScript with Vite-native speed. Jest-compatible API with ESM support and HMR. Use when user mentions "Vitest", "vi.mock", "vitest.config". Triggers on: "Vitest", "vi.mock", "vi.fn", "Vite test", "vitest config".
+
+
+## Core Patterns
+
+### Basic Test
+
+```typescript
+import { describe, it, expect, vi, beforeEach } from 'vitest';
+import { Calculator } from './calculator';
+
+describe('Calculator', () => {
+  let calc: Calculator;
+  beforeEach(() => { calc = new Calculator(); });
+
+  it('adds two numbers', () => {
+    expect(calc.add(2, 3)).toBe(5);
+  });
+
+  it('throws on divide by zero', () => {
+    expect(() => calc.divide(10, 0)).toThrow();
+  });
+});
+```
+
+### Mocking (vi instead of jest)
+
+```typescript
+import { vi } from 'vitest';
+
+// Mock module
+vi.mock('./database', () => ({
+  getUser: vi.fn().mockResolvedValue({ name: 'Alice' }),
+  saveUser: vi.fn().mockResolvedValue(true),
+}));
+
+// Mock function
+const mockFn = vi.fn();
+mockFn.mockReturnValue(42);
+mockFn.mockResolvedValue({ data: 'test' });
+
+// Spy
+const spy = vi.spyOn(console, 'log').mockImplementation(() => {});
+expect(spy).toHaveBeenCalledWith('message');
+spy.mockRestore();
+
+// Timers
+vi.useFakeTimers();
+vi.advanceTimersByTime(1000);
+vi.runAllTimers();
+vi.useRealTimers();
+```
+
+### In-Source Testing
+
+```typescript
+// src/math.ts — tests alongside code!
+export function add(a: number, b: number) { return a + b; }
+export function multiply(a: number, b: number) { return a * b; }
+
+if (import.meta.vitest) {
+  const { it, expect } = import.meta.vitest;
+  it('adds', () => { expect(add(2, 3)).toBe(5); });
+  it('multiplies', () => { expect(multiply(3, 4)).toBe(12); });
+}
+```
+
+### Snapshot Testing
+
+```typescript
+it('serializes user', () => {
+  expect(serializeUser(user)).toMatchSnapshot();
+});
+
+it('inline snapshot', () => {
+  expect(serializeUser(user)).toMatchInlineSnapshot(`
+    { "name": "Alice", "email": "alice@test.com" }
+  `);
+});
+```
+
+### React Component Testing
+
+```typescript
+import { render, screen } from '@testing-library/react';
+import { describe, it, expect } from 'vitest';
+import Button from './Button';
+
+describe('Button', () => {
+  it('renders with label', () => {
+    render(<Button label="Click me" />);
+    expect(screen.getByText('Click me')).toBeDefined();
+  });
+});
+```
+
+### Anti-Patterns
+
+| Bad | Good | Why |
+|-----|------|-----|
+| `jest.fn()` | `vi.fn()` | Vitest uses `vi` |
+| `jest.mock()` | `vi.mock()` | Different namespace |
+| No type safety | TypeScript + strict | Vitest is TS-first |
+
+## Quick Reference
+
+| Task | Command |
+|------|---------|
+| Run once | `npx vitest run` |
+| Watch | `npx vitest` (default) |
+| UI | `npx vitest --ui` |
+| Coverage | `npx vitest --coverage` |
+| Specific file | `npx vitest run src/math.test.ts` |
+| Filter | `npx vitest run -t "adds"` |
+
+## vitest.config.ts
+
+```typescript
+import { defineConfig } from 'vitest/config';
+export default defineConfig({
+  test: {
+    globals: true,
+    environment: 'jsdom',
+    coverage: { provider: 'v8', reporter: ['text', 'html'] },
+    include: ['src/**/*.{test,spec}.{js,ts,tsx}'],
+    includeSource: ['src/**/*.{js,ts}'],
+  },
+});
+```
+
+## Deep Patterns → `reference/playbook.md`
+
+| § | Section | Lines |
+|---|---------|-------|
+| 1 | Production Configuration | Config, workspace, setup file |
+| 2 | Mocking Patterns | vi.mock, spies, timers, fetch |
+| 3 | React Testing Library | Components, hooks, providers |
+| 4 | Snapshot & Inline Snapshots | File, inline, serializers |
+| 5 | Table-Driven Tests | test.each, describe.each |
+| 6 | In-Source Testing | Co-located tests in source |
+| 7 | API / Integration Testing | Server tests with fetch |
+| 8 | CI/CD Integration | GitHub Actions, scripts |
+| 9 | Debugging Quick-Reference | 10 common problems |
+| 10 | Best Practices Checklist | 13 items |
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.