Лучшие промпты для Claude Code: 25 примеров для программирования

Claude Code умеет не только дописывать отдельные функции. Его можно использовать для анализа большого проекта, поиска багов, рефакторинга, написания тестов, работы с Git, оптимизации производительности и реализации новых функций сразу в существующем коде.

Но качество результата сильно зависит от запроса. Фраза вроде «исправь код» почти всегда уступает промпту, в котором указаны задача, ограничения, контекст проекта и критерии готовности.

Ниже собраны лучшие промпты для Claude Code, которые можно копировать и адаптировать под собственный проект.

Как правильно писать промпты для Claude Code

Хороший промпт обычно содержит четыре вещи:

1. Что нужно сделать
2. Какой код нужно изучить
3. Какие ограничения нельзя нарушать
4. Как проверить результат

Например, вместо:

Оптимизируй этот проект.

лучше написать:

Проанализируй проект и найди основные проблемы производительности.

Сначала изучи архитектуру и найди потенциальные bottleneck'и.
Не меняй публичные API.

После анализа:
1. перечисли найденные проблемы;
2. оцени их влияние;
3. внеси безопасные оптимизации;
4. запусти существующие тесты;
5. покажи, какие файлы были изменены и почему.

Anthropic рекомендует давать Claude ясные и прямые инструкции, добавлять необходимый контекст и явно указывать желаемый формат результата. Для сложных задач также полезно разделять инструкции и контекст структурированными блоками.

1. Анализ незнакомого проекта

Один из самых полезных сценариев Claude Code — быстро разобраться в чужой кодовой базе.

Изучи этот репозиторий и объясни его архитектуру.

Сначала ничего не изменяй.

Определи:
- основные модули;
- точки входа;
- ключевые зависимости;
- как данные проходят через систему;
- где находится бизнес-логика;
- как устроено хранение данных;
- как запускаются тесты.

После этого составь краткую карту проекта и назови 5 файлов, которые стоит изучить в первую очередь.

Такой промпт особенно полезен при подключении к новому рабочему проекту или open-source репозиторию.

2. Поиск бага

Исследуй причину этой ошибки:

[вставьте ошибку или stack trace]

Не исправляй первое подозрительное место сразу.

Сначала:
1. найди связанный код;
2. проследи поток данных;
3. сформулируй наиболее вероятную причину;
4. проверь гипотезу по коду.

После этого внеси минимальное исправление.

Не делай несвязанный рефакторинг.
После изменения запусти релевантные тесты.

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

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

3. Исправление ошибки по stack trace

Вот stack trace:

[STACK TRACE]

Найди root cause ошибки в проекте.

Не маскируй исключение try/catch, если проблема находится глубже.

Проследи вызовы до первоначального источника ошибки, исправь причину и добавь regression test, который воспроизводит проблему до исправления.

4. Code Review

Проведи code review текущих изменений.

Не редактируй файлы.

Проверь:
- потенциальные баги;
- race conditions;
- проблемы безопасности;
- неправильную обработку ошибок;
- утечки ресурсов;
- лишние запросы к БД;
- нарушения существующей архитектуры;
- проблемы производительности.

Не перечисляй косметические замечания, если они не влияют на качество кода.

Для каждой найденной проблемы укажи:
- файл и участок кода;
- почему это проблема;
- насколько она критична;
- как её исправить.

5. Реализация новой функции

Нужно реализовать следующую функцию:

[ОПИСАНИЕ]

Перед изменениями изучи существующую архитектуру и найди похожую функциональность.

Следуй уже используемым паттернам проекта.

Требования:
- не ломать обратную совместимость;
- не добавлять новые зависимости без необходимости;
- использовать существующие abstractions;
- добавить тесты;
- обновить документацию, если меняется публичное API.

После реализации запусти тесты и кратко перечисли внесённые изменения.

Такой запрос обычно работает лучше, чем подробная инструкция уровня «создай файл A, потом функцию B, затем вызови C». Современные модели Claude хорошо справляются с многошаговыми coding-задачами, поэтому полезнее дать им цель и ограничения, а не пытаться вручную прописать каждое действие.

