Гайд · из моей реальной практики

Как я использую Claude Code
для непрограммистских задач

Разбор моей реальной практики: какие задачи я решаю Клодом помимо кода, как устроен мой «дата-лейк», как работает память между сессиями, какие скиллы и автоматизации я построил, и какие приёмы делают это рабочим. Всё ниже — реконструкция из моих файлов, скриптов, памяти и отчётов в ~/dev/claude/data.

00Главная идея

Я использую Claude не как чат, а как сотрудника-агента с доступом к локальной копии всей компании — он и отвечает на вопросы, и сам делает работу.

Вся переписка, задачи, продажи и звонки стянуты в одну папку на диске. Claude получает к ней доступ через обычные файловые инструменты (Grep, Read, агенты) — и поэтому может отвечать на вопросы уровня «что горит у клиентов на этой неделе», «сколько реально займёт фича X», «кто из партнёров приносит деньги» — со ссылками на конкретные цитаты и цифры, а не из головы. И это не только аналитика: тем же доступом он выполняет работу — ставит и ведёт задачи в Notion, отвечает на вопросы команды, пишет сообщения от моего лица, работает в нашей CRM, меняет настройки в системах и гоняет автоматизации.

Стянуть данные локально Claude читает/грепает их сам Анализ — или действие Отчёт, задача в Notion, ответ — туда, где работает команда

Три вещи делают это мощным: (1) данные локальны — не завишу от API-лимитов и могу мгновенно искать по всему массиву переписки; (2) память переживает сессии — Claude помнит мои правила и прошлые выводы; (3) результат уходит туда, где работает команда — отчёт сразу летит в чат, а не остаётся в терминале.

1 Ментальные модели 2 Какие задачи я решаю 3 Дата-лейк: структура данных 4 Синхронизация источников 5 Три уровня памяти 6 Кастомные скиллы 7 Автоматизация без меня 8 Приёмы и лайфхаки 9 Контроль качества 10 Формат вывода: HTML-отчёты 11 Чеклист новой задачи 12 Что можно улучшить

01Ментальные модели: как я про это думаю

Архитектура ниже — следствие. А это — принципы, на которых она держится. Большинство из них я проговорил, объясняя систему другому фаундеру; собрал здесь самое важное.

Сначала перестроить себя, а не инструмент

Главное ограничение — не модель, а скорость, с которой адаптируется твой мозг. Обогнать её нельзя. Поэтому первая цель — просто просидеть с ним как можно больше часов, пока не перестроятся привычки и новый способ работать не станет рефлексом. Всё остальное в этом гайде — уже про то, что начинаешь делать, когда перестройка пошла.

«Ты не сможешь обогнать скорость, с которой адаптируется твой мозг. Это невозможно. Поэтому первой целью я видел — просидеть с ним как можно больше, чтобы перестроиться.»— из разговора о системе, июнь 2026

① Описывай ЧТО, а не КАК

Главный сдвиг в голове. Ты описываешь желаемое состояние, а не способ его достичь. Я даже не знаю, где лежит мой скрипт, скачивающий чаты, и в каком кроне он прописан — и это нормально: я описал результат («чтобы чаты всегда были скачаны»), а не плумбинг.

«Тебе не надо додумывать, как это сделать. Тебе надо додумать, что ты хочешь.»

② Модель выдаёт среднее — правило 95/5

Любая LLM — статистическая модель: она выдаёт среднее из того, что прочитала. На 95% задач среднего хватает — результат не хуже, чем сделает сотрудник. Но на 5% (стратегия, маркетинг, креатив) среднего мало — туда нужно докинуть свой контекст: свою доску, свою логику, важное именно для тебя.

③ Не жди стратега

Следствие из 95/5. Где надо придумать хорошо — это всё ещё работа эксперта. Пример из кода: как в CRM реализована авторизация — мне всё равно, «как-то есть и работает». А вот архитектурная связь сущностей — это моё, тут я докидываю контекст и думаю сам. Это не «не для стратегии»: с твоей рамкой и контекстом он отлично прорабатывает стратегические записки (примеры — в разделе «Какие задачи») — просто направление задаёшь ты, а не он из себя.

④ Относись как к способному коллеге без контекста

Он не тупой — но базово тебя и твой бизнес не знает. Объясняй так же, как объяснял бы толковому новому человеку. Не нужно писать мелких сверх-специфичных правил «на каждый чих» — нужен внятно поданный контекст.

