Прямо сейчас идет Built with Opus 4.7: a Claude Code hackathon. Было более 20 тысяч заявок, отбор прошли менее 2% и я стал одним из тех, кому посчастливилось попробовать свои силы и получить API токенов на $500 (но об этом в другой раз). Так вот сегодня был AMA с Thariq Shihipar, одним из инженеров, который работает с Claude Code. Не маркетинговый вебинар, а живой разговор с человеком, который сам пишет skills, крутит loops и дебажит CLAUDE.md каждый день. Ниже то, что я записал и проверил на своих проектах.
1. Skills, а не агенты
Главный тезис, который Tharik повторил несколько раз: skills это primary extension point для Claude Code. Не агенты, не MCP-серверы, не промпты в CLAUDE.md.
Skill это файл .claude/commands/*.md, который Claude подхватывает как команду. Внутри может быть prompt, скрипты, ссылки на другие skills. Суть в том, что skill решает одну конкретную задачу: дебаг, code review, интервью, деплой. Claude сам выбирает, какие skills комбинировать под конкретный запрос.
Почему не агенты? Потому что агент с большим system prompt становится rigid. Чем больше инструкций ты запихнёшь в агента, тем хуже он работает на edge cases. Особенно Opus 4.7 (об этом ниже).
2. Не делай “фронтенд-агента” и “бэкенд-агента”
Прямая цитата: “Эра промптов ‘you are an expert designer’ прошла.” Модель и так знает, что она умеет. Не нужно говорить Claude, что он senior backend engineer. Нужно дать ему набор skills: debugging, code-quality, feature-design, и пусть сам разберётся, что применить.
Sub-agents нужны для параллельного выполнения, а не для ролевого разделения. Запустил sub-agent, чтобы он проверил тесты, пока основной пишет код. Вот это рабочий паттерн.
3. /interview вместо ТЗ
Tharik показал паттерн, который я теперь использую постоянно. Вместо того чтобы писать детальное ТЗ, он говорит Claude: “Задай мне вопросы, чтобы понять, что я хочу построить.”
Claude начинает интервью: “Какой фреймворк? Какая целевая аудитория? Нужен ли SSR? А мобильная адаптация?” Причём он задаёт вопросы, которые ты сам бы не додумался задать. После 5-10 вопросов у него в контексте полная картина, и результат на порядок лучше, чем после одного длинного промпта.
Tharik предложил сделать из этого skill /interview. Работает.
4. Opus 4.7 читает инструкции буквально
Это, пожалуй, самый практически полезный инсайт. Opus 4.7 следует инструкциям значительно строже предыдущих моделей. Если в CLAUDE.md написано “NEVER use any”, он реально никогда не использует any. Даже когда это единственный разумный вариант.
Что с этим делать:
-
Пересмотреть свои CLAUDE.md после обновления на 4.7
-
Убрать категоричные формулировки (“never”, “always”, “must”), если они не критичны
-
Дать модели пространство для манёвра: “prefer X over Y” вместо “never use Y”
-
Если Claude внезапно стал перетриггериваться на чём-то, первым делом проверь инструкции
5. CLAUDE.md протухает, и это нормально
Tharik честно сказал: поддерживать CLAUDE.md в актуальном состоянии сложно. В больших компаниях это отдельная роль. Его советы:
-
Проси Claude аудитить свой собственный setup: “Прочитай мои skills и CLAUDE.md, найди конфликты и устаревшие инструкции”
-
Проверяй, как часто триггерятся skills (можно попросить Claude проанализировать историю в
.claude/projects/) -
Проси Claude упростить слишком сложные skills
-
При переходе на новую модель (например, на Opus 4.7) нужно пересмотреть все инструкции
Есть Opus 4.7 prompt guide и migration skill от Anthropic. Можно натравить их на свои skills.
6. Все твои разговоры лежат в .claude/projects
Факт, который не все осознают: каждая сессия Claude Code сохраняется в .claude/projects/. Claude может читать эти файлы. Можно попросить его: “Прочитай мои последние 10 разговоров и скажи, где я теряю время.” Или: “Какие паттерны ошибок ты видишь?”
Но нужно быть специфичным. Абстрактный “дай мне tips” вернёт generic советы.
7. Memory через skills: CRM-паттерн
Встроенная память Claude Code generic. Tharik показал, как он строит свой structured memory layer поверх неё.
Пример: skill, который читает email, извлекает контакты, to-do, события и складывает в структурированные файлы. По сути, CRM внутри Claude Code. Работает через /loop: каждые N минут проверяет новые сообщения, обновляет структурированные данные.
Он готовит это к open source.
8. /loop для continuous data
Для мониторинга и периодических задач Tharik использует паттерн:
1. Написать скрипт, который fetch'ит новые данные (get_messages_since)
2. Создать skill, который обрабатывает эти данные
3. Запустить через /loop с интервалом (например, 20 минут)
Ключевое: скрипт должен быть “tight”. Если ничего нового нет, loop не тратит токены. Иначе сожрёт бюджет на пустом месте.
Для реально real-time задач (медицина, биржа, IoT) Claude Code не подходит. Это coding harness, не event processor. Для таких сценариев нужен managed agent.
9. Верификация: тестовая среда, а не надежда на one-shot
На вопрос “как заставить Claude не ошибаться при работе с критичными данными?” Tharik ответил прямо: не надейся на one-shot.
Для критичных операций (платежи, инфраструктура, production data) нужно:
-
Создать тестовую среду
-
Дать Claude итерировать и проверять себя в ней
-
Только после прохождения всех проверок отправлять в prod
Детерминистические проверки (linting, type checking, custom validators) всегда лучше, чем “проверь свой результат”. Модель может обмануть себя при самопроверке, а tsc --noEmit не может.
10. Claude повторяет ошибки: 4 решения
На вопрос “как справиться с повторяющимися ошибками?” Tharik дал иерархию решений:
Сначала спроси: а это реально ошибка? Часто “ошибки” Claude это просто стилевые предпочтения разработчика. Если Claude пишет чуть иначе, но код работает, может, не стоит бороться.
Linting rules. Если можешь выразить правило как lint rule, сделай это. Claude проверит детерминистически и не повторит.
Hooks. Напоминания, которые вставляются после каждого turn. “Ты работаешь с production данными, проверяй каждое действие.”
Dynamic hooks через skills. Например, /safe включает режим повышенной осторожности: после каждого turn Claude получает напоминание о необходимости проверки. Выключается, когда опасная работа закончена.
Конфликт инструкций. Проверь, не противоречат ли друг другу разные слои CLAUDE.md или skills. Удивительно часто проблема именно в этом.
11. Claude Design vs Claude Code
Tharik сказал просто: Claude Design это opinionated workflow для дизайна с сильной командой дизайнеров за спиной. Результаты “из коробки” выглядят лучше. Claude Code даёт больше контекста кодовой базы.
Если нужен быстрый прототип без привязки к репозиторию, Design хорош. Если нужно вписать в существующий проект, Code лучше, потому что он видит весь код.
По факту Claude Design вдохновлён тем же подходом: дать модели design system + skills, и пусть генерирует.
12. Remotion для демо-видео
Бонус: Tharik делает демо-видео проектов через Remotion (React-фреймворк для программного создания видео). Claude генерирует компоненты, анимации, записывает скринкасты с кликами мыши. За одну сессию собрал видео с анимированным UI.
Паттерн: описываешь design system в файле, даёшь Claude при старте проекта, и все UI-компоненты получаются в едином стиле.
Что из этого я внедрил у себя
Не буду делать вид, что это просто теория. Вот что я уже использую:
-
Skills вместо длинных промптов. У меня 15+ skills для разных задач: публикация постов, рендер обложек, дебаг, деплой. Claude комбинирует их сам.
-
Structured memory. Мой бот хранит контекст проектов, людей, сервисов в файловой структуре. Claude читает нужное перед каждой задачей.
-
Audit CLAUDE.md. После перехода на Opus 4.7 пересмотрел все инструкции. Убрал жёсткие “never”, добавил “prefer”. Результат мгновенный.
-
/loop для мониторинга. Автоматическая публикация постов, проверка серверов, обновление данных.
Если у вас есть вопросы по конкретным паттернам, пишите. Делюсь тем, что работает на практике, а не в теории.
Автор: StudyQA
