mcpField
U
ux-copy

ux-copy

github.com/n1arko设计与 UI18745 次安装11 周前更新
代码仓库

关于 ux-copy

ux-copy 是用于编写和审查界面微文案的 Skill,围绕用户场景、当前状态和后续操作组织文本,并提供多方案、改写与审查流程。

主要功能

  1. 01以用户场景为先编写界面文案
  2. 02提供多方案、改写和审查模式
  3. 03检查错误提示与界面状态
  4. 04审视通知必要性和文本语气

适用场景

  1. 01撰写按钮文案和界面文本
  2. 02修改现有界面文案
  3. 03检查错误提示和空状态

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/n1arko/redaktura-skills --skill ux-copy

安装后在 Claude Code 中输入/ux-copy确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
openai.yaml
references/
elementy.md
oshibki-i-sostoyaniya.md
printsipy.md
uvedomleniya.md

README 原文English

来自项目 README

README 暂无中文译文,以下为英文原文;中文介绍见上方。

UX-copy

Задача скилла — тексты интерфейса. Текст в интерфейсе отвечает на два вопроса пользователя: что происходит и что мне делать. Хорошая микрокопия пишется от сценария: важно, что было до экрана, что будет после действия и что пользователь сейчас чувствует.

Метод основан на практиках Людмилы Сарычевой (gladlax.ru) и собран совместно с Никитой Архиповым (niar42.com).

Шаг 0. Контекст

Если в проекте есть файл .agents/redpolitika.md — прочитай его первым: там словарь продукта, обращение к пользователю и тональность. Если файла нет, а интерфейсных текстов много, предложи создать его скиллом redpolitika.

Перед текстом выясни:

  1. Что за экран или сообщение.
  2. Что пользователь сделал до этого.
  3. Что должно произойти после.
  4. Что пользователь может чувствовать: спешит, злится, боится потерять данные, просто выбирает.
  5. Какие ограничения есть: длина, платформа, кнопки, юридический текст.

Режимы

  • Варианты (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 — статьи, посты и длинные объясняющие материалы

评论

支持 Markdown