⑤ Вся игра — это контекст

Когда я написал своего агента с нуля, стало очевидно: 90% результата — это дать модели нужный контекст и правильные инструменты, которыми она сама дообогатит этот контекст. Дата-лейк, память и скиллы ниже — всё это машинерия ровно под одну цель: подать правильный контекст в нужный момент.

⑥ Не выполняй рутину — автоматизируй её

Повторяющееся не просят делать — просят написать скрипт и поставить в крон. Тогда данные всегда свежие и без расхода токенов, а агент в момент работы просто берёт готовое.

«Не проси скачивать сообщения. Попроси написать скрипт и положить в крон — чтобы было всегда, без токенов.»

Где настоящий рычаг: ×100, а не ×5

Прикрутить нейронки к существующему процессу — это костыли, дают ×3–×5 к производительности. Перепридумать процесс с нуля, раз уж теперь всё иначе — даёт ×100. Поэтому самые большие куски ценности рождаются не в «оптимизации как было», а в «как бы это выглядело, если строить заново».

Технарям: напиши свой agent loop

Если хоть немного программируешь — потрать день и напиши простейшего агента сам. Любой современный агент — это цикл: запрос к LLM → вызов инструмента → следующий запрос к LLM, и так пока задача не решена. Когда напишешь это руками, намного глубже поймёшь, чего от агента ждать в разных ситуациях.

02Какие задачи я решаю

Спектр — почти весь нетехнический менеджмент компании. Ниже сгруппировано по типу работы, с реальными примерами из data/reports/.

