Промпты для Claude Code: 10 готовых под твою задачу

Как понять, что роль сработала, а не просто прочиталась

Три признака, по которым видно разницу, и все три видны в первом же ответе.

Setting a role in the system prompt focuses Claude's behavior and tone for your use case. Even a single sentence makes a difference.
Дословно из документации Anthropic про системный промпт: роль в системном промпте фокусирует поведение и тон под твою задачу, и разницу делает даже одно предложение

Первый: ответ начинается не с кода, а с разбора. Помощник пересказывает своими словами, что понял, и только потом переходит к делу. Второй: в ответе появляются вопросы к тебе, и он честно останавливается, пока ты не ответишь. Третий: вместе с решением приходит список того, что он проверил вокруг задачи, а не одна правка.

Если ответ пришёл сразу файлами и без единого вопроса, роль не подействовала. Чаще всего дело в том, что промпт ушёл отдельным сообщением, а задача следующим: вставляй их вместе, одним сообщением. Отдельный разбор, почему помощник понимает задачу не так, у меня уже есть.

Что роль меняет на самом деле, честно. Я взял файл на шестнадцать строк с одним заложенным дефектом: таблица промокодов хранит проценты, а код вычитает их как единицы валюты, поэтому корзина печатает 5680 вместо 4860. И задал по нему два вопроса подряд.

Замер 21.09.2026, macOS, модель sonnet, режим плана: файл на 16 строк, один и тот же дефект. Голый вопрос «Найди баг в файле korzina.py» - 44 секунды, причина названа верно, правка одной строкой. Тот же файл с промптом номер 3 - 146 секунд, та же причина плюс шесть крайних случаев и проверка «должен вывести 4560.00».

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

Проекта ещё нет, есть только идея

Два промпта на старте. Первый собирает всё сразу, второй берёт на себя только невидимую часть - ту, где хранятся данные.

Промпт 1. Приложение с нуля. Вставь перед описанием своей идеи:

Действуй как старший фулстек-инженер, который собирает готовый к продакшену MVP стартапа с нуля.

Сначала спроектируй полную архитектуру системы, потом собери самую простую, но масштабируемую версию.

Включи:
• Архитектуру системы
• Структуру файлов
• Схему базы данных
• API-эндпоинты
• Архитектуру интерфейса
• Готовый к продакшену код

Что делает: рисует устройство будущего приложения целиком (какие части, какие файлы, где хранятся данные), а потом пишет самую простую рабочую версию.

Когда звать: у тебя есть идея и пустая папка, и ты не знаешь, с какого файла начинать. MVP тут это первая версия, в которой работает только главное, а продакшен это состояние «этим уже можно пользоваться людям».

Промпт 6. Невидимая часть приложения. Вставь и допиши, что там должно храниться:

Действуй как старший системный архитектор, который проектирует инфраструктуру для быстрорастущего стартапа.

Сначала спроектируй масштабируемую архитектуру системы продакшен-уровня. Затем собери минимальную реализацию, которая реально сможет вырасти в будущем.

Включи:
• Архитектуру системы
• Структуру компонентов
• Поток данных
• Дизайн API
• Схему базы данных
• Стратегию кеширования
• Готовый к продакшену код

Что делает: проектирует изнанку приложения - где живут данные, как они ходят между частями и что запоминать заранее, чтобы не считать дважды.

Когда звать: экран уже есть или он не главное, а тебе нужно хранилище, вход по паролю и обмен данными между частями.

Код уже есть, и разбираться в нём некому

Тоже два, и они про разное: первый смотрит и рассказывает, второй переставляет.

Промпт 2. Осмотр чужого проекта. Вставь и назови папку проекта:

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

Затем найди:
• Плохие архитектурные решения
• Дублирующуюся логику
• Узкие места по скорости
• Риски при росте
• Проблемы с поддержкой

В конце дай:
• Понятный разбор архитектуры
• Критичные проблемные места
• Стратегии рефакторинга
• Улучшенный код продакшен-уровня

Не меняй работу программы.

Только подними качество кода, его способность расти и удобство поддержки.

Что делает: читает проект как новый сотрудник в первый день и отдаёт карту: из чего собрано, что повторяется дважды, что развалится при росте.

Когда звать: тебе достался чужой проект, или свой, но полугодовой давности. Строка «не меняй работу программы» тут ключевая: она запрещает помощнику чинить на ходу.

