5 промптов в Claude Code на каждый день

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

Большинство разработчиков добавляют фичи поверх кода с незамеченными проблемами. Через месяц — загадочные баги в проде, из-за которых приходится рефакторить то, что уже «работало». Этот промпт ломает этот цикл. Запускаешь его перед каждой новой фичей — и получаешь честный список того, что может сломаться, до того как ситуация усложнится. Не «советы по стилю» — конкретные архитектурные проблемы с объяснением механизма поломки.

Промпт целиком (скопировать):

Прочитай файл {path/to/file.py} и файл {path/to/related_module.py}.
Не переписывай код — только анализ.

Найди архитектурные косяки:
— нарушения SOLID и принципов чистой архитектуры
— узкие места при масштабировании (>10x нагрузки)
— потенциальные баги при граничных условиях (пустой ответ API,
  нулевые значения, таймауты)
— отсутствие обработки ошибок там, где она критична
— скрытые связанности (когда изменение одного модуля ломает другой)

Верни нумерованный список. Для каждого пункта:
1. Где именно (файл + строка или функция)
2. В чём проблема
3. Как это проявится при деплое или росте нагрузки

Приоритизируй по критичности: КРИТИЧНО / ВАЖНО / СЛЕДИТЬ.

Пример вывода Claude:

КРИТИЧНО — yield_chaser.py, функция fetch_pool_data(), строки 47-61
Нет retry-логики при таймауте внешнего API. При нагрузке >100 rps
и нестабильном соединении функция молча возвращает None, а caller
не проверяет тип. Первый деплой под нагрузкой упадёт здесь.

ВАЖНО — строки 112-134, класс PoolAnalyzer
Глобальный кэш без TTL накапливается бесконечно. При работе 24/7
через 72 часа потребление памяти растёт ~40 MB/час. OOM на VPS.

СЛЕДИТЬ — строки 203-218, метод _calculate_apy()
Division by zero не обрабатывается при total_liquidity == 0.
В тестах не возникает, в проде случается на новых пулах без ликвидности.

Когда применять:

• Перед добавлением каждой новой фичи в модуль, который не трогал >2 недель
• Перед рефакторингом унаследованного кода, который «просто работает»
• После онбординга в чужой кодовой базе — сразу видишь риски
• Перед деплоем в прод после долгой разработки в dev-среде

Вариации:

1. Быстрый скан на безопасность: добавь в конец промпта «Отдельно выдели: SQL-инъекции, хардкоженные секреты, небезопасные десериализации. Только security-риски.» — для аудита перед мёрджем в main.
2. Аналитика зависимостей: замени «найди архитектурные косяки» на «построй граф зависимостей: что вызывает что, какие модули связаны сильнее всего, где единая точка отказа» — для планирования декаплинга.
3. Сравнение двух версий: «Прочитай {old_version.py} и {new_version.py}. Что изменилось? Какие косяки из старой версии унаследованы в новой?» — для code review после PR.

Один из самых мощных инструментов CC — Task tool. Вместо того чтобы выполнять задачи последовательно, Claude спавнит субагентов, каждый из которых работает в своём контексте. Параллельно.

В скрипте Reels этот промпт описан как «запусти Task tool, спавни четырёх субагентов, каждому отдельную часть задачи». Это не метафора — CC реально создаёт изолированные агенты с отдельными контекстными окнами, которые работают одновременно. Каждый читает свои файлы, выполняет свою задачу, возвращает summary. Основной контекст не засоряется промежуточными результатами. Это меняет скорость работы кардинально: то, что раньше занимало 4 часа последовательной обработки, делается за 1 час параллельно.

Промпт целиком (скопировать):

Задача: {описание общей задачи}.

Используй Task tool. Запусти {N} субагентов параллельно.

Субагент 1 — {название_1}:
Прочитай {path/to/dir_1/}. Задача: {конкретная_подзадача_1}.
Верни: {формат_вывода_1}.

Субагент 2 — {название_2}:
Прочитай {path/to/dir_2/}. Задача: {конкретная_подзадача_2}.
Верни: {формат_вывода_2}.

