iiuniversitet.ruЦентр обучения нейросетямОткрыть каталог

Аудит и документация дизайн-системы

Проверяет дизайн-систему на несогласованность, описывает компоненты и помогает спроектировать новый элемент в её стиле.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется
Скачать на русскомОригинал на английском (архив)Источник ↗
Что делает
Проверяет дизайн-систему на несогласованность, описывает компоненты и помогает спроектировать новый элемент в её стиле.
Когда брать
Когда нужно найти разнобой в названиях и «зашитых» значениях, написать документацию к компоненту или добавить новый паттерн.
Пример запроса
Проведи аудит нашей дизайн-системы в Figma и скажи, где названия и цвета не совпадают.
Нужно подключить
Figma, база знаний

Входит в плагин design. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

  1. Нажмите «Скачать на русском» и сохраните архив.
  2. В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
  3. Включите скилл переключателем.
Для терминала

Распакуйте архив и положите папку design-system в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: design-system
description: Проверь, задокументируй или расширь свою дизайн-систему. Используй, когда нужно найти несогласованность названий или жёстко прописанные значения в компонентах, написать документацию по вариантам, состояниям и доступности компонента или спроектировать новый паттерн, который впишется в существующую систему.
argument-hint: "[audit | document | extend] <component or system>"
---

/design-system

Если встретишь незнакомые подстановки или нужно проверить, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Управляй дизайн-системой: проверяй согласованность, документируй компоненты или проектируй новые паттерны.

Использование

/design-system audit                    # Full system audit
/design-system document [component]     # Document a component
/design-system extend [pattern]         # Design a new component or pattern

Из чего состоит дизайн-система

Дизайн-токены

Атомарные значения, определяющие визуальный язык:

  • Цвета (фирменные, смысловые, нейтральные)
  • Типографика (шкала, начертания, межстрочные интервалы)
  • Отступы (шкала, внутренние отступы компонентов)
  • Границы (скругление, толщина)
  • Тени (уровни возвышения)
  • Движение (длительности, функции сглаживания)

Компоненты

Повторно используемые элементы интерфейса с определёнными:

  • Вариантами (основной, вторичный, прозрачный)
  • Состояниями (по умолчанию, при наведении, нажатое, отключённое, загрузка, ошибка)
  • Размерами (sm, md, lg)
  • Поведением (взаимодействия, анимации)
  • Доступностью (ARIA, клавиатура)

Паттерны

Типовые решения интерфейса из сочетания компонентов:

  • Формы (группы полей ввода, проверка, отправка)
  • Навигация (боковая панель, вкладки, хлебные крошки)
  • Отображение данных (таблицы, карточки, списки)
  • Обратная связь (всплывающие уведомления, модальные окна, встроенные сообщения)

Принципы

  1. Согласованность важнее творчества — система существует для того, чтобы команды не изобретали велосипед
  2. Гибкость в рамках ограничений — компоненты должны сочетаться между собой, а не быть жёсткими
  3. Документируй всё — что не задокументировано, того не существует
  4. Версионируй и описывай миграцию — для изменений, ломающих совместимость, нужны пути миграции

Результат — аудит

## Аудит дизайн-системы

### Сводка
**Проверено компонентов:** [X] | **Найдено проблем:** [X] | **Оценка:** [X/100]

### Согласованность названий
| Проблема | Компоненты | Рекомендация |
|-------|------------|----------------|
| [Непоследовательное именование] | [Список] | [Стандарт, который стоит принять] |

### Покрытие токенами
| Категория | Определено | Найдено жёстко прописанных значений |
|----------|---------|----------------------|
| Цвета | [X] | [X] случаев жёстко прописанного hex |
| Отступы | [X] | [X] случаев произвольных значений |
| Типографика | [X] | [X] случаев своих шрифтов/размеров |

### Полнота компонентов
| Компонент | Состояния | Варианты | Документация | Оценка |
|-----------|--------|----------|------|-------|
| Кнопка | ✅ | ✅ | ⚠️ | 8/10 |
| Поле ввода | ✅ | ⚠️ | ❌ | 5/10 |

### Приоритетные действия
1. [Самое значимое улучшение]
2. [Второй приоритет]
3. [Третий приоритет]

Результат — документирование

## Компонент: [Название]

