AI-разработкаБесплатноСреднийПоэтапная поставкаv1.2.0
Пошаговая реализация фичи в Cursor
Промт для Cursor/Codex/Claude Code, который разбивает фичу на фазы, задаёт границы изменений, список файлов и обязательные проверки перед merge.
Кейс применения
Открывайте, когда нужно внедрить фичу поэтапно без хаотичных правок: сначала аудит репозитория, затем маленькие патчи с тестами.
Совместимость с моделями
- Cursor
- Codex
- Claude Code
- ChatGPT
Пример формулировки
Составь поэтапный план внедрения фичи «{{FEATURE}}» в продукте «{{PRODUCT}}» для стека «{{STACK}}» с учётом ограничений: {{CONSTRAINTS}}.Текст промта целиком
## Repository context
Продукт: {{PRODUCT}}. Стек и архитектурные границы: {{STACK}}. Где в репозитории живёт целевая функциональность для фичи «{{FEATURE}}» — опиши без выдуманных путей.
## Feature goal
Фича: {{FEATURE}}. Текущее поведение и желаемое после внедрения — кратко.
## Product context
Как фича встраивается в {{PRODUCT}}: пользовательский поток, затронутые экраны и данные.
## Stack
{{STACK}}
## Constraints
{{CONSTRAINTS}}
## Files to inspect first
Назови ключевые файлы и модули перед любыми правками.
## Phased implementation plan
### Phase 1 — безопасная подготовка
Read-only аудит, инвентарь затронутых файлов, проверка контрактов и зависимостей. Без изменения продуктового поведения.
### Phase 2 — минимальная реализация
Минимальный набор патчей для рабочего сценария фичи; без массового рефакторинга соседних модулей.
### Phase 3 — проверка и полировка
Тесты, типы, регрессия по зоне; при необходимости — мелкие правки после обратной связи.
## Allowed changes
Правки только в затронутых модулях + тесты/типы, согласованные с фазами.
## Forbidden changes
Не менять unrelated код, не делать broad rewrite, не расширять scope фичи без явного согласования.
## Step-by-step implementation plan
1) inspect current structure
2) list affected files
3) files to change
4) propose minimal changes
5) implement
6) add checks/tests
7) report changed files
## Tests/checks to run
Локальные unit/integration + lint + проверки по зоне {{FEATURE}}.
## Expected output
По каждой фазе: цель, список файлов, команды, риски. Итог: changed files, dependency notes, готовность к merge.
## Rollback notes
План отката по этапам, если после Phase 2 или 3 выявится регрессия.
## Additional guardrail
do not rewrite working parts; keep minimal changes and explicit diffs.Примеры использования
Реалистичные сценарии входных данных и ожидаемого результата.
Пример 1
Входные данные
- STACK
- Next.js App Router, Prisma, PostgreSQL, zod
- FEATURE
- Добавить фильтр по тегам в каталог
- PRODUCT
- Monorepo: витрина каталога и API списка товаров
- CONSTRAINTS
- Не менять API-контракты, не трогать оплату и webhooks
Ожидаемый результат
Примечание
Каждая фаза должна быть merge-ready и укладываться в CONSTRAINTS.
Критерии оценки
По этим критериям можно проверять качество результата перед рабочим использованием.
Code-agent phased implementation
Критерии
- Явно разделены Phase 1 (подготовка), Phase 2 (минимальная реализация), Phase 3 (проверка и полировка).
- Перед реализацией есть repository audit и границы области изменений.
- Указаны files to change и итоговый отчёт changed files; нет призыва к broad rewrite.
- Есть tests/checks и rollback по этапам.
- CONSTRAINTS учтены в плане патчей.
Похожие промты
По категории, тегам и близкому сценарию применения.