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 从公开仓库中收录这些内容。

举报或申请下架