Промпт 5. Пересборка запутанного кода. Вставь и назови файлы, которые больно трогать:

Действуй как старший архитектор ПО, который пересобирает запутанный код на проде по принципам чистой архитектуры.

Твоя миссия:
• Правильно разделить ответственность
• Повысить модульность
• Уменьшить жёсткую связанность
• Улучшить способность расти
• Сделать код проще в поддержке надолго

Не меняй поведение продукта. Только улучши архитектуру и качество кода.

В конце дай:
• Новую структуру папок
• Понятный разбор архитектуры
• Переписанный готовый к продакшену код
• Объяснение, что улучшилось в архитектуре

Что делает: раскладывает кашу по полкам - разносит куски по папкам так, чтобы правка в одном месте не ломала три других.

Когда звать: всё работает, но любое изменение стало страшным. Рефакторинг это и есть перестановка без смены поведения: снаружи ничего не поменялось, внутри стало понятнее.

Что-то сломалось, и непонятно почему

Промпт 3. Поиск причины сбоя. Вставь и назови файл, в котором сломалось:

Действуй как старший инженер по отладке, который разбирает живую проблему на проде. Анализируй код шаг за шагом, будто чинишь критичный сбой в быстрорастущем стартапе. Твоя задача:

• Понять, что код делает на самом деле
• Найти настоящую корневую причину
• Объяснить, почему случается сбой
• Найти скрытые крайние случаи
• Предложить самое надёжное решение

В конце дай:
• Разбор работы кода
• Анализ корневой причины
• Объяснение сбоя
• Анализ крайних случаев
• Исправленный готовый к продакшену код

Не угадывай. Думай глубоко, прежде чем что-то менять.

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

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

Это тот самый промпт, на котором я снимал замер выше. Обязательно называй ему файл: без имени файла он пойдёт читать весь проект, и ответ станет дороже и дольше.

Работает, но медленно

Промпт 4. Скорость. Вставь и скажи, что именно тормозит:

Действуй как старший инженер по производительности, который ускоряет приложение на проде с миллионами пользователей.

Твои цели:
• Максимальная скорость
• Меньше расхода памяти
• Лучшая способность расти
• Быстрее отрисовка
• Чище исполнение

Внимательно найди:
• Узкие места по скорости
• Неэффективную логику
• Лишнюю отрисовку
• Дорогие операции
• Утечки памяти

Затем дай:
• Разбор проблем со скоростью
• Стратегии оптимизации
• Улучшенный готовый к продакшену код
• Рекомендации по росту

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

Когда звать: страница думает несколько секунд, список тормозит при прокрутке, приложение разогревает ноутбук. Утечка памяти это когда программа берёт память и не отдаёт обратно, и через час работы её не остаётся.

Нужен экран, который увидят люди

Промпт 7. Экран для людей. Вставь и опиши экран словами:

Действуй как старший фронтенд-инженер, который строит интерфейсы продакшен-уровня для современного стартапа.

Твоя задача - создать:
• Переиспользуемые UI-компоненты
• Масштабируемую архитектуру компонентов
• Доступные готовые к продакшену интерфейсы

В процессе аккуратно учти:
• Состояния загрузки
• Пустые состояния
• Крайние случаи
• Адаптивность под разные экраны
• Доступность
• Переиспользуемость компонентов
• Удобство для разработчика

В конце дай:
• Архитектуру компонентов
• Дизайн пропсов и API
• Готовую к продакшену реализацию
• Примеры использования
• Лучшие практики

Что делает: собирает видимую часть из повторно используемых кусков и сразу закрывает состояния, о которых обычно забывают: пока грузится, когда пусто, когда экран узкий.

Когда звать: делаешь страницу или экран приложения. Самое ценное здесь строки про состояние загрузки и пустое состояние: без них интерфейс выглядит сломанным ровно в тот момент, когда его впервые открывает живой человек.

Скоро показывать людям

Два промпта перед тем, как выложить наружу.

Промпт 9. Проверка на дыры. Вставь перед тем, как выкладывать:

Действуй как старший инженер по безопасности, который проверяет приложение на проде.

Внимательно проверь систему на:
• Уязвимости в безопасности
• Дыры в авторизации
• Слабые места в API
• Риски инъекций
• Утечки чувствительных данных
• Риски в инфраструктуре

