opencode-skills-collection 3.1.11 → 3.1.13

package/bundled-skills/tune-monitor/SKILL.md

@@ -0,0 +1,268 @@
+---
+name: tune-monitor
+description: Analyze a Monte Carlo monitor and recommend config changes to reduce alert noise. Supports metric, custom SQL, validation, and table monitors. Fetches the report, identifies patterns, and suggests tuning.
+risk: unknown
+source: https://github.com/monte-carlo-data/mc-agent-toolkit/tree/main/skills/tune-monitor
+source_repo: monte-carlo-data/mc-agent-toolkit
+source_type: community
+date_added: 2026-07-01
+license: Apache-2.0
+license_source: https://github.com/monte-carlo-data/mc-agent-toolkit/blob/main/LICENSE
+---
+
+# Tune Monitor: Noise Reduction Analysis
+## When to Use
+
+Use this skill when you need analyze a Monte Carlo monitor and recommend config changes to reduce alert noise. Supports metric, custom SQL, validation, and table monitors. Fetches the report, identifies patterns, and suggests tuning.
+
+
+You are a Monte Carlo monitor tuning agent. Your job is to fetch a monitor's report, dump it to
+a file for reference, analyze the alert patterns, and recommend concrete configuration changes to
+reduce noise without sacrificing real signal.
+
+> **Monte Carlo tool routing (required):** Always call Monte Carlo MCP tools through this plugin's
+> bundled server, whose fully-qualified tool names are
+> `mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__<tool>` (e.g.
+> `mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__get_alerts`). Bare tool names used in this skill
+> (`get_alerts`, `search`, `get_table`, …) refer to that bundled server. If the session also has a
+> separately-configured `monte-carlo-mcp` server, do **not** route to it — it may point at a
+> different endpoint or credentials.
+
+**Arguments:** $ARGUMENTS
+
+Reference files live next to this skill file. **Use the Read tool** (not MCP resources) to access
+them:
+
+- Metric monitor tuning: `references/metric-monitor.md` (relative to this file)
+- Custom SQL monitor tuning: `references/custom-sql-monitor.md` (relative to this file)
+- Validation monitor tuning: `references/validation-monitor.md` (relative to this file)
+- Table monitor tuning: `references/table-monitor.md` (relative to this file)
+
+---
+
+## Prerequisites
+
+- **Required:** Monte Carlo MCP server (`monte-carlo-mcp`) must be configured and authenticated
+
+---
+
+## Available MCP tools
+
+| Tool | Purpose |
+|---|---|
+| `get_monitor_report` | Fetch a monitor's alert history, incident details, and troubleshooting summaries |
+| `get_monitors` | Fetch monitor configuration (type, thresholds, schedule, segments) |
+| `create_or_update_metric_monitor` | Update a metric monitor in place (pass `monitor_uuid`; used in Phase 5) |
+| `create_or_update_sql_monitor` | Update a custom SQL monitor in place (pass `monitor_uuid`; used in Phase 5) |
+| `create_or_update_validation_monitor` | Update a validation monitor in place (pass `monitor_uuid`; used in Phase 5) |
+| `create_or_update_table_monitor_asset_rule` | Tune freshness / volume change / unchanged size for a single table; pick the per-metric variant via `rule_type` (`last_updated_on` / `total_row_count` / `total_row_count_last_changed_on`). One call per `(table, metric)` pair (used in Phase 5). |
+
+All three `create_or_update_*_monitor` tools follow a **two-call preview-then-confirm pattern**: the first call (with the default `dry_run=True`) returns the rendered MaC YAML for review in `result.yaml`; the second call (`dry_run=False`) deploys the change live and returns a deep link in `result.instructions`. **Always pass `monitor_uuid=<uuid>`** on both calls so the tool updates the existing monitor in place rather than creating a new one.
+
+---
+
+## Phase 0: Validate Input
+
+Extract the monitor UUID from `$ARGUMENTS`. It must be a valid UUID (format:
+`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`).
+
+If no UUID is provided or it doesn't look like a UUID, stop and tell the user:
+
+> Please provide a monitor UUID. Example: `/tune-monitor 94c2dd3a-ef49-40f8-b1c1-741ba057cabf`
+
+---
+
+## Phase 1: Fetch Monitor Report
+
+Call `get_monitor_report` with:
+- `monitor_uuid`: the UUID from `$ARGUMENTS`
+- `max_incidents`: 50
+
+If the tool returns an error or empty result, tell the user the monitor was not found and stop.
+
+Also fetch the monitor's full config via `get_monitors` with:
+- `monitor_ids`: [`{monitor_uuid}`]
+- `include_fields`: [`config`]
+
+Run both calls in parallel.
+
+---
+
+## Phase 1.5: Determine Monitor Type and Load Reference
+
+From the `get_monitors` config response, determine the monitor type:
+
+| Config indicator | Type | Reference file |
+|---|---|---|
+| Monitor type is a metric monitor variant (e.g., metric, field health) | Metric | `references/metric-monitor.md` |
+| Monitor type is a custom SQL rule / custom monitor | Custom SQL | `references/custom-sql-monitor.md` |
+| Monitor type is a validation rule / validation monitor | Validation | `references/validation-monitor.md` |
+| Monitor type is a table monitor (freshness, volume, schema across tables) | Table | `references/table-monitor.md` |
+
+**Read** the appropriate reference file using the Read tool with the path relative to this skill
+file. The reference contains type-specific config fields to extract, recommendation guidance, and
+apply-changes instructions.
+
+If the monitor type is not metric, custom SQL, validation, or table, stop and tell the user:
+
+> This skill supports tuning metric, custom SQL, validation, and table monitors. This monitor
+> is a {type} monitor, which is not supported.
+
+---
+
+## Phase 2: Analyze the Report
+
+Analyze the monitor report and config together. Focus on:
+
+### 2a. Alert volume & frequency
+- How many incidents in the last 30 days? Last 7 days?
+- What is the firing cadence — multiple times per day? Daily? Sporadic?
+- Are incidents clustered in time (bursts) or spread evenly?
+
+### 2b. Anomaly patterns
+- Which segments (field values) are firing most? Are they the same segments repeatedly?
+- Are anomalies consistently marginal (just above threshold) or severe?
+- Are any anomalies from sparse/bursty event types that naturally spike?
+- Are anomalies caused by known operational events (deployments, batch jobs, bulk user actions)?
+- For validation monitors: how many invalid rows per incident? Is the count stable or growing?
+- For table monitors: which (table, metric) pairs are firing most? Are they the same repeatedly?
+
+### 2c. Current configuration
+Extract the current configuration. The specific fields to look for are documented in the per-type
+reference loaded in Phase 1.5. At minimum, extract:
+- Monitor type and what it measures
+- Schedule interval
+- Audiences / notification channels
+- Whether the monitor uses ML thresholds or explicit thresholds
+
+### 2d. Troubleshooting analysis (if available)
+Look at any troubleshooting TL;DRs in the report. Note:
+- Are most anomalies assessed as "likely normal data variation"?
+- Are there recurring root causes?
+- Is there a blind spot (e.g., no upstream metadata)?
+
+---
+
+## Phase 3: Generate Recommendations
+
+Based on the analysis, produce a prioritized list of recommendations. For each recommendation:
+- State the **problem** it solves
+- Give the **specific config change** (use exact field names from the MC config schema)
+- Explain the **trade-off** (what signal might be lost)
+
+### General recommendations (all monitor types)
+
+#### Sensitivity tuning (ML thresholds only)
+This applies to any monitor that uses ML thresholds — both metric monitors and custom SQL monitors.
+Skip this section for validation monitors (they don't use ML thresholds), for table monitors
+(they have their own per-metric sensitivity — see the table monitor reference), and for monitors
+with explicit thresholds (for custom SQL monitors, see threshold adjustment in the per-type
+reference instead).
+
+- If anomalies are consistently marginal (observed value just barely above threshold) AND assessed
+  as normal variation → recommend lowering sensitivity one step:
+  - If current sensitivity is `HIGH` → recommend `"sensitivity": "medium"`
+  - If current sensitivity is `MEDIUM` or `AUTO` → recommend `"sensitivity": "low"`
+- If current sensitivity is already `LOW` and still noisy → note this isn't a sensitivity issue
+
+#### Schedule / interval
+- If the monitor fires multiple times per day but anomalies always resolve within hours → recommend
+  increasing schedule interval (e.g., from 720 min to 1440 min) to reduce duplicate alerts
+- If anomalies are caused by data arriving late → recommend increasing `collection_lag`
+
+#### Snooze / training period
+- If the monitor was recently created (<30 days) and is still learning patterns → recommend
+  waiting for the model to stabilize before tuning
+
+#### Audience / notification routing
+- If the monitor has no audiences configured and is generating noise → recommend adding audiences
+  only for high-severity anomalies, or removing notifications entirely for known-noisy monitors
+
+### Type-specific recommendations
+
+For type-specific recommendations (WHERE conditions, segment exclusion, aggregation changes,
+threshold adjustment, SQL modifications, alert condition modifications, per-table-metric
+sensitivity tuning), follow the guidance in the per-type reference loaded in Phase 1.5.
+
+---
+
+## Phase 4: Present the Report
+
+Output a structured analysis. **This is the primary output — include it in full.**
+
+```markdown
+## Monitor Tune Report: {monitor_uuid}
+
+**Monitor:** {display_name or mac_name}
+**Type:** {monitor type — metric, custom SQL, validation, or table}
+**Table:** {table}
+**What it monitors:** {metric and segments, SQL query summary, validation conditions, or table/metric coverage}
+**Current sensitivity:** {sensitivity or "AUTO (default)" or "N/A (explicit thresholds)"}
+**Schedule:** every {interval_minutes / 60}h
+
+### Alert Summary (last 30 days)
+- Total alerts: {count}
+- Firing frequency: {e.g., "~twice daily", "daily", "sporadic"}
+- Most noisy segments: {top 2-3 segment values by alert count, or N/A for custom SQL/validation}
+- Most noisy (table, metric) pairs: {for table monitors: top pairs by anomaly count}
+
+### Root Cause Pattern
+{1-3 sentence summary of what the alerts represent — operational events, bursty data, model
+miscalibration, genuine issues, etc.}
+
+### Recommendations
+
+#### 1. {Highest-impact change} [RECOMMENDED]
+**Problem:** ...
+**Change:**
+```yaml
+{specific config field}: {new value}
+```
+**Trade-off:** ...
+
+#### 2. {Second change} [OPTIONAL]
+...
+
+#### 3. {Third change} [OPTIONAL]
+...
+
+### What NOT to change
+{Any configurations that look correct and should be left alone — avoid over-tuning.}
+
+### If these changes are made
+{Predict the expected outcome: estimated alert reduction, what genuine anomalies would still fire.}
+```
+
+**Next step:** "Want me to apply any of these changes to the monitor config, or explore the alert
+history further?"
+
+---
+
+## Phase 5: Apply Changes (if user requests)
+
+To apply changes, follow the apply-changes instructions in the per-type reference loaded in
+Phase 1.5. Each reference specifies the correct tool and constraints for that monitor type.
+
+General rules for all types:
+1. **Always preview first** — show the user what will change before applying.
+2. **Get explicit confirmation** before applying any change.
+3. **Validate the preview YAML against the schema** — before presenting the preview YAML to the user, fetch the published MaC JSON Schema from `https://clidocs.getmontecarlo.com/mac/schema.json` (WebFetch) and check the preview YAML against it. If any field in the YAML does not appear in the schema for the given monitor type, flag it and correct it. Note: the schema validates field names, types, and enum values only — cross-field semantic constraints are enforced by the backend at apply time, not by the schema.
+4. **MaC-managed monitors** — if `get_monitors` returns a `mac_name` or the user mentions the monitor is managed via a MaC YAML file, note this before applying: changes made via the API will be overwritten the next time `montecarlo monitors apply` runs. Offer to hand off to `/manage-mac` (edit workflow) instead so the YAML file stays the source of truth.
+
+---
+
+## Guidelines
+
+- **Be specific.** Generic advice like "reduce sensitivity" is less useful than exact config changes.
+- **Prefer surgical changes.** A targeted WHERE condition beats a blunt sensitivity reduction.
+- **Preserve signal.** Always explain what genuine anomalies would still be caught after tuning.
+- **Cite evidence.** Reference specific incident dates, segment values, and counts from the report.
+- **Degrade gracefully.** If troubleshooting runs are missing, note the limited context and
+  reason from alert patterns alone.
+- **Add `$schema` when saving YAML to a file.** If the user asks to save the MaC YAML to a file, add `# yaml-language-server: $schema=https://clidocs.getmontecarlo.com/mac/schema.json` as the first line of that file.
+
+## 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.

package/bundled-skills/ui-a11y/SKILL.md

@@ -1,81 +1,89 @@
 ---
 name: ui-a11y
-description: "Audit a StyleSeed-based component or page for WCAG 2.2 AA issues and apply practical accessibility fixes where the code makes them safe."
-category: design
-risk: safe
-source: community
+description: Audit a component or page for accessibility issues and fix them
+risk: unknown
+source: https://github.com/bitjaru/styleseed/tree/main/engine/.claude/skills/ss-a11y
 source_repo: bitjaru/styleseed
 source_type: community
-date_added: "2026-04-08"
-author: bitjaru
-tags: [ui, accessibility, wcag, audit, styleseed]
-tools: [claude, cursor, codex, gemini]
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/bitjaru/styleseed/blob/main/LICENSE
 ---
 
-# UI Accessibility Audit
-
-## Overview
-
-Part of [StyleSeed](https://github.com/bitjaru/styleseed), this skill audits components and pages for accessibility issues with an emphasis on the Toss seed's mobile UI patterns. It combines WCAG 2.2 AA checks with practical code fixes for touch targets, focus states, contrast, labels, and reduced motion.
-
+# Accessibility Audit
 ## When to Use
-- Use when reviewing a page or component for accessibility regressions
-- Use when a StyleSeed UI looks polished but has uncertain keyboard or contrast behavior
-- Use when adding new interactive controls to a mobile-first screen
-- Use when you want a prioritized list of issues and fixable items
-
-## Audit Areas
-
-### Perceivable
-
-- text contrast
-- non-text contrast for controls and graphics
-- alt text for images
-- labels for meaningful icons
-- no information conveyed by color alone
-
-### Operable
-
-- touch targets at least 44x44px
-- keyboard reachability for all interactive controls
-- logical tab order
-- visible focus indicators
-- reduced-motion support for nonessential animation
 
-### Understandable
-
-- visible labels or `aria-label` on inputs
-- error text associated with the correct field
-- clear wording for errors and validation
-- document language set appropriately
-
-### Robust
-
-- semantic HTML where possible
-- correct use of ARIA when semantics alone are insufficient
-- no faux buttons or links without the right roles and behavior
+Use this skill when you need audit a component or page for accessibility issues and fix them.
+
+
+## When NOT to use
+
+- For general design system compliance review → use `/ss-review`
+- For Nielsen UX heuristics → use `/ss-audit`
+- For non-StyleSeed code (no `data-slot`, no semantic tokens) — assumes StyleSeed conventions
+- For runtime testing — this is a static code audit, not a screen-reader simulation
+
+Target: **$ARGUMENTS**
+
+## Audit Criteria
+
+### WCAG 2.2 AA Compliance
+
+#### 1. Perceivable
+- **Color contrast**: Text must meet 4.5:1 (normal) or 3:1 (large/bold text)
+  - Check `text-muted-foreground` (#717182) on `bg-background` (#FFFFFF) = 4.6:1 (passes)
+  - Check `text-brand` on white (verify contrast with your skin's brand color)
+  - Flag any custom colors that don't meet ratio
+- **Non-text contrast**: UI controls/graphics must meet 3:1
+- **Text alternatives**: All `<img>` need `alt`, icons need `aria-label` when meaningful
+- **Color independence**: Don't convey info by color alone (add icons/text)
+
+#### 2. Operable
+- **Touch targets**: Minimum 44x44px (`min-h-11 min-w-11`)
+  - Common violation: `h-9` (36px) buttons — should be `h-11`
+  - Icon buttons need explicit size: `w-11 h-11`
+- **Keyboard navigation**: All interactive elements must be keyboard-accessible
+  - Tab order should be logical
+  - `focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2`
+- **Motion**: Animations must respect `prefers-reduced-motion`
+  ```css
+  @media (prefers-reduced-motion: reduce) {
+    *, *::before, *::after {
+      animation-duration: 0.01ms !important;
+      transition-duration: 0.01ms !important;
+    }
+  }
+  ```
+
+#### 3. Understandable
+- **Labels**: Form inputs must have visible labels or `aria-label`
+- **Error messages**: Form errors must be programmatically associated (`aria-describedby`)
+- **Language**: `<html lang="en">` (or appropriate language code for your project)
+
+#### 4. Robust
+- **Semantic HTML**: Use appropriate elements (`<button>`, `<nav>`, `<main>`, `<header>`)
+- **ARIA**: Use Radix UI components (they handle ARIA automatically)
+- **Roles**: Custom interactive elements need proper `role` attributes
+
+## Design System Token Reference
+
+| Token | Minimum Contrast | Note |
+|-------|-----------------|------|
+| `--foreground` | 7:1+ | Body text — verify with your skin |
+| `--muted-foreground` | 4.5:1+ | Secondary text — verify with your skin |
+| `--brand` | 4.5:1+ | Accent — verify with your skin's brand color |
+| `--destructive` | 4.5:1+ | Error — verify with your skin |
+| `--success` | 3:1+ | Large text/icons only — verify with your skin |
+| `--warning` | 4.5:1+ | Warning text — some skins need a darker variant |
 
 ## Output
 
-Return:
-1. Issues found, grouped by severity
-2. Safe autofixes that can be applied directly
-3. Items that need manual review or product judgment
-4. A short summary of the accessibility risk level
-
-## Best Practices
-
-- Fix semantics before layering on ARIA
-- Use the design system tokens only if they still meet contrast requirements
-- Treat touch target failures as real usability defects, not polish issues
-- Prefer partial, verified fixes over speculative accessibility changes
-
-## Additional Resources
-
-- [StyleSeed repository](https://github.com/bitjaru/styleseed)
-- [Source skill](https://github.com/bitjaru/styleseed/blob/main/seeds/toss/.claude/skills/ui-a11y/SKILL.md)
+1. **Issues found**: List with severity (Critical/Major/Minor)
+2. **Auto-fixes**: Apply fixes directly where possible
+3. **Manual review needed**: Flag items that need human judgment
 
 ## 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/ui-component/SKILL.md

@@ -1,104 +1,76 @@
 ---
 name: ui-component
-description: "Generate a new UI component that follows StyleSeed Toss conventions for structure, tokens, accessibility, and component ergonomics."
-category: design
-risk: safe
-source: community
+description: Generate a new UI component following the StyleSeed design conventions
+risk: unknown
+source: https://github.com/bitjaru/styleseed/tree/main/engine/.claude/skills/ss-component
 source_repo: bitjaru/styleseed
 source_type: community
-date_added: "2026-04-08"
-author: bitjaru
-tags: [ui, components, design-system, frontend, styleseed]
-tools: [claude, cursor, codex, gemini]
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/bitjaru/styleseed/blob/main/LICENSE
 ---
 
-# UI Component
-
-## Overview
-
-Part of [StyleSeed](https://github.com/bitjaru/styleseed), this skill generates components that respect the Toss seed's design language instead of improvising ad hoc markup and styling. It emphasizes semantic tokens, predictable typing, reusable variants, and mobile-friendly accessibility defaults.
-
+# UI Component Generator
 ## When to Use
-- Use when you need a new UI primitive or composed component inside a StyleSeed-based project
-- Use when you want a component to match the existing Toss seed conventions
-- Use when a component should be reusable, typed, and design-token driven
-- Use when the AI might otherwise invent spacing, colors, or interaction patterns
-
-## How It Works
-
-### Step 1: Read the Local Design Context
-
-Before generating code, inspect the seed's source of truth:
-- `CLAUDE.md` for conventions
-- `css/theme.css` for semantic tokens
-- at least one representative component from `components/ui/`
-
-If the user already has a better local example, follow the local codebase over a generic template.
 
-### Step 2: Choose the Correct Home
+Use this skill when you need generate a new UI component following the StyleSeed design conventions.
 
-Place the output where it belongs:
-- `src/components/ui/` for primitives and low-level building blocks
-- `src/components/patterns/` for composed sections or multi-part patterns
 
-Do not create a new primitive if an existing one can be extended safely.
+## When NOT to use
 
-### Step 3: Follow the Structural Rules
+- For full-page scaffolding → use `/ss-page`
+- For composed multi-component patterns → use `/ss-pattern`
+- For tweaking an existing component — just edit the file directly
+- For non-StyleSeed projects (no `components/ui/` directory or no Tailwind v4)
 
-Use these defaults unless the host project strongly disagrees:
-- function declaration instead of a `const` component
-- `React.ComponentProps<>` or equivalent native prop typing
-- `className` passthrough support
-- `cn()` or the project's standard class merger
-- `data-slot` for component identification
-- CVA or equivalent only when variants are genuinely needed
+Generate a new component: **$0**
+Description: $ARGUMENTS
 
-### Step 4: Use Semantic Tokens Only
+## Instructions
 
-Do not hardcode visual values if the design system has a token for them.
+1. First, read the design system seed for context:
+   - Read `CLAUDE.md` for component conventions
+   - Read `css/theme.css` for available design tokens
+   - Read `components/ui/button.tsx` as a reference pattern
 
-Preferred examples:
-- `bg-card`
-- `text-foreground`
-- `text-muted-foreground`
-- `border-border`
-- `shadow-[var(--shadow-card)]`
+2. Follow these conventions strictly:
+   - Use `function` declaration (not `const`)
+   - Add `data-slot="component-name"` attribute
+   - Use `cn()` from `@/components/ui/utils` for all className merging
+   - Use `React.ComponentProps<>` for prop typing
+   - Always support `className` prop for overrides
+   - Use CVA (`class-variance-authority`) if the component has variants
+   - Use semantic color tokens (`bg-card`, `text-foreground`) — never inline hex
 
-### Step 5: Preserve StyleSeed Typography and Spacing
+3. Design token usage:
+   - Colors: `text-foreground`, `bg-card`, `text-brand`, `text-muted-foreground`, `border-border`
+   - Shadows: `shadow-[var(--shadow-card)]`, `shadow-[var(--shadow-elevated)]`
+   - Radius: `rounded-md`, `rounded-lg`, `rounded-2xl`
+   - Spacing: multiples of 6px (`p-1.5`, `p-3`, `p-6`)
+   - Motion: `duration-[var(--duration-fast)]`, `ease-[var(--ease-default)]`
 
-- Use the scale already defined by the seed
-- Prefer multiples of 6px
-- Use logical spacing utilities where supported
-- Keep display and heading text tight, body text readable, captions restrained
+4. Typography rules:
+   - Display (36-48px): `leading-none tracking-[-0.02em]`
+   - Heading (18-24px): `leading-snug tracking-[-0.01em]`
+   - Body (14-17px): `leading-normal` (default tracking)
+   - Caption uppercase (10-13px): `tracking-[0.05em]`
+   - Use `size-*` shorthand instead of `w-* h-*`
+   - Use `ms-*/me-*` instead of `ml-*/mr-*` (logical properties)
 
-### Step 6: Bake in Accessibility
+5. Accessibility requirements:
+   - Minimum touch target: 44x44px (`min-h-11 min-w-11`)
+   - Support `aria-*` attributes passthrough
+   - Use `focus-visible:ring-2 focus-visible:ring-ring` for keyboard focus
+   - Respect `prefers-reduced-motion` for animations
 
-- Touch targets should be at least 44x44px for interactive elements
-- Keyboard focus must be visible
-- Pass through `aria-*` attributes where appropriate
-- Respect reduced-motion preferences for nonessential motion
+6. Export the component as a named export (not default)
 
-## Output
-
-Provide:
-1. The generated component
-2. The target path
-3. Any required imports or dependencies
-4. Notes on variants, tokens, or follow-up integration work
-
-## Best Practices
-
-- Compose from existing primitives before inventing new ones
-- Keep the component API small and predictable
-- Prefer semantic layout classes over arbitrary values
-- Export named components unless the host project uses another standard consistently
-
-## Additional Resources
-
-- [StyleSeed repository](https://github.com/bitjaru/styleseed)
-- [Source skill](https://github.com/bitjaru/styleseed/blob/main/seeds/toss/.claude/skills/ui-component/SKILL.md)
+7. Place the file in the appropriate directory:
+   - Primitive/reusable → `src/components/ui/`
+   - Composed pattern → `src/components/patterns/`
 
 ## 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.