### Описание
[Что это за компонент и когда его использовать]

### Варианты
| Вариант | Когда использовать |
|---------|----------|
| [Основной] | [Главные действия] |
| [Вторичный] | [Вспомогательные действия] |

### Свойства
| Свойство | Тип | По умолчанию | Описание |
|----------|------|---------|-------------|
| [свойство] | [тип] | [значение по умолчанию] | [описание] |

### Состояния
| Состояние | Внешний вид | Поведение |
|-------|--------|----------|
| По умолчанию | [описание] | — |
| Наведение | [описание] | [взаимодействие] |
| Нажатое | [описание] | [взаимодействие] |
| Отключённое | [описание] | Не реагирует на действия |
| Загрузка | [описание] | [анимация] |

### Доступность
- **Роль**: [роль ARIA]
- **Клавиатура**: [Поведение Tab, Enter, Escape]
- **Программа экранного чтения**: [Озвучивается как...]

### Как правильно и как нет
| ✅ Делай так | ❌ Так не делай |
|------|---------|
| [Лучшая практика] | [Антипаттерн] |

### Пример кода
[Фрагмент кода, подходящий для фреймворка]

Результат — расширение

## Новый компонент: [Название]

### Проблема
[Какую потребность пользователя или пробел закрывает этот компонент]

### Существующие паттерны
| Связанный компонент | Сходство | Почему этого недостаточно |
|-------------------|-----------|---------------------|
| [Компонент] | [Что общего] | [Чего не хватает] |

### Предлагаемый дизайн

#### API / свойства
| Свойство | Тип | По умолчанию | Описание |
|----------|------|---------|-------------|
| [свойство] | [тип] | [значение по умолчанию] | [описание] |

#### Варианты
| Вариант | Когда использовать | Внешний вид |
|---------|----------|--------|
| [Вариант] | [Сценарий] | [Описание] |

#### Состояния
| Состояние | Поведение | Примечания |
|-------|----------|-------|
| По умолчанию | [Описание] | — |
| Наведение | [Описание] | [Взаимодействие] |
| Отключённое | [Описание] | Не реагирует на действия |
| Загрузка | [Описание] | [Анимация] |

#### Используемые токены
- Цвета: [Какие токены]
- Отступы: [Какие токены]
- Типографика: [Какие токены]

### Доступность
- **Роль**: [роль ARIA]
- **Клавиатура**: [Ожидаемые взаимодействия]
- **Программа экранного чтения**: [Озвучивается как...]

### Открытые вопросы
- [Решение, которое нужно обсудить с дизайнерами]
- [Крайний случай, который нужно решить]

Если подключены коннекторы

Если подключён ~~design tool:

  • Проверяй компоненты прямо в Figma — названия, варианты и использование токенов
  • Бери свойства компонентов и структуру слоёв для документации

Если подключена ~~knowledge base:

  • Ищи существующую документацию по компонентам и рекомендации по использованию
  • Публикуй обновлённую документацию в своей вики

Советы

  1. Начни с аудита — узнай, где ты сейчас, прежде чем решать, куда идти.
  2. Документируй по ходу работы — проще описать компонент, пока его проектируешь.
  3. Охват важнее совершенства — 80% задокументированных компонентов лучше, чем 100% от 10 компонентов.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/design/skills/design-system, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском 
---
name: design-system
description: Audit, document, or extend your design system. Use when checking for naming inconsistencies or hardcoded values across components, writing documentation for a component's variants, states, and accessibility notes, or designing a new pattern that fits the existing system.
argument-hint: "[audit | document | extend] <component or system>"
---

# /design-system

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Manage your design system — audit for consistency, document components, or design new patterns.

## Usage

```
/design-system audit                    # Full system audit
/design-system document [component]     # Document a component
/design-system extend [pattern]         # Design a new component or pattern
```

## Components of a Design System

### Design Tokens
Atomic values that define the visual language:
- Colors (brand, semantic, neutral)
- Typography (scale, weights, line heights)
- Spacing (scale, component padding)
- Borders (radius, width)
- Shadows (elevation levels)
- Motion (durations, easings)

### Components
Reusable UI elements with defined:
- Variants (primary, secondary, ghost)
- States (default, hover, active, disabled, loading, error)
- Sizes (sm, md, lg)
- Behavior (interactions, animations)
- Accessibility (ARIA, keyboard)