Затем дай:
• Отчёт по уязвимостям
• Уровни критичности
• Сценарии атак
• Безопасные исправления
• Рекомендации продакшен-уровня

Что делает: смотрит на твой проект глазами того, кто хочет в него залезть, и отдаёт список дыр с оценкой, насколько каждая опасна.

Когда звать: до того, как выложил в интернет, а не после. Особенно если там есть вход по паролю, форма или чужие данные. Про то, какие дыры находят у ИИ-помощников, у меня есть отдельный разбор.

Промпт 10. Выкладка наружу. Вставь и назови, где будет жить проект:

Действуй как старший DevOps-инженер, который готовит приложение к реальному запуску на проде.

Твоя задача:
• Спроектировать архитектуру деплоя
• Настроить CI/CD
• Поднять мониторинг и логирование
• Повысить надёжность
• Снизить риски простоя
• Оптимизировать рост

Дай:
• Архитектуру инфраструктуры
• Процесс деплоя
• Пайплайн CI/CD
• Настройку Docker/Kubernetes
• Стратегию мониторинга
• Чек-лист запуска в продакшен

Что делает: описывает дорогу от твоей папки на компьютере до живого адреса в интернете и настраивает автоматическую выкладку новых версий.

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

Вставлять руками каждый раз не нужно

Любой из десяти можно превратить в собственную команду. Создай в папке проекта папку .claude, внутри неё папку commands, а в ней текстовый файл с именем будущей команды, например otladka.md. Вставь в файл тело промпта, а последней строкой допиши:

Разбери файл: $ARGUMENTS

Сохрани, вернись в Claude Code и набери:

/otladka korzina.py

Помощник подставит имя файла вместо $ARGUMENTS и отработает по твоему промпту. Так десять заготовок превращаются в десять коротких команд, и каждый раз искать эту страницу не придётся.

Проверил на том же файле: промпт, положенный в файл команды, отработал за 180 секунд и вернул разбор того же состава, что и вставленный руками.

Если правило нужно не под задачу, а навсегда и для всех сессий, ему место не в промпте, а в файле правил проекта: промпт живёт до конца разговора, файл правил читается каждый раз.

Что ломается, когда вставляешь такой промпт

Четыре ловушки, на которые я наступал сам.

Помощник уходит переписывать полпроекта. Восемь промптов из десяти содержат строку про готовый к продакшену код, и на мелкой правке она разворачивает работу на час. Лечится одной фразой в конце: «менять только файл такой-то, остальное не трогать». Почему помощник вообще пишет лишнее, разбирал отдельно.

Ответ идёт втрое дольше. Это не сбой, это цена роли: помощник обходит больше случаев. На однострочной правке промпт лучше не звать вовсе.

Промпт ушёл без задачи. Если вставить только роль и нажать Enter, придёт вежливый вопрос, что делать. Роль и задача идут одним сообщением.

Помощник молча начал править файлы. Если хочешь сначала посмотреть план, включи режим плана: в документации он описан как состояние, в котором помощник читает файлы и предлагает план, но ничего не меняет на диске до твоего подтверждения. В строке состояния при этом видна пометка режима плана.

Отдельная развилка: если тебя не устраивает не результат, а сама формулировка, и хочется переписать промпт под себя, это другая работа и другой разбор - как из слабого запроса сделать сильный.

Десять промптов одним списком, чтобы видеть набор целиком.

Источники

Все страницы открыты живым запросом 21 сентября 2026 года; числа о времени ответа сняты собственным прогоном на своём файле, а не переписаны из чужих обзоров

• Документация Anthropic: роль в системном запросе - дословно: даже одно предложение роли меняет поведение модели
• Инженерный блог Anthropic про работу в Claude Code - почему разведение планирования и написания кода экономит переделки, четыре фазы работы
• Документация Claude Code: типовые сценарии - режим плана, что помощник читает файлы и ничего не меняет до подтверждения
• Документация Claude Code: команды из файла - файл в папке команд превращается в команду, подстановка аргумента
• Документация Claude Code: справочник запуска - одиночный вопрос без диалога, выбор модели, режим прав
• Собственный прогон 21 сентября 2026 года на macOS: один файл, два вопроса, замер времени ответа и состава разбора

Памятка: какой промпт под какую ситуацию

Десять строк, которые удобнее держать открытыми, чем листать эту страницу заново

Частые вопросы