Humanize Ai Text

---
name: humanize-ai-text
description: "Применять при переписывании текстов, сгенерированных LLM-агентами (отчеты, README, доки, письма, посты), в живой человеческий стиль. Триггеры - пользователь пишет 'убери AI-стиль', 'перепиши по-человечески', 'сделай естественно', 'убери воду', 'не как ChatGPT', 'убери LLM-штампы'; либо на входе текст с явными маркерами генерации: H2/H3 на каждый абзац, буллеты вместо прозы, штампы 'в современном мире', 'давайте погрузимся', избыток длинных тире, эмодзи-заголовки, обязательные 'надеюсь, это поможет!'. Сверх того ВСЕГДА проверяет технический регистр: в README, журнале изменений, документации и описаниях заменяет бытовую метафору на действие и предмет ('досыпает', 'кладет', 'копит', 'под капотом', 'из коробки', 'ядро библиотеки'); в письме, ответе и эссе эта проверка сама выключается по жанру, ключ отключения - --no-technical. Переписывание в живой стиль не применять к структурированным форматам, где списки и заголовки уместны по существу: API-документация, чек-листы, табличные данные, бенчмарки, юридические документы."
argument-hint: "[текст | путь к .md файлу] [--no-technical | --technical]"
allowed-tools:
  - Bash
  - Read
  - Write
  - Edit
---

# /humanize-ai-text - переписывание AI-текста в живой стиль

Превращает текст с маркерами LLM-генерации (ровный ритм, лестница H2/H3, буллеты вместо прозы, дежурные вступления и заключения) в текст с человеческой интонацией, не теряя смысл, числа и термины.

## Когда использовать

Триггерные фразы пользователя:
- "убери AI-стиль", "не как ChatGPT", "не как нейросеть"
- "перепиши по-человечески", "сделай естественно", "сделай живым"
- "убери воду", "убери штампы", "убери LLM-маркеры"
- "причеши текст", "оживи текст"

Автотриггер при анализе входного текста:
- Заголовки H2/H3 на каждый второй абзац в коротком документе.
- Буллеты с симметричной структурой и одинаковой длиной пунктов.
- Стоп-фразы из таблицы ниже ("в современном мире", "давайте погрузимся" и т.п.).
- Эмодзи-маркеры в начале пунктов (галочки, ракеты, стрелки).
- Дежурные "надеюсь, это поможет!" / "дайте знать, если есть вопросы!".
- Серия предложений одинаковой длины подряд (4+).

## Режимы работы

| Режим | Триггер | Что делает |
|-------|---------|------------|
| Inline | аргумент - произвольный текст | Переписанный текст выводится в чат |
| File | аргумент - путь к существующему .md файлу | Результат сохраняется рядом с суффиксом `-human.md` |
| Interactive | аргумент пустой | Спросить у пользователя текст или путь |
| Встроенный | скил вызван другим агентом как шаг задачи | Отдать ТОЛЬКО итоговый текст |

Встроенный режим - когда результат идет дальше в чужую работу: описание pull request, сообщение
коммита, кусок документации. Ни черновика, ни разбора, ни резюме правок: вызывающему нужен текст,
а не отчет о переписывании.

Алгоритм определения режима - как в `/prompt-enhancer`:
1. Пустой аргумент - Interactive.
2. Read удалось прочитать аргумент - File.
3. Read вернул "не найден" - Inline (аргумент целиком как текст).

## Технический регистр: включен по умолчанию

Сверх поиска признаков генерации скил проверяет ТЕХНИЧЕСКИЙ РЕГИСТР. Проверка включена всегда,
отключается ключом `--no-technical` либо словами пользователя "без проверки регистра".

**Что проверяется.** В техническом тексте бытовая метафора вместо действия и предмета - дефект.
Не "досыпает элементы", а "добавляет N элементов в конец коллекции". Не "копит ошибки", а
"накапливает список диагностик до вызова X". Не "схлопывая пробелы", а "заменяя последовательность
пробелов одним". Не "ядро библиотеки", а конкретный модуль. Не "подсистемы узнают друг о друге",
а "подсистема A вызывает экспортный метод подсистемы B". Так же исключаются "кладет", "забирает",
"внутренняя кухня", "под капотом", "на лету", "магия", "умеет", "дружит с", "из коробки",
"грабли", "ловушки", "костыль". В английском тексте - `under the hood`, `out of the box`,
`the heart of`, `knows how to`, `magic`, `seamless`.