Субагент 3 — {название_3}:
Прочитай {path/to/dir_3/}. Задача: {конкретная_подзадача_3}.
Верни: {формат_вывода_3}.

Субагент 4 — {название_4}:
Прочитай {path/to/dir_4/}. Задача: {конкретная_подзадача_4}.
Верни: {формат_вывода_4}.

После завершения всех субагентов — синтезируй результаты в один отчёт.

———
Пример конкретной версии (кодовая база):
Используй Task tool. Запусти 4 субагента параллельно.
Субагент 1 — auth: прочитай src/auth/. Найти все точки валидации токенов.
Субагент 2 — api: прочитай src/api/. Найти все незащищённые эндпоинты.
Субагент 3 — db: прочитай src/db/. Найти все raw SQL без параметризации.
Субагент 4 — tests: прочитай tests/. Какие security-сценарии не покрыты.
После — синтезируй в security-отчёт.

Пример вывода Claude:

[Субагент 1 — auth] Завершён. Найдено 3 точки валидации: middleware/auth.py:47,
utils/token_check.py:23, api/protected.py:89. Два из них не проверяют expiry.

[Субагент 2 — api] Завершён. Незащищённых эндпоинтов: /api/v1/status (read-only,
ок), /api/v1/export (возвращает данные без auth — РИСК).

[Субагент 3 — db] Завершён. Raw SQL без параметризации: 2 места в reports.py:134,156.
Потенциальная SQL-инъекция через user_id.

[Субагент 4 — tests] Завершён. Не покрыто: истёкший токен, невалидный формат,
concurrent requests на /export.

СИНТЕЗ: Критичных проблем — 2. Приоритет: /api/v1/export + raw SQL в reports.py.

Когда применять:

• Аудит большой кодовой базы по нескольким независимым модулям
• Параллельный сбор данных с нескольких сайтов или API (субагент 1 — сайт А, субагент 2 — сайт Б)
• Параллельный рефакторинг независимых директорий без конфликтов по файлам
• Генерация тестов для нескольких модулей одновременно

Вариации:

1. Веб-разведка параллельно: «Запусти 4 субагента. Каждый заходит на {url_1}, {url_2}, {url_3}, {url_4} и возвращает таблицу цен / features / условий. Синтезируй сравнение.» — для competitive research.
2. Генерация контента: «Субагент 1 — напиши вступление. Субагент 2 — секция 1. Субагент 3 — секция 2. Субагент 4 — заключение. Критерии: {tone}, {length}, {audience}. После — собери в один документ.» — для параллельного написания длинных материалов.
3. Кастомный субагент-специалист: создай файл .claude/agents/security-reviewer.md с system prompt «ты senior security engineer, проверяй только инъекции, auth, секреты». Тогда просто: «Используй субагента security-reviewer на {path/to/code}». CC загрузит конфиг автоматически.

Любой отчёт, презентацию или документ сначала генеришь в HTML, открываешь в браузере, вносишь правки — и только потом один промпт превращает его в PDF.

PDF — финальный артефакт, но не инструмент итераций. Если ты сразу просишь CC сделать PDF — видишь результат только после рендера. Ошибку в данных или вёрстке обнаруживаешь, когда переделка стоит дороже. HTML-first workflow переворачивает порядок: HTML открывается в браузере мгновенно, правки делаются быстро, и только когда всё ок — Playwright делает финальный скриншот в PDF. По этой схеме ежемесячный отчёт клиенту занимает 30 минут вместо дня.

Промпт целиком (скопировать):

Собери {тип_документа} для {получатель} за {период}.

Используй структуру из {~/brain/memory/project-name.md}.
Источники данных: {источник_1}, {источник_2}.

Формат вывода: HTML-файл в {~/brain/reports/filename.html}.
Требования к HTML:
— шрифт Inter или system-ui
— тёмная тема: фон #0F172A, текст #F1F5F9
— таблицы с border-collapse, цифры в mono-шрифте
— графики: Recharts или Chart.js (inline, без внешних зависимостей)
— весь CSS inline или в <style> в head

