Готовые промпты

Скопируйте, вставьте описание своей задачи в места […] и отправьте своему ИИ.

Ты — продуктовый менеджер с опытом запуска MVP. Составь одностраничный PRD.

Идея: [опиши идею в 1-2 предложениях]
Для кого: [кто будет пользоваться]
Проблема, которую решаем: [одно предложение]

Формат:
1. Цель MVP и одна ключевая метрика
2. Функции: только 3-5 самых важных, у каждой — критерий готовности
3. Сценарии: счастливый путь, путь с ошибкой, крайний случай
4. Что сознательно вне скоупа
5. Вопросы, которые нужно решить до старта

Правила: максимум 3 предложения на пункт, без воды.

На основе PRD выбери минимальный технический стек для MVP.

PRD: [вставь PRD]

Ответь:
1. Стек: фреймворк + хостинг + БД + auth. Почему именно он — 2-3 предложения
2. Модель данных: таблицы/коллекции с ключевыми полями
3. Что берём готовым (платежи, email, логин), а что пишем сами
4. Три главных риска стека
5. Что намеренно НЕ делаем в MVP

Ограничения: предпочитай managed/severless, минимум инфраструктуры, дедлайн неделя.

Реализуй фичу в существующем проекте.

Фича (поведение): [что должен делать пользователь]
Где это сейчас: [экраны/файлы, если знаешь]
Ограничения: [брандбук, стиль, дедлайн]

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

Если план покажется мне неверным — я остановлю и уточню.

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

Симптом: [что происходит]
Ожидание: [что должно быть]
Воспроизведение: [шаги]
Среда: [браузер/ОС]

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

Запрещено: правки вслепую, переписывание несвязанного кода.

Ты — специалист по безопасности. Проведи аудит приложения перед запуском.

Проект: [какие файлы проверить, или «весь проект»]

Проверь по пунктам, отчёт по каждому — [OK/РИСК/КРИТ] + доказательство (файл:строка) + рекомендация:
1. Секреты: ключи, пароли, токены в коде, .env, история git
2. Авторизация: может ли пользователь A прочитать/изменить данные B (IDOR)
3. Ввод: XSS, инъекции в БД, неограниченный размер запросов
4. Зависимости: устаревшие пакеты, известные CVE
5. Rate limiting и лимиты расходов на публичных endpoints
6. Ошибки: не утекают ли внутренние детали наружу

В конце — список критичных действий по приоритету.

Отрефактори код, сохранив поведение ровно как есть.

Файлы/модуль: [пути]
Что беспокоит: [дублирование, длинные функции, запутанные имена — или «оцени сам»]

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

Формат завершения: список изменений + что проверить руками.

Подготовь проект к публикации.

Стек: [фреймворк]
Хостинг: [Vercel/Cloudflare/свой сервер]

Сделай:
1. Проверь production-сборку локально, почини ошибки
2. Перечисли переменные окружения для хостинга
3. Настрой заголовки: CSP, HSTS, X-Content-Type-Options, Referrer-Policy
4. Проверь ссылки и ассеты в собранной версии
5. Дай чек-лист «что проверить после публикации» (5-7 пунктов)
6. Перечисли TODO/заглушки, которые остались

Без моего «го» ничего не деплой.

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

Сделай:
1. Стек и структуру: ключевые папки и их назначение
2. Стиль кода: именование, форматирование, принятые паттерны
3. Данные: где источник правды (БД/API/файлы), ключевые модели
4. Частые ошибки в этом проекте и как их избегать
5. Готовый текст для AGENTS.md — правила для следующих агентов

Цель: агент продолжает работу без расспросов о базовых вещах.

Собери из моих ответов карточку знаний о проекте.

Вопросы (отвечай на каждый):
1. Продукт: что делает, для кого, чем отличается от конкурентов
2. Пользователи: кто основной, что им больно
3. Термины: специфичные слова проекта и их значения
4. Решения: почему выбраны эти технологии/походы
5. Ошибки прошлого: что пробовали и не сработало

Формат: структурированный документ на 1-2 страницы, который можно класть в контекст агента.

Ты — инженер по тестированию. Напиши тесты для только что реализованной фичи.

Фича: [опиши]
Файлы: [пути]

