Библиотека промптов

Ты работаешь в пустой папке. Собери проект: {стек}.
Структура: минимальная, без лишних абстракций.
Добавь README на русском и .env.example.
Не устанавливай зависимости, которых нет в задаче.

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

Продукт: {одно предложение, что он делает}.
Один главный сценарий: {описать по шагам}.
Собери каркас только под этот сценарий.
Всё остальное не реализуй, а перечисли списком
в конце как «отложено».

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

Задача: {описание}. Мои ограничения: {хостинг,
опыт, бюджет, сроки}.
Предложи три варианта стека с плюсами и минусами.
Не пиши код. В конце дай одну рекомендацию
и объясни, почему именно она.

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

Вот задача целиком: {описание}.
Разбей её на шаги так, чтобы каждый шаг
можно было проверить отдельно.
Для каждого шага укажи признак готовности.
Код не пиши.

Первый шаг любого крупного проекта: без разбивки агент делает всё сразу и посредственно.

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

Заставляет агента следовать существующим конвенциям вместо того, чтобы приносить свои.

Задача: {описание}. Стек: {…}.
Оцени: какие файлы придётся создать, какие изменить,
что может пойти не так.
Дай грубую оценку в часах для человека,
который работает с агентом. Код не пиши.

Черновая оценка перед тем, как обещать срок заказчику.

Вот ошибка: {текст ошибки}.
Сначала объясни причину словами, не правь код.
Потом предложи минимальную правку и скажи,
какие ещё места в проекте она затронет.

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

Ожидаю: {что должно происходить}.
Получаю: {что происходит на самом деле}.
Ошибок в консоли нет.
Перечисли пять возможных причин по убыванию
вероятности и скажи, как проверить каждую.
Код не правь.

Для случаев, когда ничего не падает, но работает не так.

Вот стектрейс: {вставить}.
Объясни по-русски: что произошло, в какой строке
настоящая причина, а какие строки — просто
передача ошибки выше.
Правку предложи отдельно, после объяснения.

Экономит время на длинных трейсах, где настоящая причина в середине.

Баг: {описание}. Воспроизводится примерно
в {доля} случаев.
Предположи, что может быть источником
недетерминированности: время, гонки, кэш,
внешние сервисы, порядок данных.
Предложи, как поймать это в логах.

Плавающие баги: направляет агента в сторону типовых причин вместо угадывания.

После правки {что меняли} перестало работать
{что сломалось}.
Найди связь между этими местами.
Объясни её словами. Верни рабочее поведение,
не откатывая исходную правку целиком.

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

Это место работает медленно: {файл или функция}.
Найди, что именно занимает время: запросы в базу,
циклы, обращения по сети, лишние пересчёты.
Сначала покажи анализ и цифры, потом правку.
Не оптимизируй то, что не является узким местом.

Запрет на преждевременную оптимизацию: без него агент переписывает всё подряд.

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

Основной промпт для рефакторинга. План до правок — самая ценная строка.

Файл {путь} разросся. Предложи, как разбить его
на части по зонам ответственности.
Сначала — только план: что куда переезжает.
Импорты и вызовы поправь после подтверждения.
Поведение не меняем.

Разделение god-файла: без явного «сначала план» агент перекраивает всё за один заход.

Найди в {папка/модуль} повторяющуюся логику.
Покажи списком: где повторяется и насколько похоже.
Не объединяй то, что похоже случайно, —
только то, что меняется по одной причине.
Правки — после подтверждения.

Оговорка про случайное сходство спасает от вредных абстракций.

Переименуй {старое} в {новое} по всему проекту:
код, тесты, миграции, тексты интерфейса, документация.
Сначала покажи полный список мест.
Отдельно отметь места, где название совпадает
случайно и трогать его не нужно.

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

Обнови {библиотека} с {версия} до {версия}.
Сначала прочитай changelog и перечисли
ломающие изменения, которые касаются нашего кода.
Потом правь. После правок запусти тесты
и покажи вывод.

Заставляет агента посмотреть на реальные breaking changes, а не чинить наугад.

Объясни, как устроен {модуль}: что он делает,
кто его вызывает, от чего зависит.
Начни с общей картины в пять предложений,
потом детали.
Ничего не правь — я разбираюсь, а не чиню.

Первое, что стоит спросить при входе в незнакомый проект.

Напиши тесты для {модуль}. Сначала перечисли
сценарии, которые собираешься покрыть, и жди
подтверждения. Моки только там, где без них
тест невозможен.

Базовый промпт для тестов. Список сценариев до кода экономит переписывание.

Баг: {описание}. Он уже исправлен.
Напиши один тест, который падал бы до исправления
и проходит после.
Больше ничего не добавляй.

Регрессионный тест: один точный тест ценнее десяти общих.

Вот тесты: {файл}.
Проверь, действительно ли они проверяют поведение,
а не повторяют реализацию.
Найди тесты, которые пройдут даже при
сломанной логике. Объясни, почему.

Ловит бесполезные тесты, которые агенты пишут особенно охотно.

Для {функция} перечисли крайние случаи:
пустой ввод, максимальные значения, некорректный
тип, одновременный доступ, отсутствие сети.
Сначала список, потом тесты — после подтверждения.

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

Напиши тесты для эндпоинта {путь}.
Покрой: успешный ответ, некорректные данные,
отсутствие авторизации, чужой ресурс.
Проверяй код ответа и структуру тела,
а не точный текст сообщений.

