ru-text-quick

name	ru-text-quick
description	Выжимка ru-text для коротких русских отчётов / findings / статусов / комментариев. Для агентов с малой русской выдачей (verifiers, reviewers, status-сообщения). НЕ для копирайтинга — там используй полный ru-text.

ru-text-quick — Дисциплина короткого русского текста

Дистилляция ~/.claude/skills/ru-text/ для агентов, чья выдача — отчёты, findings, статусы, комментарии. Не для статей, лендингов, маркетинга — там ru-text.

---

1. Когда применять / не применять

Применять:

• Verdict / Summary / Notes в verifier-отчёте
• Findings в code review
• Status-сообщения («Сделал X, осталось Y»)
• Любая prose-выдача в YAML-полях summary, notes, detail, fix_suggestion
• Однострочные комментарии к результатам проверок

НЕ применять:

• JSON / YAML / XML / код / логи — там свой синтаксис
• Английские токены внутри кода (переменные, функции, пути)
• Технические идентификаторы: user_id, TASKS_DB_URL, ErrorCode.AUTH_FAILED
• Цитаты из чужого кода или логов (воспроизводить дословно)

---

2. TL;DR — 7 правил

Правило 1: Глагол вместо отглагольного существительного Не «осуществление проверки», а «проверить» / «проверка прошла».

Правило 2: Конкретика вместо абстракции Не «ряд нарушений», а «3 нарушения». Не «значительное время», а «14 секунд».

Правило 3: Активный залог Не «тест был запущен», а «запустил тест». Не «ошибка была обнаружена», а «нашёл ошибку».

Правило 4: Числа вместо эпитетов Не «быстро», «долго», «много» — а 150 мс, 3 минуты, 47 файлов.

Правило 5: Без модальных смягчений Не «возможно, стоит рассмотреть», «вероятно, проблема в», «как бы» — пиши прямо.

Правило 6: Без извинений и самоуничижения Не «к сожалению, не удалось», «мне не хватает информации» — пиши что именно нужно.

Правило 7: Типографика обязательна Тире (—) не дефис (-), ёлочки («»), многоточие (…), неразрывный пробел перед единицами.

---

3. Anti-cliché — 22 запрета

Каждый запрет: что вычеркнуть или чем заменить.

Запрет	Замена
качественный	назвать конкретное свойство: «надёжный», «быстрый», «без ошибок»
эффективный	указать метрику: «сократил на 40%», «ускорил до 2 с»
комплексный	описать что включает: «охватывает X, Y и Z»
уникальный	описать конкретное отличие или вычеркнуть
индивидуальный подход	вычеркнуть полностью
оптимальный	назвать критерий: «минимальный по памяти», «наибыстрый из трёх»
надёжный	гарантийный срок, uptime, статистика сбоев
современный	год / версия / конкретная технология
инновационный	описать что именно нового
гибкий	описать что именно настраивается
профессиональный	вычеркнуть; если важно — конкретная квалификация
широкий спектр	перечислить что конкретно
успешно завершено	«завершено» — «успешно» лишнее
в кратчайшие сроки	назвать срок: «за 2 часа», «до пятницы»
является	тире или перестроить: «X — это Y»
осуществляет / производит	конкретный глагол: «делает», «запускает», «отправляет»
данный	«этот» или убрать, если и так понятно
в рамках	«в», «при», «во время» — или вычеркнуть
на сегодняшний день	«сейчас», «сегодня»
соответствующий	назвать что именно: «нужный», «правильный»
определённые трудности	назвать что именно: «три ошибки парсинга», «нехватка прав»
ряд причин	«три причины», перечислить

---

4. Пять признаков канцелярита

1. Отглагольное существительное вместо глагола ❌ «Осуществление мониторинга сервиса» ✅ «Мониторинг сервиса» / «Мониторю сервис»

2. Длинная цепочка родительных падежей ❌ «Результат проверки корректности валидации данных формы» ✅ «Валидация формы прошла — данные корректны»

3. Пассивный залог без актора ❌ «Тест был прогнан, ошибки были обнаружены» ✅ «Прогнал тест — нашёл 3 ошибки»

4. Безликие формулы вместо конкретики ❌ «В ходе проведённого анализа установлено наличие ряда проблем» ✅ «Анализ выявил 2 проблемы: X и Y»

5. Модальные смягчения ❌ «Возможно, имеет смысл рассмотреть вариант добавления» ✅ «Добавь X — это исправит Y»

---

5. Типографика (обязательно)

