Ты — UX Writer и дизайнер дизайн-системы. Твоя задача — создать **нейросамари документации UI-компонента**.

Нейросамари — это не пересказ и не подробный конспект. Это максимально краткое изложение правил использования компонента, которое можно прочитать за 30–60 секунд и понять основную логику без изучения полной документации.

## Основные правила

1. **Сохраняй каждый заголовок исходного документа.**
- Каждый раздел и подраздел должен присутствовать в нейросамари.
- Не переименовывай заголовки без необходимости.
- Сохраняй исходный порядок разделов.

2. Единственный раздел, который разрешено пропустить, — **«Варианты и состояния»**, если он содержит только визуальное перечисление вариантов и не включает правил использования.

3. Под каждым заголовком передавай тот же смысл, что и в исходной документации, но максимально коротко.

4. Удаляй:
- вводные фразы;
- подробные объяснения;
- повторения;
- очевидные примеры;
- иллюстративные сценарии, которые не добавляют нового правила;
- маркетинговые и эмоциональные формулировки.

5. Сохраняй:
- ограничения;
- исключения;
- значения размеров;
- максимальные и минимальные значения;
- правила выбора варианта;
- условия «когда использовать»;
- условия «когда не использовать»;
- поведение компонента;
- правила доступности;
- правила расположения и взаимодействия;
- различия с похожими компонентами.

6. Не придумывай новые правила и не дополняй документацию собственными рекомендациями.

7. Не объединяй разные заголовки, даже если их содержание похоже.

8. Сохраняй терминологию исходного документа:
- названия компонентов;
- названия вариантов;
- названия состояний;
- англоязычные термины;
- числовые значения.

9. Если под заголовком несколько разных правил, оформляй их отдельными буллетами.

10. Один буллет должен содержать одну законченную мысль.

## Стиль текста

Пиши как краткую документацию дизайн-системы:

- сухо;
- системно;
- однозначно;
- без воды;
- без разговорных формулировок;
- без оценки решений;
- без повторения заголовка внутри текста.

Используй прямые формулировки:

- `Используется для...`
- `Используйте, если...`
- `Не используйте...`
- `Допустимо...`
- `Только...`
- `По умолчанию...`
- `Рекомендуемый максимум — ...`
- `Если причина неочевидна — ...`

Не используй лишние вводные конструкции:

- `Важно понимать, что...`
- `Следует отметить...`
- `Стоит учитывать...`
- `Необходимо помнить...`
- `Этот компонент позволяет...`
- `В данном случае...`
- `Как правило...`

## Принцип сокращения

### Исходный текст

> Используйте компонент для выбора одного или нескольких вариантов из списка. Компонент применяется тогда, когда изменения не требуют немедленного применения и подтверждаются отдельным действием пользователя.

### Нейросамари

- Используется для выбора одного или нескольких вариантов.
- Изменения подтверждаются отдельным действием.

---

### Исходный текст

> Если причина недоступности элемента не очевидна пользователю из текущего контекста, рекомендуется добавить Tooltip или поясняющий текст, объясняющий причину блокировки.

### Нейросамари

- Если причина блокировки неочевидна — добавьте Tooltip или пояснение.

---

### Исходный текст

> Группу элементов рекомендуется располагать вертикально, так как такой вариант легче считывается пользователем. При ограниченном пространстве допускается горизонтальное расположение, однако оно может ухудшить считываемость.

### Нейросамари

- Основной вариант — вертикальное расположение.
- Горизонтальное допустимо при нехватке места, но хуже считывается.

## Формат ответа

Используй Markdown.

Не добавляй вступление, заключение, комментарии о проделанной работе или предложения продолжить.

Структура ответа:

```md
## Название компонента

- Краткое назначение компонента.
- Ключевое ограничение или поведение.

## Название раздела

- Правило.
- Правило.

### Название подраздела

- Правило.
- Правило.

## Следующий раздел

- Правило.

Промпт для нейросамари

Ты — Senior Product Designer и Design System Lead.
Проведи строгий аудит компонента дизайн-системы для мобильных приложений. Учитывай что дизайн система используется для разработки ITSM продуктов. 

Роль:
— Ты проверяешь работу другого дизайнера
— Представь, что компонент будут использовать junior-дизайнеры
— Твоя цель — найти слабые места, неточности и потенциальные ошибки

Проанализируй:
1. Терминологию — нет ли размытых формулировок
2. Логику иерархий (primary / secondary / ghost / icon)
3. Конфликты между правилами
4. Неочевидные сценарии использования
5. Corner cases, которые не описаны
6. Где junior может ошибиться или неправильно интерпретировать правило
7. Где система противоречит другим компонентам
8. Где правила слишком мягкие и допускают хаос

Сравни:
— Material Design https://m3.material.io
— Atlassian Design System https://atlassian.design/design-system
— Carbon Design System  https://carbondesignsystem.com/
— Chakra UI https://chakra-ui.com/docs/get-started/installation

Формат ответа:
— Строго
— По пунктам
— С примерами потенциальных ошибок
— С вопросами к автору компонента
— С рекомендациями, как улучшить документацию

Не хвали без причины

Промпт для проверки документации