КатегорияЧто Claude делаетРеальные артефакты
Действия в системах, не только чтениеНе просто аналитик: ставит и ведёт задачи в Notion, отвечает на вопросы команды, работает в нашей CRM, меняет настройки в админках и системах, пишет и отправляет сообщения — выполняет работу, а не только отчитываетсяскиллы notion-tasks, write-as-me + telegram-send, project-setup
Разбор переписки → конфликтыСканирует клиентские чаты, находит эскалации, баги, угрозы ухода, «висяки»; сопоставляет с GMV клиента и приоритизируетdaily/*.txt, <клиент>_chat_analysis, <клиент>_conflict_analysis
Оценка задач разработкиЧитает код репозиториев и выдаёт ТЗ + оценку в днях, ища самый дешёвый путь через готовые механизмы. Мост между бизнесом и devскилл estimate-task, оценки клиентских интеграций, starter_blocks_roadmap
Аналитика продаж и выручкиТянет Redash/AmoCRM, считает GMV, комиссии менеджеров, когорты, динамику по странамsales_analytics, sales_deep_analytics, sales/redash/*
Партнёрская программаСшивает 3 несовместимых системы учёта (Notion ∪ Telegram ∪ Amo), считает реальный топ партнёров, конверсию, цикл сделкиpartner_program_analysis, partner_analysis/union.json (все партнёры одним датасетом)
Команда и процессыСводные обзоры по рабочим процессам и нагрузке, подготовка встреч 1-1 и ретроспективвнутренние сводки по команде
Продукт и приоритетыСводит пожелания клиентов, гипотезы, тикеты, роадмап платных доработокproduct_priorities, autopilot_wishes, notion/bugs_features/*
Запуски и процессыАнализ процесса онбординга клиентов, эмпатии в чатах запуска, автоматизация рутиныlaunch_process_analysis_2026, launch_empathy_automation_2026
Стратегия и ресёрчСтратегические записки (AI-эра, коммодитизация софта), хронологии решений по продуктуstrategy_ai_era, software_commoditization_starter_2026, «Cabinet timeline»
Тест AI-автопилотаПрогон тестовых сценариев бота, 3-way сравнение ответов на реальных цитатахtestbot_3way_comparison, testbot_real_quotes_*
Звонки → знанияАвтосбор записей со всех источников → сжатие → Google Drive → ручная загрузка в NotebookLMsync_recordings.py, папка calls/
Коммуникация от моего лицаЧерновики и отправка сообщений в моём голосе, с регистром под получателяскиллы write-as-me + telegram-send
Ведение задачБерёт задачи из Notion-канбана, ведёт статусы, закрывает — в т.ч. автономным цикломскилл notion-tasks

Плюс личные задачи вне работы — Claude используется и за пределами Starter (отдельные папки по проектам и клиентам). Принцип тот же: стянуть контекст локально → проанализировать → получить отчёт.

03Дата-лейк: как организована структура

Всё живёт в одной папке ~/dev/claude/data — «Starter Data Lake». Один README.md описывает, что где лежит и как обновлять. Это сердце системы.

Источники (входящие данные)

  • telegram/ — сотни рабочих чатов, каждый как плоский grep-friendly chat.txt (где есть — рядом сырой messages.json)
  • pachca/ — внутренний мессенджер: каналы по отделам + _users.json (реестр сотрудников = источник истины по ФИО)
  • notion/ — выгрузки баз: пожелания, тикеты, платные доработки, гипотезы, спринты, протоколы совещаний (2021–2026)
  • sales/amo/ (лиды, контакты, воронки) + redash/ (GMV, комиссии, когорты в JSON)
  • calls/ — записи звонков (аудио + транскрипты)

Обработка и вывод

  • scripts/ — синхронизаторы и утилиты (Telegram, Пачка, Notion, Amo)
  • insights/ — пайплайн извлечения фактов в SQLite (insights.db)
  • reports/ — готовые HTML-отчёты + daily/ (ежедневные сводки)
  • research/, sales/, <клиент>/ — материалы по конкретным темам
  • .secrets/ — отдельная защищённая папка для токенов, вне кода

Почему это работает

  1. Плоские .txt рядом с .json. Каждый чат сохраняется и как структурированный JSON (для скриптов), и как человекочитаемый chat.txt с форматом [дата] Автор: текст — последний идеально грепается. Daily-скрипт делает буквально grep -E "^\[($DAY0|$DAY1)" по всем чатам.
  2. Один README.md как карта. ID баз Notion, пути к токенам, команды синхронизации — всё в одном месте, чтобы и я, и Claude находили без раскопок.
  3. Источник истины задокументирован. Например, ФИО берутся только из pachca/_users.json, а не угадываются по нику — это записано и в README, и в памяти.

Почему просто файлы и grep, а не RAG / векторная база

Сознательный выбор. Модель и так ищет «как по коду»: находит строку, ищет её вхождения в других местах, собирает себе контекст — и так же умеет с любым текстом. RAG здесь только мешает: поиск идёт многократно, и когда подтягиваешь по документу за раз (один, второй, третий) — это сильно тормозит. Плоские .txt + grep быстрее и предсказуемее. Единственное обязательное условие — всё привести к тексту: звонки → транскрипт (Whisper, локально, бесплатно), а не складывать скриншоты, на которых «сожрёшь бесконечность токенов».

04Синхронизация: данные всегда свежие

Дата-лейк не статичен. Скрипты в scripts/ регулярно дотягивают новое, чтобы Claude всегда работал с актуальной картиной:

СкриптЧто тянетКак часто
telegram_sync.py / telegram/Новые сообщения из рабочих Telegram-чатов (свой sync_telegram.sh + лок — медленные FloodWait-догоны не блокируют остальные синки)каждые ~15 мин
pachca_sync.pyКаналы и личку Пачки + реестр сотрудниковрегулярно
amocrm_sync.pyЛиды, контакты, заметки, воронки из Amoрегулярно
redash_sync.pyСнимки аналитики из Redash (GMV, комиссии, когорты) — кэш сохранённых запросов, без нагрузки на продраз в сутки
notion_*.pyБазы Notion целиком + инбокс + ошибки лаунчерапо запросу/скрипту
sync_recordings.pyЗаписи звонков → ffmpeg-сжатие → Google Driveкаждые 3 ч (launchd)
sync_all.shОркестратор быстрых синков (pachca, amoCRM, redash) под общим локом и таймаутамиcron каждые 15 мин

Ключевой принцип: сначала зеркалирую данные локально, потом анализирую. Это снимает зависимость от rate-limit'ов API во время самого анализа и позволяет грепать всё мгновенно.

05Три уровня памяти

Чтобы Claude не начинал с нуля каждую сессию и не повторял ошибки, у меня три разных механизма памяти — для разных горизонтов.

уровень 1

claude-mem — хроника работы

Плагин, который автоматически записывает «наблюдения» о каждой сессии (что исследовано, что решено, что сделано) в поисковую базу. Сейчас 513k токенов прошлой работы, recall экономит ~95% токенов против перечитывания.

Типы: 🔵 discovery · 🟣 feature · ⚖️ decision · 🔴 bugfix. Доступ через mem-search или get_observations([ID]).

уровень 2

File-memory — правила и факты

Папка memory/ с MEMORY.md-индексом и файлами по одному факту. Четыре типа: user (кто я), feedback (как мне работать), project (текущие проекты), reference (внешние ресурсы).

Сюда попадают мои поправки, чтобы они не повторялись. Загружается в контекст каждой сессии.

уровень 3

insights.db — структурированные факты

SQLite-база, куда LLM-пайплайн (insights/extract/) извлекает из переписки типизированные факты: проблемы, жалобы, по тирам клиентов и датам. Запрос — query.py top-problems --tier 1 --months 3.

Для аналитики, где нужен SQL поверх «мягких» данных переписки.

Как я обучаю Claude через feedback-память

Самый ценный приём. Когда Claude ошибается, поправка не теряется — она становится файлом памяти с разделами Why (что именно пошло не так, с датой и фактом) и How to apply (конкретный чеклист). Примеры из моей памяти:

Эффект: одни и те же грабли не повторяются, и Claude постепенно перенимает мою модель бизнеса и мои стандарты качества.

06Кастомные скиллы — мои многоразовые рабочие процессы

Скилл = записанный один раз процесс, который Claude подхватывает по триггер-фразе. Я построил их 13. Это превращает «объясни заново каждый раз» в «возьми следующую задачу».

СкиллТриггерЧто делает
write-as-me коммуникация«напиши от меня», «ответь X»Черновик в моём голосе: кратко, sentence-case, регистр под получателя (клиент/команда/близкие), без мата и канцелярита, со смайлом )
telegram-send коммуникация«скинь в телеграм», «найди чат»Чтение/поиск/отправка через Telegram. Реальная отправка, не черновик
estimate-task продукт↔dev«оцени задачу», «сколько займёт»Глубокое исследование кода → HTML-ТЗ с baseline, путями A/B, таблицей файлов и оценкой в днях; отдельно ищет периферию (дизайн, CRM, локализация)
notion-tasks задачи«возьми следующую задачу»CLI поверх Notion-канбана: list / claim / comment / complete. Работает и в автономном цикле
notion-download данныедаёшь ссылку на NotionСкачивает страницу (+ вложенные) как Markdown для анализа
starter-redash аналитика«дай GMV / churn / выручку»Запросы к Redash за метриками по проектам и месяцам
do-it-nicely качество«сделай нормально», авто на сложномЗаставляет не хвататься за первое решение: собрать контекст → 2-3 кандидата с trade-offs → выбрать поддерживаемый
deploy-to-our-server инфра«задеплой на наш сервер»Деплой проектов на мою инфраструктуру (k3s)
add-domain-to-our-server инфра«привяжи домен»Биндит поддомен на процесс (ingress-nginx + cert-manager)
add-project-to-starter-ai инфра«подключи клиента к автопилоту»Заводит новый клиентский проект в моего Telegram-бота
+ karpathy-guidelines, solid, playwright-core — для технической работы.

Почему скилл лучше, чем длинный промпт каждый раз

07Автоматизация: Claude работает, пока меня нет

Самый продвинутый слой. Claude запускается без меня по расписанию через claude -p (headless) и сам доводит работу до отправки в чат.

Кейс: ежедневная сводка конфликтов → автопостинг в Пачку

Каждое утро в 10:00 (GMT+7) launchd запускает daily_conflicts_report.sh:

grep последних 3 дней
по клиентским чатам
+ revenue.json
(GMV клиентов)
claude -p с агентами
находит конфликты
сортировка по GMV
🔴🟡🟢
POST в Пачку
от служебного бота

Тонкости, которые делают это надёжным:

Кейс: записи звонков → NotebookLM

sync_recordings.py (launchd, каждые 3 ч) собирает записи с Я.Диска (Телемост), ~/Downloads и вложений Пачки, сжимает ffmpeg'ом (видео → 480p, аудио → 64k mono), переименовывает в ДАТА_ВРЕМЯ_источник_контекст и кладёт в Google Drive. Дальше я вручную добавляю как источники в NotebookLM (у него нет API). Умные фильтры отсекают мои собственные сообщения и не-записи.

А под локальный захват я собрал свой опенсорс-инструмент — MemorAI (menu-bar для macOS): сам пишет звонки и экран и расшифровывает локально через whisper.cpp, без облака. Тоже часть этого «второго мозга».

Кейс: автономный цикл по задачам

Скилл notion-tasks + /loop позволяют Claude в цикле: взять самую приоритетную задачу из колонки Todo → перевести в In Progress → сделать → закрыть с результатом → взять следующую. Рискованное уходит в Review для моей проверки, заблокированное — в Blocked с причиной.

Кейс: агент-«OS» для запуска клиентских проектов — уже командный, не только мой

Самый продвинутый из моих агентов обслуживает не меня, а команду. Запуск нового ресторана-клиента — это десятки настроек дизайна (палитра, шрифты, логотипы, страницы, скругления) в нашей CMS. Раньше дизайнер делал это руками. Теперь — пишет боту в Telegram обычными словами и кидает файлы, а агент сам применяет изменения. Telegram стал админкой, Claude — исполнителем, инфраструктуры в облаке нет: всё крутится на ноуте оператора.

дизайнер пишет в TG:
«вот брендбук, округли кнопки»
бот кладёт
в очередь (inbox)
агент берёт батч
заявок, грузит контекст
шлёт план,
применяет, сверяет
отчёт в TG +
запись в историю

Что в нём интересного — приёмы, которые переносятся на любой процесс вида «приёмка → батч → применить → отчитаться»:

08Приёмы и лайфхаки

Отдельные техники, которые повторяются в моей работе и дают непропорциональный эффект.

① Зеркаль данные, потом анализируй

Не дёргай API во время анализа. Сначала синхронизируй в плоские файлы, дальше Claude грепает локально — быстро и без лимитов.

② Суб-агенты для широкого сканирования

Когда нужно прочесать десятки чатов/файлов — Claude разворачивает параллельные агенты, каждый читает свой кусок, результаты сводятся. Daily-отчёт построен на этом.

③ Факты отдельно от интерпретаций

В отчётах о людях — два уровня: «что произошло (цитата + дата)» и отдельно «что это может значить — требует проверки». Не смешивать. Особенно перед публикацией для руководителя.

④ Ищи дешёвый путь (для оценок)

Первый проход всегда переоценивает, предполагая greenfield. Правило: для каждой задачи отдельно выписать «MVP через переиспользование» — есть ли готовый метод/поле/UI-блок на 80% работы.

⑤ Источник истины, не догадки

ФИО — только из _users.json. Имя по email/нику не угадывать. Партнёр — только если есть чат. Эти правила вынесены в память, чтобы держаться фактов.

⑥ Клонируй свой голос

write-as-me хранит мой стиль с реальными примерами и регистром под получателя. Исходящие сообщения звучат как я, а не как «вежливый ассистент».

⑦ Результат — туда, где работают

Отчёт не остаётся в терминале: он летит в нужный чат Telegram/Пачки. По правилу «прошу отправить — шлю сразу, потом дублирую мне, чтобы поймал ошибку».

⑧ Снимок во времени

Большие анализы (партнёры) сохраняются как датированный снимок (union.json + README с методологией). Следующий раз — сравниваю динамику, а не переизобретаю логику.

⑨ Конфигурация как код

Суждения, которые должны быть стабильными, выноси из агента в выверенный людьми файл-правило (словарь «фраза → точное поле/значение»). Тогда агент не угадывает, а применяет детерминированно и одинаково везде.

⑩ Приёмка → батч → применить → отчитаться

Командные процессы своди к одному циклу: заявки падают в очередь → агент берёт их батчем (всё накопленное разом) с полным контекстом → применяет → сверяет у источника истины → отчитывается и логирует. Транспорт (бот/форма) держи тонким.

Моя петля обратной связи (как это всё улучшается)

Claude делает задачу Я ловлю ошибку «беглым взглядом» Поправка → файл памяти (Why + How) В следующий раз не повторяется

Именно за счёт этой петли Claude из «умного, но наивного» постепенно становится «знающим мой бизнес». Большинство feedback-файлов в памяти родились ровно так.

09Контроль качества — главная задача

Когда модель делает 95% работы, твоя работа смещается в одну точку — проверять. Это не побочное действие, это основное.

«Самая главная задача — это контроль качества.»— из разговора о системе, июнь 2026

Само-проверка до слова «готово»

Агент не имеет права сказать «готово», пока сам не убедился. Для интерфейсов — гонять end-to-end в браузере (через Playwright): натыкать то, что нарисовал, сделать скриншоты, сверить с требованиями, проверить, что нет JS-ошибок и данные сохранились. Рабочий паттерн:

сделай
функциональность
напиши по ней
сценарии
по сценариям —
e2e-тесты
пройди их сам только потом
вернись ко мне
«Тогда он не приходит и не говорит, что всё готово — когда ты открываешь, а там херня.»

Ревью — в отдельной сессии

Неочевидное, но важное. Решения, принятые внутри сессии, попадают в её контекст и воспринимаются ею как факт — сама себя она уже не перепроверит. Поэтому проверку качества выношу в свежую сессию: на каждую задачу пишется отдельное ТЗ в файл, а отдельный агент сверяет изменения против этого ТЗ — не зная, как мы к этому шли — и ищет лишнее и плохое.

Обобщается и на не-код: ревьюер, который видит только спеку и результат (а не рассуждения автора), ловит больше, чем тот же автор «на свежий взгляд».

Чему я не верю: роли в одной сессии

«Ты опытный архитектор, оцени как архитектор» в пределах одной сессии — не работает: срабатывает не самоназвание роли, а структурная изоляция. Сначала в основной сессии агент сам доводит до рабочего состояния (сам себя тыкает, проверяет). А настоящий контроль качества — это отдельная сессия с чистым контекстом и только ТЗ на входе. Разделение через контекст, а не через ролевые промпты.

10Формат вывода: самодостаточные HTML-отчёты

Мой дефолтный формат результата — один .html-файл с тёмной темой, карточками-метриками, таблицами и цветовыми статусами (🔴🟡🟢). Почему это удачно:

Принцип: формат вывода выбирается под канал потребления. HTML — для чтения и пересылки; plain text — для мессенджера; Markdown — для Notion.

11Чеклист: как ставить Клоду новую непрограммистскую задачу

  1. Данные на месте? Если источник новый — сначала синхронизируй в дата-лейк (или попроси Claude дописать синхронизатор), потом анализируй.
  2. Есть ли правило в памяти? Проверь, нет ли уже feedback/reference, релевантного задаче (определения, источники истины).
  3. Это разовое или повторяемое? Повторяемое — оформляй как скилл, а не как разовый промпт.
  4. Нужны факты — назови источник истины. «ФИО из _users.json», «партнёры из папок Telegram» — чтобы не угадывал.
  5. Для отчётов о людях — попроси разделить факты и интерпретации и пометить, что требует проверки.
  6. Выбери формат и адресата. HTML мне / plain text в Пачку / черновик через write-as-me. Скажу «отправь» — отправит сразу.
  7. Большой анализ — попроси сохранить снимок (датасет + методология), чтобы потом сравнивать динамику.
  8. Опиши результат, а не способ. Что хочешь получить — а «как» (где скрипт, какой крон, какой язык) пусть решает сам.
  9. Важно качество — попроси проверить себя и, для серьёзного, вынеси ревью в отдельную сессию против ТЗ.
  10. Поймал ошибку — зафиксируй в память, чтобы не повторялась.

12Что можно улучшить

Наблюдения по системе — где есть запас.

ЗонаИдея
АвтоматизацияDaily-конфликты — единственный полноценный авто-отчёт. Тем же паттерном (claude -p + launchd + постинг) можно завести еженедельную сводку по партнёрам, продажам или продуктовым пожеланиям.
ПамятьТри механизма памяти живут раздельно. Стоит изредка «подчищать» file-memory (удалять устаревшее) и проверять, что reference-факты ещё актуальны — в инструкции это и заложено, но на практике легко забыть.
insights.dbПайплайн извлечения фактов в SQLite рабочий: запросы отдают данные, ключ в защищённой папке, есть резолвер папок и дедуп. Запас: разовый полный backfill по всей истории — по команде.
СекретыТокены в отдельной защищённой папке (chmod 600); скрипты читают оттуда с фолбэком, чтобы автоматический отчёт не падал. Запас: довести до этого оставшиеся интеграции.
Шаблон отчётаФирменный CSS и конвенции (палитра, компоненты, plain-text для Пачки, правила «факты vs интерпретации») собраны в скилл starter-report — триггер «собери отчёт в моём стиле».
// связь с автором

Очень интересно, но ничего не понятно?

Бывает ) Напиши мне — объясню по-человечески, покажу на своих примерах или просто поболтаем про агентов.

написать в Telegram
отвечаю не всегда сразу, но отвечаю
Собрано из ~/dev/claude/data: README, скрипты, кастомные скиллы, file-memory, claude-mem, 60+ HTML-отчётов и разборов рабочих созвонов.
Всё в этом гайде — реконструкция моей реальной практики, а не рекомендации «вообще».
RU/EN