НЕ делай PDF — только HTML на ревью.
После моего «ок» дам команду на конвертацию.

———
Второй промпт (после ревью):
Конвертируй {~/brain/reports/filename.html} в PDF через Playwright.
SCALE=3. Сохрани в {~/brain/reports/filename.pdf}.

Пример вывода Claude:

Файл создан: ~/brain/reports/client-m-may-2026.html

Содержимое:
— Сводка: 4 KPI-карточки (AUM, PnL, Yield, Drawdown) с дельтами к прошлому месяцу
— Секция «Позиции»: таблица 12 строк (протокол / сеть / размер / APY / PnL)
— Секция «PnL»: line chart за 30 дней (Chart.js, данные inline)
— Секция «Ребалансировка»: 3 рекомендации с обоснованием
— Секция «Риски»: 2 предупреждения по концентрации в ETH

Открой в браузере для ревью. Жду «ок» для PDF.

Когда применять:

• Ежемесячные отчёты клиентам (финансы, аналитика, KPI)
• Презентации для встреч и питчей (структура + данные)
• Брифы, технические документы, спецификации с таблицами и графиками
• Любой документ, который нужно отправить или распечатать

Вариации:

1. Шаблонный отчёт с live-данными: «Прочитай шаблон из {template.html}. Подставь данные из {Postgres: SELECT * FROM monthly_stats WHERE month='2026-05'}. Верни заполненный HTML с сохранением стилей шаблона.» — когда структура зафиксирована, меняются только данные.
2. Презентация со слайдами: «Создай HTML-презентацию из {brief.md}: каждый H2 — отдельный слайд. Используй Reveal.js (CDN). Размер слайда 1920×1080, тёмная тема. Только HTML для ревью.» — для питчей и онлайн-встреч.
3. Диффовый апдейт: «Прочитай существующий {report.html}. Обнови только секцию ‘Позиции’ — замени данные на свежие из {data.json}. Остальное не трогай.» — для регулярных апдейтов без пересборки с нуля.

Claude не помнит предыдущие сессии. Но если один раз сохранить структуру задачи в memory-файл — он подхватывает её при следующем старте без объяснений.

Каждый раз объяснять Claude стек, структуру данных, предпочтения по формату и специфику клиента — это потерянные минуты, которые складываются в часы. Memory-файлы решают это системно. Один раз тратишь 10 минут на описание — потом просто говоришь «собери отчёт за май» и не объясняешь ничего. CC читает memory-файл автоматически в начале следующей сессии. Это не хак — это нативная фича CC через CLAUDE.md и /memory команду.

Промпт целиком (скопировать):

Запомни рабочую структуру для задачи «{название_задачи}»:

КОНТЕКСТ:
— Проект: {название}
— Клиент / получатель: {кто}
— Цель задачи: {что нужно делать регулярно}

СТРУКТУРА ВЫВОДА:
— Секции: {раздел_1} / {раздел_2} / {раздел_3}
— Формат: {HTML / PDF / JSON / Telegram-message}
— Визуализация: {тип графиков, цветовая схема}

ИСТОЧНИКИ ДАННЫХ:
— {источник_1}: {как подключиться, какой запрос}
— {источник_2}: {endpoint / query}

ТЕХНИЧЕСКИЙ СТЕК:
— {язык, фреймворк, специфика}
— Финальный шаг: {что делать в конце}

ОГРАНИЧЕНИЯ:
— {что нельзя делать или изменять}

Сохрани в {~/brain/memory/task-name.md}.
При следующем старте читай оттуда — не спрашивай заново.
Подтверди: выведи содержимое файла после сохранения.

Пример вывода Claude:

Файл создан: ~/brain/memory/client-m-report.md

Содержимое:
# Клиент М — Ежемесячный отчёт

## Контекст
Проект: DeFiCap. Получатель: клиент М (приватное управление). Цель: ежемесячный
DeFi-отчёт с P&L, позициями и рекомендациями.

