Несколько месяцев назад я вручную просматривал логи своих Claude Code сессий в поиске тем для блога. Открываешь JSONL-файл, листаешь полтысячи строк служебного шума, выписываешь три интересных момента. Потом начинаешь следующий файл. Через час у тебя есть пять потенциальных тем и стойкое ощущение, что этот процесс можно было не делать вручную.
В какой-то момент я понял: я делаю ровно ту работу, которую сам же прошу автоматизировать у Claude. Нерационально.
Так появился скилл blog-ideas-research.
Что он делает
Скилл берёт логи всех Claude Code сессий, фильтрует из них полезное и выдаёт список идей для постов - с заголовком, углом подачи и ссылками на конкретные сессии, где эта тема всплывала.
Три шага.
Шаг 1: убрать шум локально. Python-скрипт обрабатывает логи до того, как к ним прикоснётся любая языковая модель. Он выбрасывает повторяющиеся записи, заменяет пути и UUID на заглушки, оставляет только уникальные паттерны. Конкретно: UUID типа a3f7c9d2-... превращается в <uuid>, абсолютные пути /Users/igor/projects/... - в <path>. После этого все похожие строки лога схлопываются в одну.
В моём проекте mp root было 33 промпта в сессиях. После фильтрации осталось 5-7 ключевых записей. Экономия существенная. Без этого шага тратишь токены на мусор - повторяющиеся tool call’ы, идентичные Bash-команды, дубли Read-запросов к одним файлам.
Шаг 2: параллельные агенты. Отфильтрованное идёт к нескольким маленьким агентам одновременно. Один определяет тип работы (feature, bugfix, research), другой вытаскивает формулировки, третий группирует по смыслу, четвёртый генерирует заголовки. Все работают параллельно и независимо, каждый видит только свой узкий кусок отфильтрованного JSON.
Здесь нет смысла использовать мощную модель - задача механическая, структурированная. Haiku справляется отлично, и стоит заметно дешевле Opus. Для рутинного парсинга это работает хорошо.
Шаг 3: синтез. Старший агент собирает результаты всех предыдущих, сравнивает с уже опубликованными постами блога и выдаёт ранжированный список. Дубли уходят. На выходе - JSON примерно такого вида:
{
"title": "Polling gates в многофазных пайплайнах",
"angle": "Детерминированный Python между агентами экономит токены",
"evidence": "session_2026-02-14, session_2026-02-17",
"confidence": "high"
}
Поле evidence - это не украшение. Это ссылка на конкретные сессии, чтобы я мог проверить, откуда взялась идея и насколько уверенно агент интерпретировал контекст.
Рекурсия и деградация сигнала
На третьей итерации система предложила написать пост о паттернах оркестрации агентов. Звучало убедительно, confidence высокий. Я открыл источники.
В первой сессии был один вопрос про параллельный запуск - в контексте совершенно другой задачи. Во второй - мимоходом сказанное замечание. Агент склеил два случайных упоминания в “паттерн” и оформил как тему.
Система анализировала свои же прошлые выводы и начала находить темы, которые сама раньше придумала. Замкнутый круг: сигнал деградирует с каждой итерацией. Без внешней точки зрения это происходит незаметно - агент уверен, confidence высокий, а реального материала для поста нет.
А потом то же самое случилось с этим постом. Система предложила написать про то, как она предлагает писать посты. Тема прошла review и стала текстом, который ты сейчас читаешь. Рекурсия состоялась.
Где это ломается
За несколько месяцев я видел четыре типа сбоев.
Придуманные паттерны. Агент видит два похожих упоминания в разных сессиях и делает вывод, что это устойчивый паттерн. Два случайных упоминания токенизации в разных контекстах превращаются в “тему про оптимизацию токенов”. Иногда это правда - тема действительно важная. Иногда просто совпадение. Без поля evidence с конкретными сессиями отличить одно от другого было бы трудно.
Эхо-камера. Если прошлые идеи попадают в контекст следующего цикла, система начинает переоткрывать то, что уже предлагала. С каждым кругом разнообразие падает. У меня из 47 идей за первые две недели 19 оказались дублями уже опубликованных постов - система просто не отслеживала, что я это уже писал, пока я не добавил список опубликованных в её контекст.
Слабый сигнал. Десять идей из тех же 47 я отклонил как “слабый сигнал” - тема интересная, но в логах только одно упоминание, исходный контекст не позволяет написать полноценный пост. Агент поставил им высокий confidence, потому что формально всё верно: тема есть, угол есть, источник есть. Но одного источника мало.
Реальные идеи без базы. Ещё семь идей были настоящими - я хотел бы их написать - но в логах не хватало деталей для полноценного поста. Честный результат: система нашла что-то реальное, но материала на статью нет. Это лучший из возможных отказов.
Что я сделал чтобы не ломалось
Первое - human gate. Ни одна идея не входит в следующий цикл без моего одобрения. Это не последний шаг перед публикацией, это фильтр между итерациями. Внешняя точка зрения разрывает замкнутый круг. Для меня это единственный шаг, который я пока не автоматизирую без потери качества.
Второе - логирование отклонённых идей. Когда я отклоняю что-то, добавляю короткий тег: “дубль”, “слабый сигнал”, “придуманный паттерн”, “нет базы”. В следующих итерациях система реже предлагает то же самое. Это не прямая инструкция - просто контекст, который меняет выводы синтез-агента.
Из 47 идей за первые две недели прошли review 11. Это примерно 23%. Для системы, которая сначала бросает широко и потом фильтрует, результат рабочий. Важнее другое: из этих 11 я уже написал несколько постов, включая этот.
Попробуй сам
Что сработало у меня:
- Скрипт предобработки логов - без него токены уходят на шум, и стоимость итерации резко растёт
- Разделение на маленькие задачи для дешёвых агентов и большую задачу синтеза для сильной модели
- Human review как обязательный шаг между итерациями - не опциональный бонус
- Логирование отклонённых идей с тегами причин отказа
Технически всё это не сложно. Логи уже есть - Claude Code пишет JSONL после каждой сессии в ~/.claude/projects/. Один активный проект за месяц работы даёт достаточно записей, из которых после фильтрации остаётся десяток содержательных.
Скрипт фильтрации можно написать быстро: вытащить только assistant-сообщения выше определённой длины, убрать tool call’ы без текстового контекста, схлопнуть повторяющиеся паттерны через простое хэширование. Этого достаточно для первой версии.
Самая трудоёмкая часть - не написать скрипт и не настроить агентов. Самая трудоёмкая - честно просматривать отклонённые идеи и тегировать причины. Именно это делает систему точнее с каждым циклом, а не просто продуктивнее. Без этого шага через несколько итераций получаешь красивый JSON с уверенными идеями и низким реальным качеством.
Логи уже есть. Там больше материала, чем кажется - надо только не читать их вручную.