Проверка структуры вместо текста делает тесты устойчивыми.

Тест {имя} падает: {вывод}.
Сначала определи, кто неправ: тест или код.
Если неправ код — чини код.
Если неправ тест — объясни почему,
и только потом правь тест.
Не подгоняй тест под текущее поведение молча.

Ключевая оговорка: без неё агент чаще всего просто подгоняет ожидания под баг.

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

Раздел про процесс: превращает «агент что-то сделал» в согласованные шаги.

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

Запреты работают лучше пожеланий: их агент выполняет буквально.

Тексты интерфейса — по-русски, имена в коде —
по-английски.
Форматирование: {инструмент}, запускать после правок.
Коммиты: {формат}.
Новые файлы клади по существующей структуре,
новые папки не создавай без согласования.

Выравнивает поведение агента у всех разработчиков команды.

Прочитай файл правил проекта и перескажи
своими словами: что тебе запрещено делать
и что ты должен делать перед большой правкой.
Если какие-то правила противоречат друг другу —
укажи на это.

Проверка, что файл прочитан и понят, а не просто лежит в репозитории.

Кратко о проекте: {что это, для кого, стек}.
Сейчас работаю над: {задача}.
Уже сделано: {список}.
Не трогай: {файлы или области}.
Начни с того, что прочитаешь {файлы} и скажешь,
что понял.

Шаблон первого сообщения в новом диалоге, когда контекст сброшен.

Свёрстай {блок}: {описание содержимого}.
Стек: {…}. Существующие компоненты переиспользуй,
новые создавай только если без них никак.
Адаптив: {точки перелома}.
Цвета и шрифты бери из существующих переменных.

Указание на переиспользование не даёт агенту наплодить дубли компонентов.

На экране шириной {ширина} ломается {что именно}.
Покажи причину: какое свойство даёт переполнение.
Почини минимальной правкой, не переписывая
всю раскладку блока.

Локальная правка вместо переписывания всего блока.

Вот компонент: {файл}. Вот наши токены: {файл}.
Замени захардкоженные цвета, отступы и размеры
на переменные из дизайн-системы.
Если для значения нет подходящего токена —
не придумывай, а выпиши его списком.

Оговорка про отсутствующие токены не даёт агенту изобретать новые значения.

Проверь {компонент} на доступность:
семантика тегов, фокус с клавиатуры, подписи
к полям и кнопкам, контраст, состояния
для скринридера.
Выдай список проблем с приоритетом.
Правки — после подтверждения.

Доступность агент делает хорошо, но только если попросить явно.

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

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

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

Состояния «пусто» и «ошибка» забывают чаще всего.

Нужно хранить: {описание предметной области}.
Предложи структуру таблиц: поля, типы, связи,
индексы.
Отдельно укажи, что придётся менять, если
понадобится {вероятное изменение}.
Миграции пока не пиши.

Вопрос про будущие изменения выявляет слабые места схемы заранее.

Нужна миграция: {что меняем}.
Напиши up и down. В down — реальный откат,
а не заглушка.
Если миграция теряет данные — скажи об этом
явно перед кодом.

Предупреждение о потере данных — то, о чём агент обычно молчит.

Запрос {код или описание} работает медленно
на {объём} записей.
Покажи, что именно медленно: полный перебор,
отсутствие индекса, запрос в цикле.
Предложи правку и скажи, какой индекс нужен.
Не меняй логику выборки.

Классический N+1 и отсутствующие индексы агент находит хорошо.

Нужен эндпоинт: {что делает}.
Опиши: метод, путь, параметры, тело запроса,
формат ответа, коды ошибок, права доступа.
Сначала только описание, без кода.
Следуй тому, как устроены существующие эндпоинты.

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

Интеграция с {сервис}.
Обработай: таймаут, недоступность, некорректный
ответ, превышение лимита запросов.
Повторы — с задержкой и ограничением попыток.
Ни одна ошибка не должна ронять наш процесс.

Внешние сервисы падают всегда; агент об этом не думает без напоминания.

Нужна фоновая задача: {что делает, как часто}.
Учти: задача может запуститься дважды одновременно,
может упасть на середине, может выполняться
дольше интервала запуска.
Опиши, как это обработано, перед кодом.

Идемпотентность и перекрытие запусков — типовые грабли фоновых задач.

Проверь эти изменения: {diff или файлы}.
Ищи: ошибки логики, необработанные случаи,
утечки данных, проблемы с производительностью.
Не предлагай стилистические правки.
По каждой находке — чем именно это грозит.

Запрет на стилистику отсекает шум и оставляет только существенное.

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

Проверка чужой агентной работы — самая частая операция в вайбкодинге.

Проверь {модуль} на типовые проблемы:
внедрение в запросы, небезопасный вывод данных,
секреты в коде, отсутствие проверки прав,
доверие данным от пользователя.
По каждой находке — как эксплуатируется
и как чинится.

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

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

Оговорка «без разделов, которых нет» убирает выдуманные Contributing и Roadmap.

Объясни {файл} так, чтобы понял разработчик,
который видит проект впервые.
Начни с того, зачем этот код нужен,
потом как работает.
Без пересказа кода построчно.

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

Вот изменения: {diff}.
Напиши сообщение коммита на русском:
одна строка сути, потом список изменений
по пунктам.
Не перечисляй файлы — перечисляй смысл.

Разница между «правки в 12 файлах» и понятной историей изменений.