## Структура
Секции: Сводка / Позиции / PnL / Ребалансировка / Рекомендации
Формат вывода: HTML → Playwright SCALE=3 → PDF

## Источники
DeBank API: GET /user/portfolio?id={wallet_address}
Dune: query #4821 (monthly_pnl_by_protocol)

Файл сохранён. Читаю его при следующем старте. Готов к работе.

Когда применять:

• После первой сборки отчёта или документа, который будет повторяться
• После настройки нового агента или сервиса — зафиксировать архитектуру
• После онбординга в новый проект — записать ключевые особенности кодовой базы
• После решения нетривиальной задачи — записать подход для следующего раза

Вариации:

1. CLAUDE.md для проекта: вместо ~/brain/memory/ создай .claude/CLAUDE.md в корне репозитория. CC читает его в начале каждой сессии в этой директории автоматически. Пиши туда: стек, соглашения, команды деплоя, специфику — всё что Claude не может угадать из кода. /init генерирует стартовый файл.
2. Skill-файл для повторяемого workflow: создай .claude/skills/monthly-report/SKILL.md с описанием всего процесса (шаги 1-5, источники, финальный шаг). Вызывай: /monthly-report. Это то же самое, что memory-файл, но оформлено как команда CC с автовызовом по релевантности.
3. Глобальная память: сохраняй в ~/.claude/CLAUDE.md то, что применимо ко всем проектам — стиль кода, предпочтения по языку, личные правила («никогда не коммить без тестов»). Читается при каждой сессии в любой директории.

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

Большинство архитектурных решений принимается интуитивно: «сделаю быстро, потом перепишу». Потом — не наступает никогда. Или наступает в самый неподходящий момент. Этот промпт заставляет вывести стоимость каждого варианта до реализации. Не «какой лучше» — а «что получишь и от чего откажешься в каждом случае». Иногда минимальный вариант окупается. Иногда его технический долг дороже правильной реализации с первого раза. Разница в том, что теперь ты знаешь это заранее.

Промпт целиком (скопировать):

Задача: {описание задачи в 2-3 предложениях}.
Контекст: {текущий стек, ограничения, размер команды, горизонт}.

Опиши два подхода к реализации:

1. МИНИМАЛЬНЫЙ — работает прямо сейчас:
   — Минимум кода и зависимостей
   — Быстрый старт (часы, не дни)
   — Что будет сломано или ограничено

2. ПОЛНОЦЕННЫЙ — правильная архитектура:
   — Масштабируется при росте нагрузки в 10x
   — Соответствует лучшим практикам
   — Что потребует времени и ресурсов

Для каждого подхода укажи:
— Примерное время реализации
— Технический долг (что придётся переписывать и когда)
— Что сломается при росте нагрузки / пользователей / данных
— Конкретный первый шаг к реализации

Не пиши код. Только сравнение.
Завершение: рекомендация — какой вариант взять при {моих_условиях}.

Пример вывода Claude:

МИНИМАЛЬНЫЙ — SQLite + cron-скрипт на Python:
Время: 3-4 часа. Работает с первого дня.
Технический долг: при >50 параллельных запросов SQLite начинает блокировать
записи. Переписывать через 2-3 месяца при росте пользователей.
Что сломается при 10x: concurrent writes, нет миграций, нет retry.
Первый шаг: pip install schedule, создать tasks.db.

ПОЛНОЦЕННЫЙ — Postgres + FastAPI + Celery + Redis:
Время: 2-3 дня включая настройку инфраструктуры.
Технический долг: минимальный. Этот стек выдержит 100x.
Что сломается при 10x: ничего критичного, только нужен горизонтальный скейл.
Первый шаг: docker-compose up с postgres + redis.

РЕКОМЕНДАЦИЯ для твоих условий (MVP, один разработчик, 3 месяца до product-fit):
Минимальный — с условием: заложи абстракцию над БД с первого дня.
Когда придёт время мигрировать — замена займёт день, не неделю.

Когда применять:

• Выбор технологии или стека для нового сервиса
• Интеграция с внешним API: простой webhook vs полноценный event-bus
• Архитектура хранилища данных: flat files vs structured DB vs data lake
• Любое решение с явным trade-off между скоростью запуска и долгосрочной стоимостью

Вариации:

1. Три варианта вместо двух: добавь «3. ИДЕАЛЬНЫЙ — если бы не было ограничений». Используй для понимания gap между текущим и best-in-class. Полезно для технических roadmap-сессий.
2. Сравнение вендоров или инструментов: «Сравни {инструмент A} vs {инструмент B} для задачи {задача}. Для каждого: цена, ограничения, lock-in, время миграции обратно.» — для выбора SaaS или библиотеки.
3. Ретроспективный анализ: «Мы выбрали минимальный вариант 6 месяцев назад. Прочитай текущий код в {path/}. Оцени: насколько близко к тому, когда минимальный вариант начнёт стоить дороже рефакторинга?» — для планирования технического долга.

Мои 5 промптов — результат полугода итераций. Они работают для моих задач: DeFi-аналитика, агенты, отчёты, код ревью. Твои задачи другие — значит, твои промпты тоже будут другими. Но механика выявления одна.

Вот 7 шагов, которые помогут найти свои личные топ-5 за 30 дней. Не теория — реальный процесс, который привёл меня к этим пяти формулировкам. Можешь повторить.

7 шагов методики:

1. Веди лог итераций. После каждой сессии CC добавляй одну строку в ~/brain/memory/prompt-log.md: дата, задача, промпт который сработал (или не сработал). Не оценки — факты. «05.21 — ревью кода — сработало: добавил “не переписывай”». Через 2 недели увидишь паттерны.
2. Запускай /insights еженедельно. Команда /insights генерирует отчёт по твоим сессиям CC: паттерны, точки трения, что ты повторяешь чаще всего. Читай и выписывай топ-3 повторяющихся задачи.
3. Отмечай «дорогие» переделки. Каждый раз, когда приходится переделывать (Claude понял не так, пришлось уточнять >2 раз) — записывай. Это места, где нужен более точный промпт-шаблон. Переделки = сигнал к созданию нового промпта.
4. Превращай хорошие промпты в slash-команды. Когда промпт сработал чисто 3+ раза — перенеси в .claude/skills/{task-name}/SKILL.md. Теперь это /task-name. Не нужно помнить точную формулировку — достаточно имени. Skills вызываются через имя и применяются автоматически по релевантности.
5. Используй /memory для системной документации. После каждого месяца запускай /memory — это откроет редактор CLAUDE.md. Добавляй выявленные паттерны: «всегда добавляй “не переписывай код”», «для отчётов сначала HTML». Это накапливается — через 3 месяца CC начинает делать правильно без дополнительных инструкций.
6. Тестируй вариации. Берёшь рабочий промпт — и намеренно меняешь одну переменную: формулировку задачи, уровень детализации, добавляешь или убираешь ограничения. Сравниваешь выходы. За месяц такого тестирования находишь формулировки, которые работают лучше исходных.
7. Проводи ретроспективу раз в месяц. 30 минут: открываешь prompt-log.md, смотришь на /insights, спрашиваешь CC: «Прочитай ~/brain/memory/prompt-log.md. Выяви 5 задач, которые я решаю чаще всего. Предложи улучшенные шаблоны промптов для каждой.» CC делает ретроспективу за тебя.

Промпты — это что ты говоришь CC. Команды — это как CC работает. Большинство пользователей знает 2-3 из них. Те, кто знает все 7, работают иначе: сессии не замусориваются, контекст не теряется, задачи продолжаются через дни.

Все команды актуальны для CC v2.1+ (май 2026). Команды меняются быстро — держи /release-notes под рукой.

Команды и когда они нужны:

• /memory — редактировать постоянную память. Открывает редактор CLAUDE.md-файлов и auto-memory записи. Используй когда хочешь зафиксировать паттерн навсегда: стиль кода, предпочтения, специфику проекта. Изменения применяются ко всем следующим сессиям. Когда нужна: после выявления нового рабочего паттерна, после онбординга в проект.
• /resume — вернуться к прошлой сессии. Открывает picker всех сохранённых сессий с именами. Начиная с v2.1.144 в списке видны и фоновые агенты (помечены bg). Сессии именуй через /rename oauth-migration, weekly-report — находишь по имени, не по дате. Когда нужна: многодневные задачи, возврат к незавершённому проекту.
• /compact — сжать контекст без потери состояния. Суммирует историю разговора в краткий конспект, освобождает контекстное окно. В отличие от /clear — не сбрасывает сессию, а продолжает её. Принимает инструкции: /compact Focus on the auth module changes. Когда нужна: длинные сессии (>1 часа), когда контекст заполняется, перед тяжёлой задачей в конце длинной сессии.
• /agents — управлять субагентами. Открывает менеджер конфигураций субагентов. Показывает N running — сколько субагентов работает прямо сейчас. Оттуда же редактируются .claude/agents/*.md файлы. Когда нужна: перед параллельными задачами, при создании специализированных субагентов-ролей.
• /plan — войти в режим планирования. В plan mode CC читает файлы и отвечает на вопросы, но не делает изменений. Идеально для фазы Explore + Plan перед крупным изменением. Ctrl+G открывает план в текстовом редакторе для правки до реализации. Это официальная рекомендация Anthropic: Explore → Plan → Implement → Commit. Когда нужна: перед любым изменением в нескольких файлах, перед незнакомым кодом.
• /clear — сбросить контекст, начать чисто. Сбрасывает разговор, но project memory (CLAUDE.md) остаётся. Предыдущая сессия доступна через /resume. Если CC начал делать одно и то же неправильно >2 раз — это сигнал: нужен /clear с более точным промптом. Когда нужна: между несвязанными задачами, после 2+ неудачных итераций на одном месте.
• /btw — задать вопрос без засорения истории. /btw question — задать быстрый вопрос так, чтобы ответ не попал в историю разговора. Это показывает ответ в overlay, не засоряя контекст. Когда нужна: уточняющие вопросы в середине задачи, когда не хочется ломать поток.
• /insights — анализ истории твоих сессий. Генерирует отчёт по паттернам: что ты делал часто, где спотыкался, какие задачи занимали больше всего времени. Основной инструмент для выявления личных топ-5 промптов (см. секцию 6). Когда нужна: еженедельно или после крупного спринта, при ретроспективе.

• Час в день × 30 дней = 30 часов. Полная рабочая неделя возвращается тебе. Это не теория — это математика использования каждый день
• Качество без падения: промпт «задай вопросы до старта» + промпт «найди косяки до фичи» убирают большинство переделок в источнике
• Параллельность: Task tool с субагентами меняет само уравнение времени — не быстрее, а иначе
• Накопительный эффект: memory-файлы и skills работают как сложный процент — каждый месяц CC требует меньше объяснений
• Архитектурные решения: промпт «сравни два подхода» переводит выбор из интуиции в анализ
• Код без слепых пятен: ревью до фичи, а не после дебага в проде
• Система, не инструмент: 5 промптов + 7 команд + методика = рабочий процесс, который улучшается с каждым месяцем

Где хранить промпты. Три уровня.

~/.claude/CLAUDE.md — глобальные предпочтения, работают в каждой сессии, в любой директории. Сюда: стиль кода, язык ответов, личные правила («никогда не коммить без тестов»).

.claude/CLAUDE.md в корне проекта — специфика проекта: стек, команды деплоя, соглашения, особенности. Кладётся в git, разделяется с командой.

.claude/skills/{name}/SKILL.md — повторяемые процедуры как именованные команды: /monthly-report, /security-review, /release-notes. Вызываются явно или применяются автоматически по релевантности. Это место для превращённых в команды промптов, которые доказали свою ценность.

Правило разделения: если применяется всегда → CLAUDE.md. Если применяется только к этому проекту → локальный CLAUDE.md. Если применяется к конкретной процедуре → skill.