7 промптов для AI-агентов: задачи, инструменты, проверка

Цель задачи (одной фразой): [например: «Добавить endpoint POST /api/users/{id}/avatar для загрузки аватара пользователя»].

Контекст проекта:
Стек: [язык + фреймворк + БД].
Где живёт похожий код для образца: [файл/папка].
Конвенции: [короткие — naming, тесты, error handling].

Что должно работать после задачи:
1) [конкретное поведение 1].
2) [конкретное поведение 2].
3) [edge case — что если файл слишком большой / не картинка / запрос без авторизации].

Acceptance criteria (все должны выполняться):
1) Код проходит существующие тесты.
2) Добавлены новые тесты на happy path и edge cases.
3) Линтер не ругается.
4) PR с понятным описанием изменений.

Границы (что НЕ делать):
Не менять схему БД (требует миграции — выходит за scope).
Не трогать существующие endpoints.
Не добавлять новые зависимости в requirements/package.json.
Не делать commit в main — только в feature-ветку, потом PR.

Если столкнёшься с неоднозначностью — остановись и задай уточняющий вопрос. Лучше спросить, чем сделать неправильно.

Тема исследования: [например: «Какие open-source альтернативы есть у Datadog для observability в малой команде»].

Что хочу получить:
1) Шорт-лист 5–10 решений с краткими описаниями.
2) Сравнительная таблица по критериям: [критерии — функционал, производительность, стоимость, простота установки, активность сообщества].
3) Рекомендация — топ 2–3 для дальнейшего пилотирования.
4) Источники — на что опирался (ссылки на документацию, бенчмарки, обсуждения).

Принципы:
1) Только то, что реально существует. Не выдумывай решения, которые звучат правдоподобно.
2) Если решение проверял лично (использовал API, читал доки) — пометь это. Если только по описанию из третьих источников — тоже пометь.
3) Указывай дату источника. Информация о ценах и фичах быстро устаревает.
4) Если по теме мало достоверных источников — скажи об этом, не выдумывай.

Границы:
Не подписываюсь на платные сервисы для проверки.
Не запускаю команды на моей рабочей машине, только в sandbox.
Не отправляю запросы на сервисы, которые требуют моего email/телефона.

Хочу автоматизировать процесс: [описание процесса, который сейчас делается руками].

Текущий процесс шаг за шагом:
1) [шаг].
2) [шаг].
...

Что хочу получить — скрипт / workflow / интеграция, который:
Запускается по [триггер — cron / webhook / ручной запуск].
Делает [конкретные действия].
Логирует результаты в [куда].
Уведомляет о проблемах в [Slack / email / Telegram].

Стек: [что используем — Python, Bash, n8n, Make, Zapier].

Acceptance criteria:
Тестовый прогон проходит на dev-окружении.
Есть rollback / undo для деструктивных действий.
Есть логирование всех действий с timestamp.
Документирована инструкция по запуску и по диагностике сбоев.

Границы:
Не запускать на prod, пока не проверим на dev.
Все секреты — через переменные окружения, не в коде.
Никаких удалений данных без двух подтверждений (логирование + явный флаг).
При первой ошибке — остановиться и уведомить, не «продолжить, может получится».

Задача: миграция данных из [ИСТОЧНИК — старая БД / CSV / API] в [НАЗНАЧЕНИЕ — новая БД / другой формат].

Источник:
Структура: [короткая схема].
Объём: [число записей].
Известные проблемы данных: [пропуски, дубли, кодировка, кривые форматы].

Назначение:
Структура: [короткая схема].
Преобразования: [какие нужны].
Жёсткие ограничения: [unique constraints, обязательные поля].

