Готовые промпты
Скопируйте промпт, вставьте его в агента и подставьте свои данные в квадратных скобках.
PRD на одну страницу
Когда использовать: Вставьте перед первой сборкой. Агент спросит детали — отвечайте; готовый PRD сохраните в docs/ — он же послужит контекстом для следующих шагов.
Ты — продуктовый менеджер с опытом запуска MVP. Составь одностраничный PRD. Идея: [опиши идею в 1-2 предложениях] Для кого: [кто будет пользоваться] Проблема, которую решаем: [одно предложение] Формат: 1. Цель MVP и одна ключевая метрика 2. Функции: только 3-5 самых важных, у каждой — критерий готовности 3. Сценарии: счастливый путь, путь с ошибкой, крайний случай 4. Что сознательно вне скоупа 5. Вопросы, которые нужно решить до старта Правила: максимум 3 предложения на пункт, без воды.
Выбор стека
Когда использовать: После PRD. Заставляет агента обосновать выбор, а не тянуть случайные технологии. Повторяйте при каждом большом изменении архитектуры.
На основе 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. Если причина вне кода (сеть, конфиг, данные) — скажи прямо Запрещено: правки вслепую, переписывание несвязанного кода.
Security-аудит перед запуском
Когда использовать: Запускайте перед публикацией и после каждой крупной фичи. Агент проверяет по чек-листу и даёт приоритизированный список.
Ты — специалист по безопасности. Проведи аудит приложения перед запуском. Проект: [какие файлы проверить, или «весь проект»] Проверь по пунктам, отчёт по каждому — [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/заглушки, которые остались Без моего «го» ничего не деплой.
Контекст для нового агента
Когда использовать: В начале работы с новым инструментом или после долгой паузы. Результат можно положить в AGENTS.md, чтобы любой агент стартовал с пониманием проекта.
Изучи проект и опиши его так, чтобы новый агент работал как участник команды. Сделай: 1. Стек и структуру: ключевые папки и их назначение 2. Стиль кода: именование, форматирование, принятые паттерны 3. Данные: где источник правды (БД/API/файлы), ключевые модели 4. Частые ошибки в этом проекте и как их избегать 5. Готовый текст для AGENTS.md — правила для следующих агентов Цель: агент продолжает работу без расспросов о базовых вещах.
Обучение на своих данных
Когда использовать: Когда агенту не хватает контекста вашего бизнеса/продукта. Отдаёт «знание» в структурированном виде, которое можно хранить в docs/ и подключать к промптам.
Собери из моих ответов карточку знаний о проекте. Вопросы (отвечай на каждый): 1. Продукт: что делает, для кого, чем отличается от конкурентов 2. Пользователи: кто основной, что им больно 3. Термины: специфичные слова проекта и их значения 4. Решения: почему выбраны эти технологии/походы 5. Ошибки прошлого: что пробовали и не сработало Формат: структурированный документ на 1-2 страницы, который можно класть в контекст агента.
Написать тесты
Когда использовать: После реализации фичи. Заставляет агента покрыть критичные пути и объяснить, что проверяет каждый тест.
Ты — инженер по тестированию. Напиши тесты для только что реализованной фичи. Фича: [опиши] Файлы: [пути] Требования: 1. Сначала перечисли сценарии: счастливый путь, граничные значения, ошибки 2. Минимум один тест на критичный путь (оплата, вход, сохранение) 3. Каждый тест — с комментарием, что именно ловит 4. Тесты должны запускаться: покажи команду 5. Не добавляй тесты ради покрытия — только на реальные риски Если тестовая инфраструктура в проекте отсутствует — предложи минимальную (одну библиотеку, без раздувания).
Код-ревью агентов и своего кода
Когда использовать: Регулярно, раз в 1-2 недели или перед релизом. Агент читает весь проект и ищет конкретные классы проблем.
Проведи код-ревью проекта. Файлы/модуль: [пути или «весь проект»] Проверь и отчитайся по каждому пункту (файл:строка + рекомендация): 1. Логические ошибки и гонки (race conditions) 2. Утечки ресурсов: подключения, файлы, таймеры 3. Незакрытые TODO/заглушки/mock-данные 4. Дублирование, которое стоит вынести 5. Непроверяемые места: нет обработки ошибок 6. Проблемы производительности (O(n) в цикле, запросы в цикле) Формат: список проблем по приоритету, в конце — «что можно не чинить».
Документация проекта
Когда использовать: Когда проект вырос и пора зафиксировать знание. Результат можно положить в docs/, а короткую версию — в README.
Напиши документацию для проекта. Разделы: 1. Что делает проект (2-3 предложения для новичка) 2. Быстрый старт: установка, настройка, запуск 3. Архитектура: ключевые модули и связи (схема текстом) 4. Конфигурация: переменные окружения и что они значат 5. Частые задачи: как добавить фичу, как починить типовую ошибку Правила: короткие секции, примеры команд, без воды. Не выдумывай того, чего нет в коде — если не уверен, пометь «проверить».
Оптимизация производительности
Когда использовать: Когда приложение тормозит. Сначала замеры, потом правки — иначе оптимизируем не то.
Найди и исправь узкие места производительности. Симптом: [что тормозит, где заметно] Файлы: [если знаешь] Порядок: 1. Гипотезы о причинах: лишние запросы, тяжёлые операции на клиенте, отсутствие кэша, блокировки 2. По каждой гипотезе: где именно в коде (файл:строка) 3. Правь только подтверждённые места, маленькими шагами 4. Покажи, как измерить улучшение (замер до/после) Запрещено: преждевременная оптимизация, переписывание работающего кода без замера.
Интеграция внешнего API
Когда использовать: Когда подключаете сторонний сервис: платёжка, почта, гео, LLM. Закрывает типовые грабли: таймауты, лимиты, ошибки.
Интегрируй внешний API в проект. Сервис: [название, документация] Что нужно: [операции] Требования: 1. Сначала опиши данные: запросы/ответы, ключевые поля 2. Ключ/токен — только через переменную окружения, не хардкодь 3. Таймауты и повторные попытки (retry с backoff) 4. Обработка ошибок API: лимиты (429), недоступность (5xx), неверный ключ 5. Тест: эндпоинт/функция вызывается и ошибка обрабатывается 6. Не логируй секреты и тело ответа целиком
Улучшение UX по отзывам
Когда использовать: Когда собрали обратную связь и нужно превратить её в конкретные правки. Проверяет, что агент не «украшает», а решает проблему.
Преврати отзывы пользователей в конкретные UX-правки. Отзывы (цитаты, без редактирования): [вставь] Сделай: 1. Сгруппируй отзывы по проблемам (не по решениям!) 2. Для каждой проблемы: где в интерфейсе она возникает, почему пользователь спотыкается 3. Минимальное решение (1-2 изменения экрана/флоу), без редизайна всего 4. Как проверить, что стало лучше (сценарий проверки) Приоритизируй: что чаще болит — то первым.
Разбор ошибки по трейсу/логам
Когда использовать: Когда ошибка воспроизводится, но непонятно, где. Агент работает от улик к причине.
Разбери ошибку по логам и коду. Текст ошибки/трейс: [вставь] Ожидаемое поведение: [что должно быть] Порядок: 1. Разложи трейс: какая функция вызвала, какой слой (клиент/сервер/БД) 2. Покажи, где в нашем коде это происходит (файл:строка) 3. Найди источник: данные, гонка, конфиг, внешний сервис 4. Предложи фикс + способ проверки Не предлагай «обернуть в try/catch и посмотреть» — найди причину.
Проверка доступности (accessibility)
Когда использовать: Для сайтов перед публикацией и после изменения UI. Закрывает типовые проблемы, которые ИИ не пишет сам.
Проверь доступность интерфейса. Страницы: [какие] Проверь по чек-листу: 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. Обнови структуру промптов: что добавить, что убрать Цель: чтобы следующий цикл работы был точнее с первого промпта.