Требования:
1. Сначала перечисли сценарии: счастливый путь, граничные значения, ошибки
2. Минимум один тест на критичный путь (оплата, вход, сохранение)
3. Каждый тест — с комментарием, что именно ловит
4. Тесты должны запускаться: покажи команду
5. Не добавляй тесты ради покрытия — только на реальные риски

Если тестовая инфраструктура в проекте отсутствует — предложи минимальную (одну библиотеку, без раздувания).

Проведи код-ревью проекта.

Файлы/модуль: [пути или «весь проект»]

Проверь и отчитайся по каждому пункту (файл:строка + рекомендация):
1. Логические ошибки и гонки (race conditions)
2. Утечки ресурсов: подключения, файлы, таймеры
3. Незакрытые TODO/заглушки/mock-данные
4. Дублирование, которое стоит вынести
5. Непроверяемые места: нет обработки ошибок
6. Проблемы производительности (O(n) в цикле, запросы в цикле)

Формат: список проблем по приоритету, в конце — «что можно не чинить».

Напиши документацию для проекта.

Разделы:
1. Что делает проект (2-3 предложения для новичка)
2. Быстрый старт: установка, настройка, запуск
3. Архитектура: ключевые модули и связи (схема текстом)
4. Конфигурация: переменные окружения и что они значат
5. Частые задачи: как добавить фичу, как починить типовую ошибку

Правила: короткие секции, примеры команд, без воды. Не выдумывай того, чего нет в коде — если не уверен, пометь «проверить».

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

Симптом: [что тормозит, где заметно]
Файлы: [если знаешь]

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

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

Интегрируй внешний API в проект.

Сервис: [название, документация]
Что нужно: [операции]

Требования:
1. Сначала опиши данные: запросы/ответы, ключевые поля
2. Ключ/токен — только через переменную окружения, не хардкодь
3. Таймауты и повторные попытки (retry с backoff)
4. Обработка ошибок API: лимиты (429), недоступность (5xx), неверный ключ
5. Тест: эндпоинт/функция вызывается и ошибка обрабатывается
6. Не логируй секреты и тело ответа целиком

Преврати отзывы пользователей в конкретные UX-правки.

Отзывы (цитаты, без редактирования):
[вставь]

Сделай:
1. Сгруппируй отзывы по проблемам (не по решениям!)
2. Для каждой проблемы: где в интерфейсе она возникает, почему пользователь спотыкается
3. Минимальное решение (1-2 изменения экрана/флоу), без редизайна всего
4. Как проверить, что стало лучше (сценарий проверки)

Приоритизируй: что чаще болит — то первым.

Разбери ошибку по логам и коду.

Текст ошибки/трейс:
[вставь]
Ожидаемое поведение: [что должно быть]

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

Не предлагай «обернуть в try/catch и посмотреть» — найди причину.

Проверь доступность интерфейса.

Страницы: [какие]

Проверь по чек-листу:
1. Контраст текста и фона (WCAG AA)
2. Фокус: видно, где он, порядок Tab правильный
3. Кнопки и поля: есть ли подписи (label), работает ли с клавиатуры
4. изображения: alt-тексты осмысленные
5. Заголовки: иерархия h1→h2→h3

Формат: список проблем (страница → элемент → как чинить), в конце перечень «уже хорошо».

Спланируй и выполни миграцию данных/схемы.

Что меняем: [текущая схема → новая]
Данные, которые нельзя терять: [что]

Сделай:
1. План миграции: шаги, для каждого — SQL/код
2. Бэкап перед миграцией: как сделать и как проверить
3. Обратный путь: как откатить, если что-то сломалось
4. Проверки после каждого шага: запросом/функцией
5. Обработка ошибок: где валидировать данные, что делать с «мусором»

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

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

Что случилось в проекте за последний месяц: [кратко]
Где агент «плавал»: [перечисли ситуации, если есть]

Сделай:
1. Какие решения не зафиксированы и должны попасть в AGENTS.md / docs
2. Какие ошибки агент повторяет (по твоим правкам)
3. Какие правила добавить в AGENTS.md, чтобы их не было (готовый текст)
4. Обнови структуру промптов: что добавить, что убрать

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