Этапы (выполнять последовательно, останавливаясь на каждом для проверки человеком):
1) Аудит источника — что есть, что не так, сколько проблемных записей.
2) Маппинг полей — таблица соответствий источник → назначение, с правилами преобразования.
3) Тестовая миграция — на 100 записях, в тестовую БД. Сверка результата.
4) Полная миграция — на dev-копии. Сверка по контрольным суммам и выборочным записям.
5) Backup prod — обязательно, отдельным шагом.
6) Миграция prod — с возможностью rollback.
7) Постмиграционная сверка — все ли данные доехали, нет ли потерь.

Границы:
Не запускать без явного подтверждения после каждого этапа.
Не удалять источник, пока сверка назначения не подтверждена 100%.
Не пропускать backup, даже если кажется, что миграция простая.

Запусти автоматический code review для PR.

Источник: [ссылка на PR / diff].
Контекст проекта: [язык, фреймворк, main branch].
Конвенции команды: [короткий список правил].

Что проверить:
1) Соответствие конвенциям (naming, structure, comments).
2) Корректность — баги, edge cases, забытые проверки.
3) Безопасность — инъекции, утечки, небезопасные дефолты.
4) Производительность — N+1, лишние запросы, тяжёлые операции в hot path.
5) Тесты — покрытие, качество ассертов.
6) Документация — изменены ли README/API docs, если нужно.

Формат вывода:
Для каждой находки — файл:строка, тяжесть (blocker/major/minor/nit), описание, предложенная правка.
Сначала blocker'ы, потом остальное.
В конце — суммарная оценка PR (готов / требует правок / переделать).

Границы:
Только комментарии в PR, не push'и в ветку.
Не предлагай переписать архитектуру (это решение продакта).
Не блокируй PR автоматически — только помечай blockers, человек принимает решение.
Если в коде PII / секреты — отметь и не коммитируй ничего, что показывало бы их.

Задача: подключить интеграцию с [НАЗВАНИЕ_API].

Что нужно сделать:
1) Изучить API документацию (auth, endpoints, rate limits).
2) Настроить безопасное хранение ключей (env vars, не в коде).
3) Реализовать клиента: основные endpoints, обработка ошибок, retries.
4) Покрыть тестами (мок API в тестах).
5) Добавить логирование и мониторинг.
6) Документация — короткое README с примерами использования.

Эндпоинты, которые нужны MVP:
[список с описанием].

Acceptance criteria:
Все указанные эндпоинты работают end-to-end на dev-окружении.
Rate limits соблюдаются (нет 429 ошибок при типичной нагрузке).
Ошибки не «глотаются» — логируются с контекстом.
Секреты не утекают в логи.

Границы:
Не запускать тесты, которые делают реальные платные вызовы (стоимость оплаты — мой риск).
Не использовать deprecated эндпоинты, если есть актуальные.
Не делать webhook-эндпоинты на open URL без подписи (безопасность).
Если API требует whitelist IP / верификации домена — сначала уточни у меня, как настроить.

Описание бага:
Что происходит: [симптом — конкретно, в продакшене].
Когда воспроизводится: [условия и частота].
Что должно быть: [ожидаемое поведение].
Когда появилось: [после какого релиза / даты, если знаем].

Доступная диагностика:
Логи: [ссылка / вставка релевантных строк].
Стек технологий: [язык, фреймворк, БД].
Метрики: [что показывают графики / дашборды].

План отладки (выполнять последовательно):
1) Сформулировать 3–5 гипотез о причине, в порядке вероятности.
2) Для каждой — минимальный эксперимент / запрос / лог-фраза, которая её подтвердит/опровергнет.
3) Начать с самой дешёвой проверки.
4) После каждого эксперимента — обновить вероятности и план.
5) При нахождении причины — предложить минимальный фикс + тест, чтобы проблема не вернулась.

Границы:
Не делать изменений в prod без человека.
Не запускать команды, которые меняют данные (даже если кажутся безопасными).
Если для гипотезы нужны логи, которых нет — предложи добавить логирование (но не пуши его в prod без меня).
Если за 5 экспериментов причина не найдена — остановись и эскалируй к человеку с отчётом «что проверили, что отсекли».