Элемент	Ошибка	Правильно
Длинное тире	Слово - слово	Слово — слово (U+2014, с пробелами)
Дефис в переносе строки	Москва-столица	остаётся - (составное слово)
Диапазон чисел	10-15 тестов	10–15 тестов (en dash, U+2013, без пробелов)
Кавычки основные	"текст"	«текст» (ёлочки)
Кавычки вложенные	«"вложенные"»	«„вложенные"» (лапки)
Многоточие	... (3 точки)	… (U+2026, один символ)
Неразрывный пробел	5 кг, 100 %	5 кг, 100 % (U+00A0 между числом и единицей)
Неразрывный пробел инициалы	А. С. Пушкин	А. С. Пушкин (nbsp между инициалами)
Неразрывный пробел перед тире	слово — слово	пробел перед — должен быть неразрывным
Числа от 10 000	1000000	1 000 000 (тонкий пробел U+202F)
Проценты	5 %	5% — без пробела (принятый технический стиль)
Порядковые числительные	1ый, 2ой	1-й, 2-й
Аббревиатуры	т.д.	т. д. (с пробелом и nbsp)

Правило для агентов: в plain-text / Markdown ставь реальные символы: — «» …. Не --, не "", не ....

---

6. Паттерны структуры

Verifier-отчёт

✅ Прошло: 47 / ❌ Провалилось: 3 / ⚠️ Предупреждений: 2

Провалилось:
- auth.ts:82 — отсутствует проверка подписи вебхука
- payments.ts:140 — сумма сравнивается как float, не в копейках
- webhook.ts:201 — дублирующийся вебхук не de-duplicated

Предупреждения:
- Нет rate limit на POST /webhook (не блокирует деплой)

Status-сообщение

Формула: Сделал X → проверил Y → осталось Z (или что нашёл).

Прогнал полный тест-сьют (187 тестов, 4 m 12 s).
Нашёл 3 падения — все в auth-модуле, связаны с новым middleware.
Остальное зелёное. Детали в findings ниже.

Bug finding

Что: двойное списание при повторном вебхуке
Где: src/payments/webhook.ts:201, функция handlePaymentConfirmed
Почему: отсутствует проверка уникальности transaction_id перед записью
Как чинить: добавить уникальный индекс на transaction_id и проверять перед вставкой

---

7. Self-check (5 секунд)

Перед отдачей любого русского текста — 6 пунктов:

• Нет запрещённых слов из anti-cliché (качественный, эффективный, комплексный…)
• Нет цепочек родительных падежей длиннее двух уровней
• Нет пассивного залога без явного актора
• Цифры вместо расплывчатых эпитетов (много/быстро/долго)
• Модальных смягчений нет («возможно», «как бы», «стоит рассмотреть»)
• Типографика: тире (—), кавычки («»), многоточие (…)

---

8. Навигация

Нужно	Файл
Быстрый чек-лист перед выдачей	references/checklist.md
20+ примеров bad→good	references/examples-before-after.md
Полный каталог стоп-слов (97 записей)	~/.claude/skills/ru-text/references/info-style.md
Все правила типографики	~/.claude/skills/ru-text/references/typography.md
Полный каталог анти-паттернов	~/.claude/skills/ru-text/references/anti-patterns.md

---

9. Правила общения оркестратора (dev-orchestrator) с пользователем

Пользователь является не-программистом (маркетинг, бизнес). Любые технические действия, отчеты и сообщения оркестратора или воркеров должны переводиться на понятный человеческий язык.

Принципы:

1. Никакого парада внутренних механизмов: не показывай названия MCP-инструментов, полные пути к глубоким файлам (например, вместо src/lib/agent/handlers/init.ts пиши «обработчик инициализации»), хеши коммитов, PM2-команды, сырые JSON-логи.
2. Краткость и фокус: при запросе расшифровки термина («что такое PR?») отвечай одной простой фразой и сразу возвращайся к работе.
3. Зеркальный регистр: если пользователь сам переходит на технический жаргон («сделай detect_changes», «чекни PR #35»), можно отвечать в его терминологии. В остальных случаях — строго plain language.

Таблица перевода терминов (используй готовые фразы):

Внутренний термин	Человеческий перевод
Score: 7 — full cycle	«Задача крупная — пройду полным циклом: план + проверки»
Score: 2 — direct path	«Это быстрая правка, сделаю напрямую без плана»
Score: 11+ — split	«Задача слишком большая, давай разобьём на 2-3 фичи»
Dispatching @feature-planner	«Сейчас составлю план: что делать и сколько примерно работы»
Dispatching @worker-test-verifier	«Прогоняю тесты, проверяю что ничего не сломалось»
Dispatching @worker-security-verifier	«Проверяю на дыры в безопасности»
Dispatching @worker-payments-verifier	«Перепроверяю всё про платежи — там нельзя ошибиться»
mcp__gitnexus__impact	«Смотрю, на что это повлияет в других местах»
mcp__gitnexus__detect_changes	«Проверяю что попадёт в этот коммит»
mcp__gitnexus__query	«Ищу в коде, где у нас X»
serena.find_referencing_symbols	«Ищу, где это используется»
Worktree created at <path>	«Сделал отдельную копию проекта в <path>, чтобы не мешать основной работе»
Blast radius: 12 callers	«Эта функция используется в 12 местах — все проверю»
Critical finding	«Важное замечание — надо исправить сейчас»
High finding	«Серьёзное замечание — исправлю до конца этой задачи»
Medium / Low finding	«Мелочь — записал в TODO»
gh pr create	«Создал запрос на слияние, ссылка: ...»
merge to main	«Залить в основную версию проекта» (требует подтверждения)
/codex:adversarial-review	«Второе мнение от другой модели»

Словарь: что разрешено как есть, а что требует перевода

Можно без перевода (технологии стека): PostgreSQL, Redis, BullMQ, Prisma, Pinia, PM2, Angie, nginx, systemd, Next.js, Vue, Nuxt, Astro, FastAPI, Hono, Claude Code, Anthropic SDK, Vitest, pytest, Playwright, Lighthouse, Perplexity, GitNexus, Serena, XMLStock.

Требует перевода (общие термины):

• рефакторинг -> переписать без изменения поведения
• middleware -> прослойка между запросом и обработчиком
• blast radius -> сколько мест поломается от правки
• serialize / десериализация -> упаковать данные в строку / распаковать
• IDOR -> возможность увидеть чужие данные, поменяв ID в ссылке
• monorepo -> несколько проектов в одной папке git
• worktree -> копия проекта на той же машине для работы в отдельной ветке
• migration -> изменение структуры базы данных
• webhook -> уведомление от внешнего сервиса нашему API
• JWT / refresh token -> временный билет для входа в систему
• PR / commit / branch -> запрос на слияние / сохраненные изменения / ветка

Шаблоны объявлений фаз (Phase announcements)

При переходе между фазами используй понятные шаблоны (с подстановкой деталей):

Фаза	Шаблон объявления
Phase 0	«Прежде всего оценю, насколько большая задача.»
Phase 1	«Уточню одну-две детали, чтобы не уйти не туда.»
Phase 2	«Соберу план: что делать, какие файлы тронем, примерный объём.»
Phase 3	«Покажу план — если ок, создам отдельную копию проекта и начну.»
Phase 4	«Делаю задачу N из M: <одно предложение человеческим языком о сути задачи>»
Phase 5	«Проверяю результат: тесты + безопасность/платежи если затронули»
Phase 6	«Нашёл замечание — чиню, проверяю ещё раз»
Phase 7	«Готово. Решим что с веткой: PR / влить / оставить / отменить?»

Шаблон итогового отчета (Plain-language summary template)

Используй этот шаблон для финального отчёта:

Готово.

Что сделали:
- <одна-две строки человеческим языком: что изменилось для пользователя>

Где увидеть:
- <URL продакшна или путь к экрану в UI>
- Изменения на проде с HH:MM <timezone>
- <N> тестов прошли, ничего не сломали

Если что не так — скажи, откачу.

Запрещенные термины в отчетах (требуют замены/перевода)

По умолчанию в отчетах не должны появляться слова: коммит, merge, push, PR, worktree, PM2, branch, rebase, force-push, deploy. Если пользователь сам использует их в текущей сессии — можно зеркалить их в ответах. В остальных случаях переводи их на русский человеческий язык.

Примеры отчетов по задачам (End-of-task reports)

• ❌ Неправильно (сырой технический лог):

  Score: 7 | Phase 4 task 3/8 complete | 12 callers via gitnexus_impact |
  worker-test-verifier 47/0 | worker-security-verifier 2 medium findings deferred
  

• ✅ Правильно (человеческое резюме):

  Сделал 3 из 8 задач. Все тесты проходят. Безопасность нашла 2 мелких
  замечания — добавил в TODO, не блокеры. Иду к задаче 4.
  

---

10. Sources

Выжимка из ~/.claude/skills/ru-text/ (Arseniy Kamyshev, talkstream/ru-text). Полный канон: ~/.claude/skills/ru-text/SKILL.md и references/. Применяй ru-text (полный) когда нужен copywriting, UX-текст, статьи.

---

Быстрый старт: что читать первым

1. Раздел 2 (7 правил) — даёт рабочую основу за 30 секунд.
2. Раздел 3 (anti-cliché) — сверяй с каждым прилагательным в выдаче.
3. Раздел 7 (self-check) — 6 галочек перед отдачей.
4. Если сомневаешься в примере — references/examples-before-after.md.