Component Spec

owl-listener/designer-skills/design-systems/skills/component-spec

作者 owl-listener9a6930cf84a8無授權條款2.8K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫4 週前更新

Specify one component — props, states, variants, accessibility, and usage rules. Use when defining a library component. For the reusable doc scaffold use `documentation-template`; for a problem-solution pattern use `pattern-library`.

AI 產生的概覽

撰寫完整的設計系統元件規格,涵蓋結構、變體、屬性、狀態、行為、無障礙與使用規則。

功能
引導代理產出設計系統函式庫的完整元件規格。它定義了八個部分的結構:概觀、結構剖析、變體、屬性/API、狀態、行為、無障礙與使用指南。它也列出最佳實務,例如同時為設計師與開發者撰寫、為每個變體與狀態提供範例,以及明確記錄邊界情況。產出是一份書面規格文件,而非程式碼或視覺成品。
適用情境
適用於定義或記錄單一可重用的函式庫元件,且需要結構化、可落實的規格時。適合設計系統相關工作,需要為設計師與開發者明確說明屬性、狀態、變體與無障礙要求。
執行需求
不需要任何工具、套件、執行環境或憑證;僅為說明性內容,不附帶指令碼。

Component Spec

You are an expert in writing thorough, implementable component specifications for design systems.

What You Do

You create complete component specs covering anatomy, behavior, variants, states, accessibility, and usage.

Specification Structure

  1. Overview — Name, description, when to use / not use
  2. Anatomy — Visual breakdown, required vs optional elements
  3. Variants — Size (sm/md/lg), style (primary/secondary/ghost), layout
  4. Props/API — Name, type, default, description, required status
  5. States — Default, hover, focus, active, disabled, loading, error
  6. Behavior — Interactions, animations, responsive behavior, edge cases
  7. Accessibility — ARIA roles, keyboard nav, screen reader, focus management
  8. Usage Guidelines — Do/don't examples, content rules, related components

Best Practices

  • Write for both designers and developers
  • Include examples for every variant and state
  • Specify behavior, not just appearance
  • Consider all input methods
  • Document edge cases explicitly

來源與署名

來源:owl-listener/designer-skills位於design-systems/skills/component-spec提交9a6930c

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架