AI-разработкаБесплатноСреднийКачество и релизv1.0.0
Чек-лист готовности веб-приложения к продакшену
Преобразует вводные о приложении, инфраструктуре и команде в чеклист readiness перед релизом: что проверить, что блокирует запуск и что можно отложить без риска.
Описание
Преобразует вводные о приложении, инфраструктуре и команде в чеклист readiness перед релизом: что проверить, что блокирует запуск и что можно отложить без риска.
Кейс применения
Открывайте за 1-2 дня до релиза, когда нужно быстро пройтись по критическим проверкам и отделить must-have от nice-to-have без бесконечного споринга в чате.
Совместимость с моделями
- Cursor
- Codex
- Claude Code
- ChatGPT
- Claude
Пример формулировки
Составь чек-лист готовности к продакшену для «{{APP}}», стек «{{STACK}}», инфра «{{INFRA}}», команда «{{TEAM_SIZE}}».Текст промта целиком
## Роль
Ты работаешь в **существующем репозитории** через Cursor, Codex или Claude Code. Сначала опирайся на фактическую структуру проекта; не придумывай пути, файлы и модули, которых нет в репозитории и во входных данных.
## Задача
Собери **практичный** чек-лист готовности к продакшену с приоритетами: **env**, **auth**, **БД/миграции**, **платежи/вебхуки** (если релевантно), **логи**, **rollback plan**, go/no-go. Без «галочек пройдено» без фактического прогона.
## Контекст
- {{APP}}
- {{STACK}}
- {{INFRA}}
- {{TEAM_SIZE}}
## Ограничения
- Не выдумывай файлы, модули, маршруты и строки кода, которых нет в репозитории или во входе.
- **Не** помечай проверки как успешно пройденные, если в ответе нет факта запуска команды (укажи «нужно запустить»).
- **Не** раздувай scope: **minimal changes**, без переписывания рабочих частей без причины; **do not rewrite working parts** целиком.
- Пиши на русском; допустимы стандартные имена: Cursor, Codex, Claude Code, ChatGPT, Claude, Gemini, GitHub Copilot, Prisma, n8n.
- Если не хватает данных — до пяти уточняющих вопросов, затем продолжай с явными допущениями.
## Формат ответа
Результат оформь **на русском** по разделам. Не обещай, что тесты или прод прошли, если их не запускали. Не отмечай смоук или готовность как «пройдено» без фактического прогона команд.
### Inspect
- **inspect current structure** деплой-артефактов: CI, env, health — только по факту в репо.
### Scope
- Зона проверки; что не блокирует релиз, но в backlog.
### Plan
- Порядок проверок: конфиги → данные → безопасность → наблюдаемость.
### Implement
- Что **не** переписывать; только устойчивые **minimal changes** для рисков.
### Validate
- Явно: **lint**, typecheck, **tests/checks**, build — «запустить и зафиксировать». Не писать «ОК» без команды.
### 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 личный кабинет клиентов
- INFRA
- Docker + managed DB + CDN
- STACK
- Next.js + PostgreSQL + Redis
- TEAM_SIZE
- 6 человек, релиз раз в 2 недели
Ожидаемый результат
Критерии оценки
По этим критериям можно проверять качество результата перед рабочим использованием.
Release readiness checklist
Критерии
- Разделены критические и некритические проверки перед релизом.
- Выделены блокирующие риски с действиями до выката.
- Чеклист применим для команды без полной переработки.
- Нет размытого списка без приоритетов и владельцев.
Похожие промты
По категории, тегам и близкому сценарию применения.