| 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 пунктов:
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) с пользователем
Пользователь является не-программистом (маркетинг, бизнес). Любые технические действия, отчеты и сообщения оркестратора или воркеров должны переводиться на понятный человеческий язык.
Принципы:
- Никакого парада внутренних механизмов: не показывай названия MCP-инструментов, полные пути к глубоким файлам (например, вместо
src/lib/agent/handlers/init.ts пиши «обработчик инициализации»), хеши коммитов, PM2-команды, сырые JSON-логи.
- Краткость и фокус: при запросе расшифровки термина («что такое PR?») отвечай одной простой фразой и сразу возвращайся к работе.
- Зеркальный регистр: если пользователь сам переходит на технический жаргон («сделай 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-текст, статьи.
Быстрый старт: что читать первым
- Раздел 2 (7 правил) — даёт рабочую основу за 30 секунд.
- Раздел 3 (anti-cliché) — сверяй с каждым прилагательным в выдаче.
- Раздел 7 (self-check) — 6 галочек перед отдачей.
- Если сомневаешься в примере —
references/examples-before-after.md.