**Проверочный вопрос к каждому глаголу и образу:** можно ли по этой фразе назвать метод, поле, код
ошибки, диапазон версий или измеренное число? Нельзя - фраза декоративная, заменить на фактическую.
Имя метода и измеренная величина всегда лучше пересказа своими словами.

**Где проверка НЕ применяется.** Текст произвольного жанра - письмо, ответ, сообщение, эссе,
поздравление - живет по своим правилам, и разговорный оборот там не дефект. Скрипт распознает такой
текст по приветствию в начале и подписи в конце и сам пропускает проверку, сообщая об этом. Если
жанр распознан неверно, проверка включается принудительно ключом `--technical`.

Приветствие засчитывается только целым словом и только в короткой строке, до 60 символов. Иначе
заголовок "Приветственный экран" выключал бы проверку для всей статьи, и молча.

Границу проводить по жанру, а не по теме: письмо про устройство обмена данными остается письмом.

**Список в скрипте узкий и точный.** Оценочные слова ("просто", "легко", "удобно", "мощный") в него
не входят: они слишком часто законны. По ним решение принимает модель проверочным вопросом выше.

## Базовый принцип

Хороший человеческий текст имеет ритм, неровность и точку зрения. AI-текст ровный, симметричный, гипер-структурированный, без личной интонации. Цель скила - вернуть тексту неровность, не теряя смысл.

## Жесткие правила

1. **Ничего не выдумывать.** В переписанном тексте не должно появиться ни одного факта, имени,
   числа, даты или цитаты, которых не было в исходнике. Заменить расплывчатое на конкретное можно,
   только если конкретика взята из источника или дана пользователем: "заметно ускорилось" станет
   "стало вдвое быстрее" лишь тогда, когда "вдвое" где-то сказано. Если фразе не хватает детали -
   спросить или написать без нее. Мнение и оценка фактами не считаются: там, где жанр допускает
   голос, отношение добавлять можно, новые утверждения о мире - нельзя.
2. **Списки только когда элементы реально параллельны и независимы.** Если соседние пункты связаны логикой ("сначала X, потому что Y, иначе Z") - это абзац, а не буллеты.
3. **Заголовки только при смене темы.** Не на каждые 2 абзаца. Документ из 400 слов с 6 H2 - это AI-текст, переписать в прозу с 1-2 разделами.
4. **Длина предложений варьируется.** Если идут 4 предложения по 15-20 слов подряд - ломать ритм. Короткое. Потом длинное, с придаточным. Потом среднее.
5. **Никаких буферных вступлений и заключений.** Не "В этой статье мы рассмотрим...", не "Подводя итог...". Сразу к делу, в конце - последняя содержательная мысль, без обертки.
6. **Никаких финальных "надеюсь, это поможет!", "дайте знать, если есть вопросы!".** Если уместен призыв к действию - он конкретный ("скажи, какой вариант - соберу пример"), а не дежурный.
7. **Bold для терминов при первом введении и для реальных акцентов**, не для каждой второй фразы. Если в абзаце 4+ выделения жирным - убрать половину.
8. **Длинные тире лучше заменить на обычный дефис, запятую или скобки.** Часто длинное тире - тоже маркер LLM-стиля. Если оставлять - то редко и осознанно, не подряд в каждом втором предложении.
9. **Буква Cyrillic Letter Yo (U+0451) - тоже маркер AI или официального документа.** Люди в неформальных текстах эту букву печатают редко: пишут "все", "еще", "вообще", "отчет", "нашел". Если в исходнике диакритическая "е" расставлена везде - заменить на обычную "е". Сохранять только в текстах, где это требование жанра (учебники, словари, имена собственные если автор настаивает на точном произношении).
10. **Текстовые стрелки `->`, `=>`, `→` - убрать.** Запись через стрелку - маркер технической AI-генерации, в живом тексте так не пишут. Заменять словом по смыслу ("становится", "переходит в", "дает", "ведет к") или переписывать фразой. "складская накладная -> расходный ордер" становится "из складской накладной собирается расходный ордер". Это касается всех стрелок: ASCII `->` и `=>`, юникод `→`.