### Patterns
Common UI solutions combining components:
- Forms (input groups, validation, submission)
- Navigation (sidebar, tabs, breadcrumbs)
- Data display (tables, cards, lists)
- Feedback (toasts, modals, inline messages)

## Principles

1. **Consistency over creativity** — The system exists so teams don't reinvent the wheel
2. **Flexibility within constraints** — Components should be composable, not rigid
3. **Document everything** — If it's not documented, it doesn't exist
4. **Version and migrate** — Breaking changes need migration paths

## Output — Audit

```markdown
## Design System Audit

### Summary
**Components reviewed:** [X] | **Issues found:** [X] | **Score:** [X/100]

### Naming Consistency
| Issue | Components | Recommendation |
|-------|------------|----------------|
| [Inconsistent naming] | [List] | [Standard to adopt] |

### Token Coverage
| Category | Defined | Hardcoded Values Found |
|----------|---------|----------------------|
| Colors | [X] | [X] instances of hardcoded hex |
| Spacing | [X] | [X] instances of arbitrary values |
| Typography | [X] | [X] instances of custom fonts/sizes |

### Component Completeness
| Component | States | Variants | Docs | Score |
|-----------|--------|----------|------|-------|
| Button | ✅ | ✅ | ⚠️ | 8/10 |
| Input | ✅ | ⚠️ | ❌ | 5/10 |

### Priority Actions
1. [Most impactful improvement]
2. [Second priority]
3. [Third priority]
```

## Output — Document

```markdown
## Component: [Name]

### Description
[What this component is and when to use it]

### Variants
| Variant | Use When |
|---------|----------|
| [Primary] | [Main actions] |
| [Secondary] | [Supporting actions] |

### Props / Properties
| Property | Type | Default | Description |
|----------|------|---------|-------------|
| [prop] | [type] | [default] | [description] |

### States
| State | Visual | Behavior |
|-------|--------|----------|
| Default | [description] | — |
| Hover | [description] | [interaction] |
| Active | [description] | [interaction] |
| Disabled | [description] | Non-interactive |
| Loading | [description] | [animation] |

### Accessibility
- **Role**: [ARIA role]
- **Keyboard**: [Tab, Enter, Escape behavior]
- **Screen reader**: [Announced as...]

### Do's and Don'ts
| ✅ Do | ❌ Don't |
|------|---------|
| [Best practice] | [Anti-pattern] |

### Code Example
[Framework-appropriate code snippet]
```

## Output — Extend

```markdown
## New Component: [Name]

### Problem
[What user need or gap this component addresses]

### Existing Patterns
| Related Component | Similarity | Why It's Not Enough |
|-------------------|-----------|---------------------|
| [Component] | [What's shared] | [What's missing] |

### Proposed Design

#### API / Props
| Property | Type | Default | Description |
|----------|------|---------|-------------|
| [prop] | [type] | [default] | [description] |

#### Variants
| Variant | Use When | Visual |
|---------|----------|--------|
| [Variant] | [Scenario] | [Description] |

#### States
| State | Behavior | Notes |
|-------|----------|-------|
| Default | [Description] | — |
| Hover | [Description] | [Interaction] |
| Disabled | [Description] | Non-interactive |
| Loading | [Description] | [Animation] |

#### Tokens Used
- Colors: [Which tokens]
- Spacing: [Which tokens]
- Typography: [Which tokens]

### Accessibility
- **Role**: [ARIA role]
- **Keyboard**: [Expected interactions]
- **Screen reader**: [Announced as...]

### Open Questions
- [Decision that needs design review]
- [Edge case to resolve]
```

## If Connectors Available

If **~~design tool** is connected:
- Audit components directly in Figma — check naming, variants, and token usage
- Pull component properties and layer structure for documentation

If **~~knowledge base** is connected:
- Search for existing component documentation and usage guidelines
- Publish updated documentation to your wiki

## Tips

1. **Start with an audit** — Know where you are before deciding where to go.
2. **Document as you build** — It's easier to document a component while designing it.
3. **Prioritize coverage over perfection** — 80% of components documented beats 100% of 10 components.

Источник: anthropics/knowledge-work-plugins / design / design-system ↗. Ссылка проверена 2026-10-10.

Похожие