AI-разработкаБесплатноЛёгкийКачество и релизv1.0.0
План смоук-проверки перед релизом
Короткий набор проверок после деплоя и локальный проход по маршрутам: критические пути, API, UI и сценарий после серии правок — для команды без выделенного тестировщика.
Описание
Короткий набор проверок после деплоя и локальный проход по маршрутам: критические пути, API, UI и сценарий после серии правок — для команды без выделенного тестировщика.
Кейс применения
Когда релиз частый и нужен повторяемый минимальный набор проверок после выката.
Совместимость с моделями
- Cursor
- Codex
- Claude Code
- ChatGPT
Пример формулировки
Собери план смоук-теста после релиза «{{RELEASE}}» для продукта «{{APP}}», критические пути «{{PATHS}}», среда «{{ENV}}».Текст промта целиком
## Роль
Ты работаешь в **существующем репозитории** через Cursor, Codex или Claude Code. Сначала опирайся на фактическую структуру проекта; не придумывай пути, файлы и модули, которых нет в репозитории и во входных данных.
## Задача
Собери **короткий** план смоук-после-релиза/после-серии-правок: маршруты, ожидаемые результаты, **do not** отмечать passed без запуска, rollback-сигналы, фиксация для постмортема.
## Контекст
- {{RELEASE}}
- {{APP}}
- {{PATHS}}
- {{ENV}}
## Ограничения
- Не выдумывай файлы, модули, маршруты и строки кода, которых нет в репозитории или во входе.
- **Не** помечай проверки как успешно пройденные, если в ответе нет факта запуска команды (укажи «нужно запустить»).
- **Не** раздувай scope: **minimal changes**, без переписывания рабочих частей без причины; **do not rewrite working parts** целиком.
- Пиши на русском; допустимы стандартные имена: Cursor, Codex, Claude Code, ChatGPT, Claude, Gemini, GitHub Copilot, Prisma, n8n.
- Если не хватает данных — до пяти уточняющих вопросов, затем продолжай с явными допущениями.
## Формат ответа
Результат оформь **на русском** по разделам. Не обещай, что тесты или прод прошли, если их не запускали. Не отмечай смоук или готовность как «пройдено» без фактического прогона команд.
### Inspect
- **inspect current structure** маршрутов/экранов из {{PATHS}}; если пути не в репо — скажи, что сверяешь с задеплоенной средой.
### Scope
- Что входит в смоук; таймбокс; зоны риска.
### Plan
- Порядок шагов; **list affected files** в релизе — если известен diff.
### Implement
- Что фиксить в первую очередь при падении смоука; **propose minimal changes**.
### Validate
- **tests/checks** + ручной проход URL на {{ENV}}; запись результатов; без «успех» без прогона.
### Report
- **report changed files**; сигналы отката; артефакты для команды.
### Системные метки (не удалять; подстроки для инструментов)
inspect current structure; list affected files; files to change; propose minimal changes; minimal changes; implement; add checks/tests; tests/checks; do not rewrite working parts; report changed files
## Чего избегать
- Общих рекомендаций без привязки к репозиторию
- Смешения русского и английского в пользовательских фразах без необходимости
- Массового рефакторинга, broad rewrite, несанкционированного изменения публичных API
- Выдуманных путей, пакетов, эндпоинтов, которых нет в кодеПримеры использования
Реалистичные сценарии входных данных и ожидаемого результата.
Пример 1
Входные данные
- APP
- B2B-магазин запчастей
- ENV
- прод + staging для сравнения
- PATHS
- логин, поиск, корзина, оформление, webhooks оплаты
- RELEASE
- v2.4 — новая оплата по счёту
Ожидаемый результат
Примечание
Подходит для итеративной работы в Cursor, Codex или Claude Code.
Критерии оценки
По этим критериям можно проверять качество результата перед рабочим использованием.
Выполнимость смоук-плана
Критерии
- Проверки конкретны
- Есть ожидаемые результаты
- Учтено сравнение со staging
- Есть критерии отката
Похожие промты
По категории, тегам и близкому сценарию применения.