本文へ移動
cccskills
無料GitHub で公開

ui-pattern

Use when generating reusable UI patterns such as card sections, grids, lists, forms, and chart wrappers using StyleSeed Toss primitives.

インストール方法を見る

含まれるファイル(3)

  • SKILL.md4.3 KB
  • examples/data-list-pattern.tsx10.3 KB
  • examples/form-wizard-pattern.tsx18.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

UI Pattern

Overview

Part of StyleSeed, this skill builds reusable composed patterns from the seed's primitives. It is intended for sections like card lists, grids, form blocks, ranking lists, and chart wrappers that appear across multiple pages and need to look deliberate rather than ad hoc.

When to Use

  • Use when you need a reusable layout pattern rather than a one-off page section
  • Use when a page repeats the same arrangement of cards, rows, filters, or data blocks
  • Use when you want to build from existing StyleSeed primitives instead of copying markup
  • Use when you want a pattern component with props for dynamic content

How It Works

Step 1: Identify the Pattern Type

Common pattern families include:

  • card section
  • two-column grid
  • horizontal scroller
  • list section
  • form section
  • stat grid
  • data table
  • detail card
  • chart card
  • filter bar
  • action sheet

Step 2: Read the Available Building Blocks

Inspect both:

  • components/ui/ for primitives
  • components/patterns/ for neighboring patterns that can be extended

The goal is composition, not duplication.

Step 3: Apply StyleSeed Layout Rules

Keep the Toss seed defaults intact:

  • card surfaces on semantic tokens
  • rounded corners from the system scale
  • shadow tokens instead of improvised shadow values
  • consistent internal padding
  • section wrappers that align with the page margin system

Step 4: Make the Pattern Dynamic

Expose data through props instead of hardcoding content. If a pattern has multiple variants, keep the API explicit and small.

Step 5: Keep the Pattern Reusable Across Pages

Avoid page-specific assumptions unless the user explicitly wants a one-off section. If the markup only works on one route, it probably belongs in a page component, not a shared pattern.

Output

Provide:

  1. The generated pattern component
  2. The target location
  3. Expected props and usage example
  4. Notes on which existing primitives were reused

Best Practices

  • Start from the smallest existing building block that solves the problem
  • Keep container, section, and item responsibilities separate
  • Use tokens and spacing rules consistently
  • Prefer extending a pattern over adding a near-duplicate sibling

Additional Resources

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.

Core Process

  1. Identify the recurring UI challenge and select the appropriate StyleSeed primitives.
  2. Compose the primitives into a flexible pattern that accepts variable content.
  3. Implement standard error handling and edge cases (e.g., long text overflow).
  4. Document the pattern for reuse across the application.

Common Rationalizations

RationalizationReality
I'll build a custom grid for this specific layout.Fails to leverage existing StyleSeed grid primitives, reducing consistency.
This form doesn't need the standard validation pattern.Inconsistent validation patterns confuse users and reduce trust.
I'll hardcode the list spacing.Breaks the reusable pattern design, making it brittle to global spacing updates.

Red Flags

  • Reinventing standard patterns instead of composing them from primitives.
  • Hardcoded layouts that don't adapt to different content lengths.
  • Inconsistent error handling in form patterns.

Verification

  • Pattern correctly composes existing StyleSeed primitives.
  • Layout responds gracefully to varying content lengths.
  • Standard interactive patterns (e.g. form validation) are maintained.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Use when a hybrid memory system that provides persistent, searchable knowledge management for AI agents (Architecture, Patterns, Decisions).

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Reference for how BDB structures autonomous software engineering work — the seven-node dispatcher graph (Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, Shipping) that /startcycle-graph actually runs. Use when you need the high-level lifecycle framing without inventing your own process.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Tools are how AI agents interact with the world. A well-designed tool is the difference between an agent that works and one that hallucinates, fails silently, or costs 10x more tokens than necessary. This skill covers tool design from schema to error handling.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Harness patterns for coding agents — memory, permissions, context engineering, delegation, skills, hooks, bootstrap.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Live map of a multi-agent build in the browser: which plan component is being worked on, by which agent or harness, what is done and what is stuck. Use when a multi-agent pipeline starts (/startcycle, /startcycle-graph, /teamwork-preview) or after a plan-canvas approve, or when the user asks to see what the agents are doing.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

hybridlabor-api のスキルをすべて見る

このスキルの問題を報告する