6. Рефакторинг сложного кода

Проанализируй этот модуль и предложи рефакторинг.

Цели:
- уменьшить сложность;
- убрать дублирование;
- улучшить читаемость;
- сохранить текущее поведение.

Не меняй публичный интерфейс без крайней необходимости.

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

Затем выполни рефакторинг небольшими логическими изменениями и запусти тесты.

7. Безопасный рефакторинг большого проекта

Нужно отрефакторить [компонент].

Перед началом найди все места его использования.

Определи:
- публичные интерфейсы;
- зависимости;
- тесты;
- потенциальные скрытые зависимости.

Составь короткий план миграции.

После этого выполняй изменения постепенно, сохраняя рабочее состояние проекта после каждого этапа.

Не удаляй старый код, пока не убедишься, что он больше нигде не используется.

8. Написание unit-тестов

Изучи этот модуль и существующий стиль тестирования в проекте.

Добавь unit-тесты для наиболее важных сценариев.

Обязательно проверь:
- happy path;
- некорректный ввод;
- граничные значения;
- обработку ошибок;
- потенциально проблемные edge cases.

Не пиши тесты исключительно ради высокого coverage.

Тесты должны проверять реальное поведение системы.

9. Поиск недостающих тестов

Проанализируй реализацию и существующие тесты для [модуль].

Найди важные ветки поведения, которые сейчас не покрыты.

Особое внимание удели:
- error paths;
- concurrency;
- null/empty values;
- boundary conditions;
- внешним API;
- транзакциям;
- повторным запросам.

Сначала перечисли недостающие сценарии, затем добавь наиболее важные тесты.

10. Тесты на найденный баг

В проекте есть баг:

[ОПИСАНИЕ]

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

Убедись, что тест падает на текущей реализации.

После этого исправь код так, чтобы тест проходил.

Не изменяй сам тест после исправления, если только первоначальная проверка не была некорректной.

Это один из самых полезных промптов при работе по принципу regression testing.

11. Оптимизация производительности

Найди потенциальные проблемы производительности в [модуль].

Не оптимизируй код только на основании предположений.

Изучи:
- алгоритмическую сложность;
- повторные вычисления;
- обращения к БД;
- сетевые запросы;
- лишние allocations;
- сериализацию;
- блокировки;
- конкурентный доступ.

Раздели проблемы на:
1. вероятно критичные;
2. потенциальные;
3. микрооптимизации.

Исправляй только изменения, которые имеют понятное практическое преимущество.

12. Оптимизация SQL-запросов

Проанализируй SQL-запросы в этом модуле.

Найди:
- N+1 queries;
- отсутствующие или потенциально полезные индексы;
- лишние JOIN;
- SELECT *;
- повторяющиеся запросы;
- фильтрацию после получения данных;
- потенциально дорогие сортировки.

Для каждой проблемы объясни причину и предложи исправление.

Не предлагай индекс без объяснения, какой запрос и какое условие он ускоряет.

13. Поиск N+1

Проверь код на проблему N+1 запросов.

Проследи путь от HTTP-handler до слоя данных.

Особенно проверь запросы внутри циклов и lazy-loading связанных сущностей.

Если найдёшь N+1:
- покажи точное место;
- оцени количество запросов;
- предложи исправление;
- убедись, что результат функции не изменился.

14. Проверка безопасности

Проведи security review этого проекта.

Ничего не изменяй на первом этапе.

Проверь:
- authentication;
- authorization;
- SQL injection;
- command injection;
- XSS;
- SSRF;
- path traversal;
- небезопасную десериализацию;
- хранение секретов;
- неправильную работу с JWT/cookies;
- загрузку файлов;
- пользовательский ввод.

Отделяй реальные уязвимости от теоретических.

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

15. Проверка API

Проанализируй API этого сервиса.

