mcpField
U
ux-copy

ux-copy

github.com/n1arkoデザイン・UI18745 回インストール11 週間前に更新
リポジトリ

ux-copy について

ux-copyは、インターフェースのマイクロコピーを作成・レビューするスキルです。ユーザーの状況や次の行動を基点に、複数案、書き換え、監査の手順を示します。

主な機能

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

コメント