11 промтов для Claude Code, которые я гоняю каждый день

Я хочу построить новую фичу или продукт. Сначала спроси у меня в одном предложении, что именно я хочу сделать. Затем проинтервьюируй меня детально через инструмент AskUserQuestion: техническая реализация, UX, edge-кейсы, риски, tradeoffs. Не задавай очевидных вопросов — копай в сложное, что я мог упустить. Задавай вопросы по одному, не списком. Продолжай интервью, пока не покроем всё важное. В конце запиши полный спек в SPEC.md: цель, требования, ограничения, открытые вопросы, критерии приёмки. После этого я открою новую сессию для реализации.

Прежде чем что-либо делать с задачей, которую я только что описал — отправь subagent на исследование кодобазы. Subagent должен: (1) найти все релевантные файлы и точки входа; (2) понять текущую архитектуру и потоки данных вокруг затронутой области; (3) выявить существующие паттерны, утилиты и абстракции, которые можно переиспользовать вместо написания нового; (4) перечислить риски, неясности и зависимости; (5) вернуть краткий отчёт с конкретными ссылками на файлы и строки. Не редактируй файлы. Не пиши длинные пересказы кода — только структурированные выводы. Если из моего сообщения непонятно, что исследовать — задай один уточняющий вопрос и жди ответ.

Прежде чем писать код, составь детальный план для задачи, которую я обсуждаю выше. План должен включать: (1) цель и критерий «готово»; (2) изменяемые файлы с пояснениями зачем; (3) поток данных и архитектурные решения; (4) edge-кейсы и обработка ошибок; (5) как будем проверять, что работает — конкретные тесты, команды, ожидаемый вывод; (6) открытые вопросы и риски.

Если требования неясны — задай уточняющие вопросы через AskUserQuestion прежде чем писать план. Если задача в чате не описана — попроси описать. Не упрощай задачу, не делай заглушек. План должен быть достаточно конкретным, чтобы по нему можно было реализовать без догадок. Жди моего одобрения плана прежде чем переходить к коду.

Реализуй план шаг за шагом. Требования:

(1) Следуй плану последовательно. Если отклоняешься — отметь и обоснуй.
(2) Пиши рабочий production-код. Никаких заглушек, placeholder-ов, TODO в основном пути.
(3) Лечи root cause, а не симптомы. Не глуши ошибки try/catch-ом «чтобы прошло» — обрабатывай осознанно.
(4) После каждого логического шага — верифицируй: запусти тест, выполни команду, проверь вывод. Если запустить нечего — скажи это явно, не делай вид, что проверил.
(5) Если упёрся в неожиданность или план требует пересмотра — остановись и обсуди.

В конце дай краткий отчёт: что сделано, чем проверено, что осталось.

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

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

LARP-проверка: критически проверь, реальный ли это код или «изображает работу». Ищи:

(1) Заглушки, возвращающие фейковые данные.
(2) Hardcode, притворяющийся динамикой.
(3) Тесты, которые мокают именно ту логику, которую должны проверять.
(4) Ошибки, которые молча глушатся (пустой except, catch без обработки, проглоченные Promise).
(5) async-функции без await там, где результат нужен.
(6) «Валидацию», которая ничего не валидирует.
(7) Условия, которые никогда не срабатывают (мёртвые ветки).
(8) Кэши, которые никогда не инвалидируются.
(9) Метрики и логи, которые никуда не пишутся.

Отчитайся честно. Если что-то выглядит рабочим, но не доказано запуском — пометь как «не подтверждено». После обзора немедленно исправляй проблемы по списку, от самой опасной к самой мелкой. Веди TODO.

Убери AI-мусор и over-engineering. Удали:

(1) Ненужные абстракции и обёртки на одно использование.
(2) Многословные комментарии-пересказы кода («// возвращаем результат»).
(3) Защитный код для невозможных случаев (null-проверки там, где значение гарантировано типом).
(4) Слишком общие решения для частной задачи.
(5) Лишние валидации на внутренних границах, где данные уже доверенные.
(6) Enterprise-паттерны (фабрики, регистры, DI-контейнеры) в простых скриптах.
(7) Размазанные логи «для отладки», которые остались с разработки.
(8) Эмодзи и пустые формулировки в комментариях.

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

Расширь покрытие тестами за пределы happy path. Покрой:

(1) Граничные условия (пустой вход, максимальный размер, ноль, отрицательные числа).
(2) Ошибки и невалидные входы.
(3) Интеграции с реальными зависимостями (БД, файловая система) — не мокай свою логику.
(4) Конкуренцию и асинхронность, если есть.
(5) Проверку фактических данных и побочных эффектов, а не только возвращаемых значений.

Правило по мокам: моки допустимы на границах системы (внешние API, текущее время, random), но не внутри своей логики. Если ловишь себя на моке проверяемого модуля — тест бесполезен.

Запусти весь тест-набор. Покажи список новых тестов и что упало.

Проход по качеству кода. Отрефактори:

(1) Компактность — убери дубли, объедини похожие блоки.
(2) Лаконичность — упрости логику, замени циклы на идиоматичные конструкции языка.
(3) Чистота — единый нейминг, согласованная структура, одинаковый стиль на всех уровнях.
(4) Надёжность — обработка edge-кейсов в одном стиле.
(5) Читаемость — функции делают одно дело, имена объясняют намерение.

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

Сделай независимое code review последних изменений. Сначала через git определи, что ревьюим: незакоммиченные правки (git diff), последний коммит (git show HEAD), или текущая ветка против main (git diff main...HEAD) — выбери самое осмысленное. Не делай предположений о замысле автора — анализируй сам код.

Проверь:
(1) Реально ли работает то, что заявлено? Что покажет запуск?
(2) Решает ли это исходную задачу полностью или есть пропущенные кейсы?
(3) Race conditions, утечки ресурсов, проблемы конкуренции.
(4) Безопасность: injection, утечки секретов, проверка входов на границе.
(5) Согласованность с существующими паттернами кодобазы.
(6) Что может сломаться в проде через месяц.

Дай честный фидбек: критичное / важное / nice-to-have. По каждому пункту — конкретная ссылка на файл:строку.

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

(1) Все тесты проходят при реальном выполнении (не «должны проходить»).
(2) Линтер и тайпчекер чистые.
(3) Ошибки обрабатываются и логируются с контекстом.
(4) Конфиг вынесен в env. Никаких секретов в коде.
(5) Производительность приемлемая — нет N+1, нет очевидных утечек.
(6) Зависимости закреплены и проверены на уязвимости.
(7) Есть план отката (миграции обратимы, флаги доступны).
(8) Мониторинг и алерты настроены на ключевые метрики.
(9) Документация обновлена (README, CHANGELOG, миграционные заметки).
(10) Feature flag, если фича рискованная.

Если что-то не выполнено — создай TODO и закрой по списку. Не объявляй готовым, пока не закрыты все пункты.

Закрой всё оставшееся. Процесс:

(1) Перечисли все открытые вопросы: баги, FIXME/TODO, пропущенные тесты, предупреждения линтера, заблокированные пункты из прошлых сессий.
(2) Расставь приоритеты: блокеры → важное → nice-to-have.
(3) Закрывай по одному, полностью. После каждого — реальный запуск, реальный тест.
(4) После каждого фикса прогоняй полный тест-набор, чтобы поймать регрессии.
(5) Не объявляй завершение, пока список не пуст.

Итог: список закрытого со ссылками на коммиты/файлы и список того, что осознанно отложено с причиной.