## Голос: где он нужен, а где вредит

Безжизненный текст выдает машину не хуже, чем штампы. Ровные предложения, безупречная симметрия и
полное отсутствие отношения - тоже признак генерации. Живому тексту позволено иметь мнение,
сомнение, смешанные чувства, отступление в скобках и неровный ритм.

Но добавлять голос можно **не везде**. Он уместен в постах, эссе, письмах, разборах, README со
своей интонацией. В справочнике, спецификации, регламенте и юридическом документе нейтральный
ровный тон **и есть** правильный человеческий голос: первое лицо и оценки там неуместны, их
отсутствие не дефект. Прежде чем оживлять - определить жанр.

## Калибровка по образцу

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

1. Прочитать образец. Отметить длину предложений, лексику, чем начинаются абзацы, какая пунктуация
   в ходу, какие обороты повторяются, как делаются переходы.
2. Подстраиваться под эти привычки, а не просто вычищать маркеры. Не "улучшать" разговорные слова и
   не выравнивать намеренные странности - они и есть авторский почерк.
3. Образца нет - работать по умолчаниям этого скила.

**Образец главнее правил скила.** Если автор любит длинные тире и они есть в образце - оставить их с
его частотой, а не вычищать по общему правилу. Совпасть с автором важнее, чем убрать признак.

## Структурные антипаттерны

- **Триплеты-пулемет.** "Быстрый, надежный и масштабируемый". "Анализ, синтез и применение". Если в тексте 3+ триплета - сломать половину в пары или одиночные.
- **Симметричные буллеты одинаковой длины.** Признак шаблона. Либо переписать в прозу, либо сознательно сделать пункты разной длины и структуры.
- **Эмодзи-маркеры в списках и заголовках.** Удалить все, если только это не маркетинговый пост, где это сознательный выбор.
- **Параллельные подзаголовки в духе "Преимущества / Недостатки / Применение / Заключение".** Признак шаблона из тренировочных данных. Переписать структуру под конкретный материал.
- **Перевернутая пирамида с TL;DR + повторением + резюме.** Достаточно одного из трех.
- **Хеджирование на каждом шагу:** "может быть", "возможно", "в некоторых случаях", "как правило". Оставить только там, где есть реальная неопределенность.
- **Длинные тире через предложение.** Маркер ровного LLM-ритма. Заменять на запятые, скобки, точки или обычный дефис.

## Что сохранять буквально

- Технические термины - не упрощать ради "человечности".
- Числа, версии, имена файлов, флаги CLI, идентификаторы - без изменений.
- Цитаты, код, команды - не трогать.
- Если в исходнике есть обоснованная структура (нумерованные шаги установки, список зависимостей, таблица параметров API) - оставить.
- Имена людей, организаций, продуктов - точно как в оригинале.

## Справочники

Лежат рядом в `references/`, грузятся по требованию, а не каждый раз:

| Файл | Когда читать |
|---|---|
| `stop-phrases.md` | Скрипт нашел стоп-фразу и нужно решить, чем ее заменить |
| `language-antipatterns.md` | Идет переписывание: обход глагола "быть", синонимическая карусель, ложные диапазоны, формулы-афоризмы |
| `false-positives.md` | Перед правкой: что НЕ считать признаком AI и какие приметы живого текста беречь |
| `examples.md` | Нужен образец "до и после" |

## Алгоритм работы

Механическое делает скрипт, решения принимает модель. Порядок именно такой: без первого шага модель
тратит проход на поиск того, что находится регулярным выражением.

### Шаг 1. Прогнать скрипт

