Своя автоматизация
Достроить инструмент под себя: скиллы, которые срабатывают, хуки и параллельная работа.
Перестать просто пользоваться инструментом и начать достраивать его под себя: скиллы, которые действительно срабатывают, хуки и параллельная работа.
Когда методику пора превращать в скилл
Правило простое: объяснили одно и то же третий раз, значит это скилл.
Признаки готовности: у задачи повторяемые входы, проверяемый результат и требования, о которых вы каждый раз вспоминаете в конце.
Оформи скиллом то, что мы только что сделали. Требования: 1. Имя скилла латиницей, kebab-case, по предмету работы. 2. В описании явно перечисли фразы-триггеры на русском, по которым его надо подхватывать. Описание решает, будет ли скилл вообще применяться. 3. Внутри: пошаговый процесс, чеклист приёмки, типичные ошибки, которые мы обсуждали по ходу. 4. Не выдумывай шаги, которых у нас не было. Если чего-то не хватает, спроси. В конце покажи мне готовый SKILL.md целиком и скажи, куда его положил.
Почему скиллы молчат
Самая частая беда со скиллами не в том, что они плохо написаны внутри. Модель просто не понимает, когда их применять. Скилл, который не подхватился, не существует.
«Помогает с финансами» не срабатывает никогда. Нужна конкретная ситуация.
Скилл-комбайн на пять работ не подхватится ни на одной. Признак: в описании три раза встречается «а также».
В описании канцелярит, а просите вы обычными словами. Впишите в описание те формулировки, которыми пользуетесь на самом деле.
Длинный файл вытесняет из контекста то, что важно, и инструкция тонет.
Скилл ни разу не запускали на реальной задаче. Задайте ту самую фразу и посмотрите, подхватился ли он сам.
Скилл, убирающий из русского текста машинный ритм, молчал месяцами. Методика внутри была нормальная. В описании стояло «маскировка ИИ-паттернов в текстах», и модель не связывала это с задачей «напиши текст на сайт».
Чинили описание. Вписали, для каких работ его грузить (кейсы, коммерческие предложения, статьи, письма) и какими словами это правда просят вслух: «гуманизируй», «убери ИИ-паттерны», «сделай по-человечески». После этого скилл начал подхватываться сам.
Подстраховка для того, что обязано срабатывать всегда. Скилл критичен: не надейтесь только на описание, добавьте строку в файл правил. Описание отвечает за узнавание задачи, строка в правилах за то, что мимо не проскочит.
Проверка в одну фразу. Спросите: «какие скиллы ты подключил к этой задаче и почему». Нужного в ответе нет, значит чинить надо описание.
Список разрешённых инструментов это про удобство: он избавляет от лишних подтверждений и не мешает скиллу сделать что-то опасное. Настоящие границы держат хуки и ваше подтверждение на необратимых действиях. Чужие скиллы из интернета читайте перед установкой так же, как читали бы чужой скрипт.
Хуки
Хук это автоматическое правило на событие: перед запуском команды, после правки файла, в начале сессии.
На них держатся защиты: блокировка опасных команд, запрет тащить закрытые файлы в контекст. Свои хуки заводите осторожно и по одному: хук, который срабатывает не на то, отравляет каждую сессию.
Рой, циклы и автопилот
Три разных способа не делать работу руками. Их часто путают, а решают они разные задачи.
Много агентов одновременно над разными кусками одной задачи. Разобрать сто файлов, собрать данные по двадцати компаниям. Каждый видит только свой кусок, результаты сводятся в конце.
Одна и та же работа повторяется, пока не выполнится условие: пока не найдено N штук, пока проверка не станет зелёной, каждые пятнадцать минут. Отличие от роя: по кругу до результата, а не вширь.
Режим работы: очередь задач по приоритету, решения без переспросов, рои и циклы по необходимости, до закрытия всего списка.
Три типовых провала. Первый: рою отдали задачу, требующую общего контекста, и двадцать агентов сделали двадцать несовместимых кусков. Второй: на выходе никто не проверил результат, и в свод попал мусор. Третий: рой запустили там, где хватило бы одного скрипта, и заплатили за это токенами.
Правило: рою отдаётся механика с чёткими границами. Суждение остаётся человеку.
Передача работы между сессиями
Сессия заканчивается, задача нет. Handover это записанный контекст: что сделано, что осталось, где грабли, какое состояние репозитория.
Правило одно: записали handover, сразу коммитьте и пушьте. Иначе другая сессия его не увидит.
Где это всё живёт
Когда автоматизация выходит за пределы ноутбука, встаёт вопрос, на чём она крутится круглосуточно.
| Вариант | Для чего берут |
|---|---|
| Провайдер приложений (Railway, Render и подобные) | Бэкенд плюс managed-база в одном проекте, деплой прямо из репозитория |
| Хостинг статики (Cloudflare Pages, Netlify) | Сайты и страницы без своего сервера, деплой автоматически из основной ветки |
| Фронтенд-платформы (Vercel) | Фронтенд без постоянно живущего бэкенда. Для долгих процессов не подходит: код поднимается на каждый запрос |
| Свой сервер плюс расписание | Задача раз в день. Скрипт и cron, без отдельной платформы |
Сначала спросите, нужен ли вообще сервис. Задача раз в день по расписанию решается скриптом плюс расписанием, платформа тут лишняя. Нужен внешний доступ и база: провайдер приложений. Нужна только статика: хостинг статики.
Всё остальное требует обоснования: каждый новый сервис это ещё одна вещь, которая однажды упадёт в неудобный момент.
Визуальные конструкторы автоматизаций удобны на демонстрации и неудобны в сопровождении: логика живёт внутри редактора, в истории версий её не видно, глазами на ревью не прочитаешь и толком не протестируешь. Визуальный слой окупается там, где сценарий собирает не инженер и цена ошибки низкая.
Написан скилл, который подхватывается сам, и вы можете назвать, какую свою рутину отдали бы рою, а какую скрипту по расписанию.
Что сделать
Результат: Работающий свой скилл и понимание, какую рутину чем закрывать.