Проверь:
- корректность HTTP status codes;
- validation;
- authentication;
- authorization;
- idempotency;
- pagination;
- error responses;
- backward compatibility;
- обработку timeout;
- rate limiting.

Найди места, где поведение API может быть неожиданным для клиента.

16. Создание REST API

Добавь REST API для [сущность].

Используй существующий framework и архитектуру проекта.

Нужно реализовать:
- создание;
- получение;
- обновление;
- удаление;
- validation;
- корректные HTTP-коды;
- обработку ошибок.

Не дублируй существующую бизнес-логику в handler.

Добавь тесты API и обнови документацию.

17. Работа с legacy-кодом

Нужно изменить legacy-модуль:

[ЗАДАЧА]

Предположи, что существующее странное поведение может быть намеренным.

Перед изменением:
- изучи вызовы модуля;
- найди тесты;
- найди неявные зависимости;
- определи публичное поведение.

Внеси минимально необходимое изменение.

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

18. Поиск dead code

Найди потенциально неиспользуемый код в проекте.

Не удаляй ничего автоматически.

Для каждого кандидата проверь:
- прямые вызовы;
- динамические вызовы;
- dependency injection;
- reflection;
- CLI entry points;
- jobs;
- tests;
- внешнее использование через public API.

Раздели результат на:
- безопасно удалить;
- вероятно не используется;
- требуется ручная проверка.

19. Миграция библиотеки или framework

Нужно обновить [библиотека] с версии [A] до [B].

Сначала изучи текущее использование библиотеки в проекте.

Определи breaking changes, которые затрагивают наш код.

Составь план миграции и затем выполни её.

Не делай несвязанный рефакторинг.

После обновления:
- собери проект;
- запусти тесты;
- проверь deprecated API;
- перечисли изменения, которые потребовались для миграции.

20. Создание Dockerfile

Изучи приложение и создай production-ready Dockerfile.

Требования:
- multi-stage build, если он имеет смысл;
- минимальный runtime image;
- запуск не от root;
- корректное кеширование dependencies;
- отсутствие секретов внутри image;
- healthcheck, если он подходит для приложения.

Также создай или обнови .dockerignore.

После этого объясни основные решения.

21. Анализ Docker-образа

Проанализируй Dockerfile и docker-compose конфигурацию.

Найди:
- лишние слои;
- проблемы кеширования;
- слишком большой image;
- секреты;
- запуск от root;
- лишние build dependencies в runtime;
- неправильные volume;
- networking issues.

Предложи изменения, но не усложняй конфигурацию без необходимости.

22. Создание документации

Изучи проект и обнови README.

README должен позволить новому разработчику:

1. понять назначение проекта;
2. установить зависимости;
3. настроить environment;
4. запустить приложение;
5. запустить тесты;
6. выполнить основные команды.

Не придумывай команды или переменные окружения.

Используй только то, что реально присутствует в репозитории.

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

23. Подготовка Pull Request

Посмотри текущий git diff и подготовь описание Pull Request.

Структура:

## Что изменено
Краткое описание.

## Зачем
Какую проблему решает изменение.

## Основные изменения
Список действительно важных изменений.

## Тестирование
Какие проверки были выполнены.

## Риски
Что потенциально может сломаться.

Не преувеличивай масштаб изменений и не упоминай то, чего нет в diff.

24. Поиск проблемы перед production deployment

Представь, что этот код завтра идёт в production.

Проведи финальную техническую проверку текущих изменений.

Ищи только проблемы, которые действительно могут привести к:
- падению;
- потере данных;
- security incident;
- неправильным результатам;
- существенной деградации производительности.

Не трать время на naming и форматирование.

Сначала покажи только найденные риски. Код пока не меняй.

25. Автономное выполнение большой задачи

Для больших задач Claude Code можно дать больше свободы:

Нужно полностью реализовать следующую задачу:

[ЗАДАЧА]

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

Работай до полного завершения задачи.

Ты можешь:
- читать необходимые файлы;
- изменять код;
- запускать тесты;
- использовать существующие инструменты проекта.

Не останавливайся после написания первого варианта.

