UX-copy
SkillCommunicationUX copy in Russian: buttons, forms, errors, empty states, onboarding, confirmations, notifications, pushes, and microcopy. Use this skill whenever the user asks to write, rewrite, review, choose, or improve interface copy, product messages, UI strings, transactional emails, push notifications, t
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the UX-copy skill
What this skill tells your AI
The instructions your AI receives, as published by n1arko/redaktura-skills in ux-copy/SKILL.md and read by ahel’s review.
Задача скилла — тексты интерфейса. Текст в интерфейсе отвечает на два вопроса пользователя: что происходит и что мне делать. Хорошая микрокопия пишется от сценария: важно, что было до экрана, что будет после действия и что пользователь сейчас чувствует.
Метод основан на практиках Людмилы Сарычевой (gladlax.ru) и собран совместно с Никитой Архиповым (niar42.com).
Шаг 0. Контекст
Если в проекте есть файл .agents/redpolitika.md — прочитай его первым: там словарь продукта, обращение к пользователю и тональность. Если файла нет, а интерфейсных текстов много, предложи создать его скиллом redpolitika.
Перед текстом выясни:
- Что за экран или сообщение.
- Что пользователь сделал до этого.
- Что должно произойти после.
- Что пользователь может чувствовать: спешит, злится, боится потерять данные, просто выбирает.
- Какие ограничения есть: длина, платформа, кнопки, юридический текст.
Режимы
- Варианты (options) — дать 2–3 формулировки и объяснить разницу.
- Правка (rewrite) — было/стало/правило для существующих текстов.
- Аудит (audit) — найти проблемы сценария и текста без полной переписи.
Если режим не назван, дай варианты: для интерфейса полезно выбрать из нескольких точных решений.
Глубина разбора
Подстраивай ответ под собеседника. Редактору можно отвечать терминами метода. Если пользователь не из редакторского мира — объясняй по-простому: не «голословное утверждение», а «здесь написано "многие считают", но непонятно, кто и откуда это известно». Термины либо избегай, либо поясняй в скобках, разбор давай короче: три главные правки полезнее пятнадцати.
Процесс
1. Сценарий
Опиши сценарий словами пользователя: «я хочу…», «я сделал…», «я не понимаю…». Детали — в references/printsipy.md.
Правило сценарий впереди экрана: сначала путь пользователя, затем текст элемента.
2. Элемент
Определи тип элемента: кнопка, заголовок, поле, плейсхолдер, чекбокс, тултип. Детали — в references/elementy.md.
Правило каждый элемент делает свою работу: кнопка называет действие, заголовок объясняет состояние, текст рядом даёт детали.
3. Ошибки и состояния
Если это ошибка, пустое состояние, загрузка или опасное действие, проверь, что текст объясняет случившееся и следующий шаг. Детали — в references/oshibki-i-sostoyaniya.md.
Правило что случилось и что делать: пользователь должен понять ситуацию без внутреннего кода системы.
4. Уведомления
Для пушей, писем, тостов и снекбаров проверь, нужно ли вообще писать. Если сообщение не меняет действие пользователя, часто лучше молчать. Детали — в references/uvedomleniya.md.
Правило польза сообщения: уведомление вмешивается во внимание пользователя и должно окупать это вмешательство.
5. Тональность
Сверься с ../redaktura/references/tonalnost.md: без вины, давления, ложной срочности и «упс». Слова пользователя важнее слов системы.
Формат ответа
В колонках «Почему» и «Правило» называй правила метода по имени («событие и шаг», «действие на кнопке», «слова пользователя», «последствие видно») — так пользователь учится, а не просто получает строки.
Варианты
| Элемент | Вариант 1 | Вариант 2 | Почему |
|---|---|---|---|
Правка
| Было | Стало | Правило |
|---|---|---|
Аудит
## Диагноз
[2–4 предложения о сценарии и главной проблеме]
## Главные правки
| Элемент | Проблема | Как исправить |
|---|---|---|
## Что ещё нужно узнать
[сценарные дыры, ограничения, системные причины]
Чего не делать
- Не писать от экрана. Сначала сценарий, затем текст элемента.
- Не выдумывать системные факты. Сроки («несколько минут»), каналы ответа («напишем на почту») и поведение системы легко подставить по привычке — но если они не заданы пользователем, это выдумка. Пиши плейсхолдер «[срок: уточнить]» или задай вопрос.
- Не винить пользователя. Текст помогает выйти из ситуации и сохранить контроль.
- Не ставить «ОК» там, где есть действие. Кнопка должна говорить, что произойдёт.
- Не шуметь уведомлениями. Если пользователь не должен ничего делать, часто лучше молчать.
Связанные скиллы
- redaktura — финально проверить тональность, слова и ритм интерфейсных текстов
- redpolitika — словарь продукта и тональность
- statya — статьи, посты и длинные объясняющие материалы
Signals
- GitHub stars
- 138
- Forks
- 21
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
ux-copy-n1arko- Source
- github.com/n1arko/redaktura-skills