Замысел подготовки текста перед проверкой - исключать области, где находка не находка, - взят из
`humanizer_ru/textprep.py` проекта [comol/Humanizer_RU](https://github.com/comol/Humanizer_RU)
(MIT, версия 0.3.0). Реализация здесь своя и решает другую задачу: тот линтер меряет читаемость
русского текста вообще, а этот сканер сторожит правила набора. Пользоваться ими имеет смысл вместе:
сканер обязателен и падает в сборке, линтер запускают отдельно, когда пишут длинный текст наружу.

```bash
python scripts/humanize_scan.py <файл>                    # отчет, файл не меняется
python scripts/humanize_scan.py <файл> --fix              # плюс механические замены на месте
python scripts/humanize_scan.py <файл> --genre reference  # задать жанр явно
python scripts/humanize_scan.py <файл> --json             # машиночитаемый отчет
python scripts/humanize_scan.py <файл> --no-technical     # без проверки технического регистра
python scripts/humanize_scan.py <письмо> --technical      # проверять регистр и в письме
```

Скрипт находит и с `--fix` чинит сам: букву е с диакритикой, длинное и короткое тире,
кавычки-елочки, символ многоточия. Находит, но НЕ чинит: текстовые стрелки (на их месте нужно слово
по смыслу), стоп-фразы из таблиц, эмодзи-маркеры в начале строк, слишком плотные заголовки и
бытовые обороты вместо технических - категория `[регистр]`.

**Жанр решает, какие категории проверяются.** Жанрозависимых категорий две, и каждый жанр глушит
ровно одну:

| Жанр | Когда | структура | регистр | остальные |
|---|---|---|---|---|
| `reference` | README, правило, SKILL.md, справочник, журнал изменений | ВЫКЛ | вкл | вкл |
| `prose` | отчет, статья, пост, эссе (по умолчанию) | вкл | вкл | вкл |
| `letter` | письмо, ответ | вкл | ВЫКЛ | вкл |

Жанр берется из `--genre`, иначе определяется сам: сначала по пути и имени файла, затем по
содержимому. README с приветствием это справочник, а не письмо - порядок именно такой.

Плотные заголовки в справочном документе уместны по существу, и до введения жанров сканер
штрафовал за них всю документацию набора: из 40 правил чисто проходило НОЛЬ, а после - 22.

**Часть находок снимается по области, а не по жанру.** Стрелка в таблице это обозначение
соответствия, слово в кавычках упоминается, а не употребляется, а адрес ссылки не проза. Все это
маскируется адресно, но механическое не маскируется нигде кроме кода: запрещенный символ остается
запрещенным и в таблице, и во frontmatter, потому что EDT рубит его одинаково.

Ограничение названо явно: кавычка, открытая на предыдущей строке, читается как открывающая, и в
такой строке границы цитат смещаются. Абзац с цитатой, перенесенной через строку, даст находку на
упоминании.

Категория `[регистр]` не чинится механически по определению: замена зависит от того, что код делает
на самом деле. Скрипт называет найденное слово целиком и номер строки, формулировку подбирает модель.

Совпадение идет по границе слова: "копит" не находится внутри "накопитель", "умеет" - внутри
"умелый". Часть записей - основы (`досып`, `схлопыв`, `ловушк`), они ловят любое окончание, но
только с начала слова.

Блоки кода и inline-код исключены из поиска: внутри них тире и стрелка - часть синтаксиса, а
метафора в комментарии к примеру кода правится вместе с примером, а не отдельно.

Код возврата 0, если находок нет. Это позволяет ставить скрипт в проверку перед коммитом.

### Шаг 2. Решить, нужно ли переписывание вообще

Скрипт не нашел ничего и текст не вызывает подозрений - работа закончена. Сказать об этом и НЕ
создавать выходной файл: копия, идентичная исходнику, вводит в заблуждение.

Проверить жанр по разделу "Когда НЕ применять". API-документация, чек-лист, регламент, таблица
бенчмарков - там структура не дефект, и переписывать нечего.

Есть образец авторского стиля - разобрать его до правок, см. "Калибровка по образцу". Образец
главнее правил этого скила.

### Шаг 3. Переписать то, что осталось

Читать `references/false-positives.md` ДО правок: половина признаков AI встречается у аккуратного
человека. Дальше по жестким правилам:

- убрать буферные вступления и дежурные заключения;
- слить связанные пункты в прозу, оставить списками только параллельное и независимое;
- сократить заголовки до числа реальных смен темы;
- сломать ровный ритм, чередуя длину предложений;
- разбить триплеты-штампы на пары и одиночные формулировки;
- заменить стрелки словом по смыслу, стоп-фразы - по таблице в `references/stop-phrases.md`;
- убрать эмодзи-маркеры, если жанр их не требует;
- переписать бытовые обороты из категории `[регистр]` на действие и предмет: что именно делается,
  с чем и в каком количестве. Пройти по тексту и тем же проверочным вопросом снять декоративные
  фразы, которых в списке скрипта нет. В произвольном жанре этот пункт не выполняется.

Тонкие приемы уровня фразы - в `references/language-antipatterns.md`.

### Шаг 4. Проверить себя

Прогнать скрипт повторно, затем пройти чек-лист ниже и ответить на два вопроса:

- что в получившемся тексте все еще очевидно машинное?
- появился ли факт, имя, число, дата или цитата, которых не было в исходнике? Выдумка - дефект,
  даже если звучит человечнее расплывчатого оригинала.

### Шаг 5. Отдать результат

Режим File - сохранить в `<имя>-human.md` рядом с исходником и сообщить путь. Режим Inline -
вернуть текст в чат. Встроенный режим - отдать ТОЛЬКО текст, без разбора правок.

## Чек-лист перед сдачей текста

- [ ] Вступление начинается с сути, а не с "в современном мире".
- [ ] Финал - содержательная мысль, а не "надеюсь, это поможет".
- [ ] Заголовков ровно столько, сколько реальных смен темы.
- [ ] Буллеты только для параллельных независимых пунктов.
- [ ] Длина предложений неровная.
- [ ] Нет триплетов-штампов.
- [ ] Нет стоп-фраз из таблицы выше.
- [ ] Bold на терминах и акцентах, не на каждом абзаце.
- [ ] Нет эмодзи-маркеров (если жанр их не требует).
- [ ] Нет длинных тире через предложение.
- [ ] Нет диакритической "е" (Cyrillic Letter Yo, U+0451), кроме случаев когда это требование жанра.
- [ ] Хеджирование осталось только там, где есть реальная неопределенность.
- [ ] Числа, термины, имена, код не пострадали.
- [ ] В техническом тексте нет бытовых оборотов вместо действий и предметов: по каждому глаголу и
      образу можно назвать метод, поле, код ошибки или измеренную величину.

## Когда НЕ применять

Разделы ниже - про переписывание в живой стиль. Проверка технического регистра здесь действует
наоборот: в API-документации, регламенте и отчете с метриками она нужна БОЛЬШЕ всего, а отключается
только на произвольных жанрах - письме, ответе, эссе.

- API-документация с эндпоинтами и параметрами - структура нужна.
- Чек-листы для исполнения, runbook - буллеты по делу.
- Юридические и официальные документы - стиль регламентирован.
- Регламенты, инструкции по технике безопасности - формальная структура обязательна.
- Табличные данные, бенчмарки, отчеты с метриками - таблицы и заголовки уместны.
- Когда пользователь явно просит "структурируй", "оформи в виде списка", "сделай TOC".

## DO / DON'T

**DO:**
- Сохранять смысл, числа, термины, цитаты буквально.
- Ломать ровный ритм предложений и абзацев.
- Удалять буферные вступления и дежурные заключения.
- Сводить связанные пункты в прозу, оставлять списки только для реально параллельных вещей.
- Сокращать количество заголовков до реальных смен темы.

**DON'T:**
- Упрощать технические термины ради "человечности".
- Менять числа, версии, имена файлов, идентификаторы.
- Добавлять разговорные элементы там, где пользователь хочет деловой регистр.
- Переделывать обоснованную структуру (API-доки, чек-листы) - сначала проверить раздел "Когда НЕ применять".
- Заменять стоп-фразы на синонимы-штампы (вместо "давайте погрузимся" писать "давайте рассмотрим").

## Источник каталога признаков

Часть признаков сверена с [Wikipedia:Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) -
каталогом WikiProject AI Cleanup, собранным на тысячах случаев генерации в статьях. Полезная оттуда
мысль: модель выбирает статистически наиболее вероятное продолжение, поэтому тяготеет к формулировке,
подходящей самому широкому числу случаев - отсюда и обтекаемость, и одинаковость.