После реализации:
1. проверь изменения;
2. запусти релевантные тесты;
3. исправь обнаруженные ошибки;
4. убедись, что задача действительно выполнена;
5. кратко опиши итог.

Для современных Claude-моделей Anthropic рекомендует явно говорить агенту, когда от него требуется именно действие, а не только предложение решения. Иначе запрос вроде «предложи изменения» может привести лишь к объяснению без редактирования файлов.

Универсальный промпт для Claude Code

Если нужен один шаблон практически для любой задачи, можно использовать такой вариант:

Задача:
[ЧТО НУЖНО СДЕЛАТЬ]

Сначала изучи релевантный код и существующую архитектуру.

Не делай предположений о файлах или поведении, которые ты не проверил.

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

Выполни задачу полностью.

После изменений:
- проверь git diff;
- запусти релевантные тесты;
- исправь ошибки;
- кратко перечисли изменённые файлы и причины изменений.

Почему короткие промпты иногда работают лучше длинных

Claude Code уже имеет доступ к репозиторию, инструментам и контексту текущей сессии. Поэтому не обязательно объяснять модели каждую строку будущей реализации.

Слишком жёсткий промпт:

Открой user.go, создай функцию X, затем открой handler.go, добавь вызов Y...

может оказаться хуже описания конечной цели:

Добавь возможность блокировать пользователя.

Изучи существующую архитектуру пользователей и реализуй функцию так, чтобы она соответствовала текущим паттернам проекта.

Добавь необходимые тесты.

Во втором случае Claude может самостоятельно обнаружить, что логика находится совсем не в тех файлах, которые предполагал разработчик.

Как уменьшить галлюцинации Claude Code

Для работы с большим проектом можно добавить постоянное правило:

Никогда не делай утверждений о коде, который ты не изучил.

Если вопрос относится к конкретному файлу, функции или компоненту, сначала найди и прочитай соответствующую реализацию.

Если информации недостаточно, исследуй проект вместо того, чтобы предполагать.

Подобный подход напрямую соответствует актуальным рекомендациям Anthropic для agentic coding: модель следует заставлять исследовать код перед выводами о его поведении.

Стоит ли просить Claude Code «думать пошагово»

Обычно в этом нет необходимости.

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

Вместо:

Думай шаг за шагом максимально подробно...

часто достаточно:

Тщательно исследуй проблему перед изменением кода.

Рассмотри несколько возможных причин и проверь их по репозиторию.

Claude Code и CLAUDE.md

Повторяющиеся инструкции нет смысла вставлять в каждый запрос.

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

Например:

# Project rules

- Go 1.26
- PostgreSQL используется как основная БД
- бизнес-логика не должна находиться в HTTP handlers
- новые dependencies добавлять только при необходимости
- после изменений запускать go test ./...
- публичные API должны сохранять backward compatibility

Так рабочие промпты становятся значительно короче.

Главный принцип хорошего промпта для Claude Code

Лучший промпт — не самый длинный.

Он должен дать Claude достаточно информации, чтобы модель понимала:

что нужно получить → что нельзя сломать → где искать информацию → как проверить результат.

Для простой задачи иногда достаточно одного предложения:

Найди причину падения этого теста и исправь её, не меняя ожидаемое поведение теста.

Для изменения архитектуры потребуется гораздо больше контекста.

Главное — не пытаться объяснить Claude Code, как именно писать каждую строку кода. Лучше точно сформулировать результат и ограничения, позволив агенту самостоятельно исследовать проект и выбрать подходящую реализацию.

Meta Title: Лучшие промпты для Claude Code: 25 примеров для программистов

Meta Description: Лучшие промпты для Claude Code для написания кода, поиска багов, рефакторинга, тестирования, Code Review, оптимизации и работы с большими проектами. 25 готовых примеров.

URL: /luchshie-prompty-claude-code/

Основные ключевые запросы: Claude Code промпты, лучшие промпты для Claude Code, Claude Code prompts, промпты для программирования, как пользоваться Claude Code.