50 промптов для программистов в Cursor, Claude Code и Codex в 2026

Промпт в Cursor, Claude Code или Codex — это не «привет, напиши код». Это инженерный артефакт: контекст, ограничения, формат ответа и явный критерий «когда задача считается выполненной». Один и тот же запрос, сформулированный двумя способами, даёт либо рабочий PR за три минуты, либо двадцать минут отлова галлюцинаций и неработающих импортов.

Собрали библиотеку из 50 промптов для программистов, которые в редакции используем каждую неделю, по шести категориям: новый проект, рефакторинг, тесты, фикс багов, документация и ревью чужого кода. К каждому промпту даём пример «до/после» с реальным выхлопом модели, рекомендацию, под какую задачу какая модель лучше (Claude Opus 4.7, Sonnet 4.6 или GPT-5), и пометки, что точно не работает.

Это библиотека для тех, кто пишет код профессионально или регулярно: разработчиков, тимлидов, DevOps, QA-инженеров. Если вы не программист и хотите подключить AI к маркетингу, аналитике или редакторской работе, смотрите статью Claude Code для не-программистов.

Если вы только начинаете и ещё не понимаете, чем эти три инструмента отличаются, стоит сначала прочитать обзорную статью про вайбкодинг и сравнение Claude Code vs Cursor. Здесь же мы исходим из того, что вы уже сидите хотя бы в одном из трёх и хотите выжимать из него больше.

Промпты универсальные, но есть нюансы. В Cursor работает inline-режим Cmd+K и Composer с @‑mentions файлов. В Claude Code (агентный CLI) можно ссылаться на slash-команды и писать CLAUDE.md для проекта. В OpenAI Codex (облачный агент с PR-логикой) есть файл AGENTS.md. Где это критично, пометим отдельно.

Если хочется освоить ремесло промптинга системно, а не собирать по крупицам в Telegram, загляните в нашу подборку курсов по промпт-инжинирингу: 33 программы от коротких интенсивов до годовых треков.

TL;DR — что забрать из статьиСкопировано

• Хороший промпт всегда содержит четыре части: контекст, задача, ограничения, формат ответа.
• Opus 4.7 — для архитектуры, ревью, рефакторинга больших кусков и дизайна систем. Sonnet 4.6 — рабочая лошадь на 90 % задач: код, тесты, фикс багов. GPT-5 — когда нужен альтернативный взгляд или работа с нестандартными форматами данных.
• Контекст всегда давайте через файл, а не через копипасту: @file.ts в Cursor, читай src/utils/parser.ts в Claude Code.
• Тесты пишите ДО кода или ПАРАЛЛЕЛЬНО, не ПОСЛЕ. Так модель сама проверяет себя.
• Запрещайте модели «исправлять, если она не понимает», фразой «если непонятно, остановись и задай вопрос».

Какая модель под какую задачу — короткоСкопировано

Cursor, Claude Code и Codex — это интерфейсы, а нейросеть, которая думает за вас, в каждом из них меняется. В Cursor выбор в выпадающем меню вверху Composer. В Claude Code модель ставится флагом --model или через /model. В Codex модель привязана к тарифу, по умолчанию GPT-5.

* Цены API за input/output на май 2026. В подписках Cursor Pro и Claude Max включён фиксированный лимит токенов, см. актуальные лимиты Claude Code.

Дефолт, если не уверены: Sonnet 4.6. Он закрывает 9 из 10 рабочих задач. Переключайтесь на Opus 4.7, если задача больше «подумать», чем «написать».

8 промптов для нового проектаСкопировано

Категория, где AI блестит ярче всего: с нуля собрать структуру, прописать импорты, поднять стек. Здесь модель не ограничена существующим кодом и может предложить чистую архитектуру.

1. Скаффолдинг с нуля

Промпт:

Подними проект на TypeScript + Vite + React 19 + Tailwind 4.
Нужны: страница /login с формой email+password, страница /dashboard
(защищённый роут), компонент Layout с шапкой и сайдбаром,
заглушка для API в src/api/.
Структура: feature-based, не routes-based.
Не пиши README, не добавляй ESLint. Отдай мне tree файлов и diff.

До (плохой промпт): «сделай SPA на React с авторизацией». Cursor сгенерирует 14 файлов, половину из которых вы не просили: jest.config.js, .eslintrc, vitest.setup.ts, package-overrides. Уберёте, сломается тест-команда.

После: получите ровно 11 файлов с объяснённой структурой и diff в один проход. Лучшая модель — Opus 4.7: он держит в голове всю структуру и не забывает про импорты.

2. Конфигурация инфраструктуры по чек-листу

Промпт:

Настрой Docker + docker-compose для проекта Python 3.13 + FastAPI + Postgres 17.
Требования:
1. Hot-reload в dev (volume на /app).
2. Postgres с healthcheck, чтобы api ждала готовности БД.
3. .env через env_file, не хардкод.
4. Прод-сборка: multi-stage, итоговый image < 200 MB.
Покажи Dockerfile, docker-compose.yml и .env.example.

Жёсткий чек-лист в промпте — это контракт. Модель не забудет про healthcheck и multi-stage. Лучшая модель — Sonnet 4.6: инфраструктура — её родная зона.

3. CLI-утилита по спецификации

Напиши CLI на Go (стандартный flag, без cobra).
Команды:
- `tool init` — создаёт ~/.tool/config.yaml с дефолтами
- `tool sync <url>` — качает JSON по url, валидирует против схемы в config, сохраняет в ~/.tool/cache/
- `tool list` — показывает кеш в виде таблицы
Покрой тестами (testify), README не нужен.
Стиль ошибок: всегда возвращай fmt.Errorf("%s: %w", op, err).

Тут важен последний пункт: стиль ошибок. Без него модель напишет идиоматичный, но не ваш Go.

4. Микросервис из OpenAPI-схемы

Сгенерируй handler-функции на Node.js + Hono из схемы api-spec.yaml.
@api-spec.yaml
Требования:
- Один файл на эндпоинт, никаких «контроллеров на 500 строк».
- Валидация через zod, схемы вынеси в src/schemas/.
- Error-handling: единый middleware, ответы в формате RFC 7807.
Заглушки бизнес-логики оставь TODO с описанием.

Прикрепляйте схему через @api-spec.yaml в Cursor или читай api-spec.yaml в Claude Code. Без этого модель сочинит эндпоинты из воздуха.

5. Начальный CLAUDE.md / .cursorrules / AGENTS.md

Сделай AGENTS.md для текущего проекта, прочитав:
@package.json @tsconfig.json @src/ @README.md
Структура:
1. Что это за проект (3-5 предложений).
2. Стек (явно: версии, фреймворки).
3. Команды (dev, test, build, lint).
4. Что нельзя делать без подтверждения (миграции, удаление файлов, изменение env).
5. Что в /tmp/ — игнорируй.
6. Конвенции (импорты, naming, тесты).
Без воды, конкретно.

Один из самых высокоокупаемых промптов: 10 минут на первый запуск экономят часы галлюцинаций в будущем. Подробнее про шаблоны, в статье CLAUDE.md примеры. Лучшая модель — Opus 4.7.

6. Plan-режим перед кодом

Хочу добавить экспорт в PDF в дашборд аналитики.
Сначала НЕ ПИШИ КОД. Дай план в виде:
1. Какие файлы трогаем (полный список).
2. Какие зависимости добавляем.
3. Какие edge cases надо предусмотреть.
4. Как тестируем (unit + e2e).
5. Риски регрессии — где можем сломать существующее.
Жду план. Код напишем после одобрения.

Сamost важный паттерн вайбкодинга в 2026. План отделён от кода, получаете дешёвую возможность сказать «не туда» до того, как модель сожгла токены на генерации 600 строк. В Cursor это режим Plan, в Claude Code, просто инструкция «не писать код пока не одобрю».

7. Прототип за один экран

Сделай одностраничный HTML с встроенным JS (без сборщика, без npm).
Внутри: визуализация Lissajous figures в canvas,
два слайдера (a и b — частоты), один слайдер (delta — фаза).
В реальном времени перерисовка. Стиль — тёмная тема, монохром.
Один файл, открывается двойным кликом в браузере.

Для презентаций, демо в Telegram, быстрого «давайте посмотрим, как это будет выглядеть». GPT-5 здесь часто оригинальнее в дизайн-решениях, чем Claude.

8. Миграция со старой версии стека

Проект на Vue 2 + Vuex + Webpack 4.
Спланируй миграцию на Vue 3 + Pinia + Vite 5.
Покажи:
1. Этапы (что переключаем первым, что последним).
2. Файлы-камикадзе (которые проще переписать с нуля).
3. Файлы для автоматической трансформации (vue-codemod / regex).
4. Где будут breaking changes в зависимостях.
5. Сколько примерно человеко-часов (грубо).
Код пока не пиши.

Лучшая модель — Opus 4.7. Migration plan, ровно та задача, где нужно «много контекста + много рассуждения».

9 промптов для рефакторингаСкопировано

Самая опасная категория. Рефакторинг ломает работающий код, если модель не понимает инвариантов. Поэтому каждый промпт начинается с контекста и заканчивается тестами.

9. Локальный рефакторинг через Cmd+K

Перепиши выделенную функцию для читаемости.
Извлеки сложную логику в именованные хелперы.
Сократи вложенные условия (early return).
Не меняй сигнатуру, не меняй имена экспортов.
Сохрани поведение для всех тестов в @file.test.ts.

Cursor: выделите код, Cmd+K, вставьте. Получите diff на месте. Самый частый паттерн в нашей редакции.

10. Извлечение хука / композиции

В компоненте @UserDashboard.tsx логика загрузки пользователя
смешана с UI. Вынеси в кастомный хук useUserProfile(userId).
Хук должен:
- инкапсулировать useEffect + useState
- возвращать { user, loading, error, refetch }
- работать с уже существующим API-клиентом из @src/api/client.ts
В компоненте оставь только рендер.
Существующие тесты должны проходить без правок.

11. Замена паттерна по всему репозиторию

Найди все места, где используется паттерн `try { ... } catch (e) { console.error(e) }`
и замени на наш кастомный logger из @src/lib/logger.ts.
Правила:
- если в catch было только console.error — заменить на logger.error.
- если внутри catch есть rethrow — оставить, добавить logger.error перед throw.
- если catch пустой (swallow) — оставить, но добавить TODO-комментарий.
Покажи мне список файлов и diff. Не коммить.

Cursor с Composer или Claude Code здесь сильнее, чем GPT-5: они умеют читать сразу несколько файлов и применять одинаковую трансформацию.

12. Декомпозиция god-object

Класс OrderService в @src/services/order.ts разросся до 1200 строк.
Предложи декомпозицию по принципу single responsibility.
Дай:
1. Список новых классов/модулей (3-7), с описанием ответственности.
2. Карту миграции методов (старое имя → новое расположение).
3. Сначала план, потом код. План жду на согласование.
Хочу, чтобы публичный API не сломался — сохрани фасад OrderService
как тонкую обёртку поверх новых сервисов.

Opus 4.7 обязателен. Sonnet иногда теряет нюансы в таких задачах.

13. Перевод на новый паттерн ошибок

В проекте сейчас ошибки = строки. Хочу мигрировать на
дискриминированные union-типы (Result<T, E>).
@src/types/result.ts (уже есть тип Result).
План:
- Найди функции, которые возвращают строку с "Error: ..." как ошибку.
- Перепиши их на возврат Result<T, E>.
- Все вызывающие места обнови (pattern matching через if (result.ok)).
- Подели на коммиты по фичам, не один мега-коммит.
Не трогай тестовый код, только src/.

14. Удаление мёртвого кода

Сканируй @src/ на:
1. Экспорты, на которые нет импортов в проекте.
2. Функции с 0 вызовов.
3. Закомментированные блоки кода (более 3 строк).
4. import-ы, которые не используются.
Покажи отчёт: путь к файлу, строки, что предлагаешь удалить,
насколько уверена (high/medium/low).
Не удаляй сама. Я сам пройдусь.

Важно: явно запрещаем модели удалять. Иначе она самоуверенно вычистит то, что использовалось через динамический импорт. Лучшая модель — Sonnet 4.6.

15. Снятие копипасты

В файлах @parseInvoice.ts @parseReceipt.ts @parseOrder.ts
почти одинаковая логика парсинга PDF (90% совпадает).
Извлеки общую логику в src/lib/parsePdf.ts.
Различия — через параметризацию (тип документа, схема полей).
Сигнатуры экспортов не меняй — три парсера остаются,
но внутри тонкие обёртки над общим хелпером.
Тесты должны продолжать проходить.

16. Перевод callback-стиля на async/await

В @src/legacy/api/ все запросы написаны на callback'ах.
Перепиши на async/await + axios (axios уже в package.json).
Сохрани сигнатуры: где было `function(opts, callback)`,
сделай `function(opts): Promise<Result>`.
Старые вызовы оставь работающими через адаптер
(колбэк-обёртку поверх промиса) — удалим позже.

17. Снижение когнитивной сложности

В файле @src/billing/calculate.ts функция calculateInvoice
имеет cyclomatic complexity 18 (по ESLint).
Снизь до 10 или меньше:
- Извлеки вложенные ветки в отдельные чистые функции.
- Замени switch на словарь стратегий, где это уместно.
- Не меняй наблюдаемое поведение.
Не пиши никаких комментариев в коде. Объяснения — в ответе мне.

Запрет на комментарии, важный момент. Иначе модель насыпет // extracted from foo по всему файлу.

9 промптов для написания тестовСкопировано

18. Unit-тесты на функцию

Напиши Jest-тесты для функции formatPhoneNumber из @src/utils/format.ts.
Покрой:
- happy path (валидные номера российский, международный)
- edge cases (пустая строка, null, undefined, только пробелы, 0 цифр, 30 цифр)
- ошибочные форматы (буквы внутри, эмодзи)
Не используй snapshot-тесты, только явные assertions.
Группируй в describe по сценариям, не по входным значениям.

Лучшая модель — Sonnet 4.6. Тесты, её родное.

19. TDD-цикл

Я хочу добавить функцию calculateShippingCost(weight, country, isPriority).
Действуй по TDD:
1. Сначала напиши тесты (вместе обсудим, что покрывают).
2. Покажи мне их, дождись OK.
3. Затем напиши минимальную реализацию, чтобы тесты прошли.
4. Запусти тесты. Покажи вывод.
5. Если что-то падает — исправь и повтори.
Не пиши код раньше тестов.

Жёстко закреплённый порядок, ключ. Иначе модель «оптимизирует» и напишет всё разом.

20. Тесты на React-компонент

Напиши тесты для @UserProfile.tsx через @testing-library/react.
Покрой:
- рендер без user (показывается скелетон)
- рендер с user (имя, email, аватар)
- клик по «Редактировать» открывает модалку (моки store)
- form submit зовёт API (мок fetch)
- ошибка API показывает toast
Запросы мокай через msw, не jest.mock.
Не используй data-testid там, где можно findByRole / findByText.

21. Тесты на API endpoint

Напиши интеграционные тесты для POST /api/orders.
Используй supertest + тестовую базу (testcontainers с postgres).
Сценарии:
- 201 при валидном payload + проверка записи в БД
- 400 при невалидной схеме (пропущено поле, неправильный тип)
- 401 без токена
- 403 при токене с недостаточными правами
- 429 при превышении rate limit (5 запросов в минуту)
- 500 — НЕ покрывай (это не наша зона).
afterEach: очищай таблицу orders.

22. Property-based тесты

Напиши property-based тесты на функцию sortByDate из @src/utils/.
Библиотека fast-check.
Инварианты:
- длина выхода == длина входа
- множество элементов сохраняется
- результат отсортирован
- две одинаковые даты сохраняют относительный порядок (stability)
Не пиши больше 5 properties. Для каждой — runs:1000.

GPT-5 здесь иногда удивляет: предлагает property, которое Claude не замечает.

23. Регрессионный тест на баг

Только что нашли баг: при пустой корзине applyDiscount возвращает -100.
Сначала:
1. Напиши падающий тест, который ловит этот баг.
2. Запусти, убедись, что красный.
3. Покажи мне.
Потом починим код. Не правь src/ пока не одобрю тест.

24. Mutation testing — генерация мутантов

Прогони @src/services/payment.ts через mental mutation testing:
1. Перечисли 8-12 возможных мутаций (заменить === на ==, > на >=, true на false, удалить throw, и т.д.)
2. Для каждой — упадёт ли существующий тест?
3. Если НЕ упадёт — это пробел в покрытии. Напиши тест на эту мутацию.
Не запускай stryker или другие тулзы — это разговорная симуляция.

25. E2E-сценарий на Playwright

Напиши e2e-тест: пользователь логинится, добавляет товар, оформляет заказ.
Playwright. Один файл.
Используй page.getByRole / getByLabel, не CSS-селекторы.
Перед каждым тестом — чистый стейт (новый browser context).
Не делай screenshot-assertions, только семантические проверки.
Тестовые данные — фикстуры из @e2e/fixtures/.

26. Тесты на БД-миграцию

Написана миграция 0042_user_phone.sql (добавляет колонку phone NOT NULL).
Проверь её на безопасность:
1. Что будет с существующими 50M строк (есть default? есть backfill?)
2. Залочится ли таблица при ALTER?
3. Можно ли откатить?
Напиши тестовый сценарий (pseudo-SQL, без запуска):
- before: 100 строк, без phone
- apply migration
- expected: phone заполнен из default, no nulls
- rollback: phone убран, исходные строки целы.

9 промптов для фикса баговСкопировано

27. Минимальное воспроизведение

Вот стектрейс:
[вставить полный stack]
Вот код:
@src/payment/handle.ts
Не предлагай фикс сразу. Сначала:
1. Гипотеза №1: что вызывает ошибку (с обоснованием).
2. Какие данные надо посмотреть в логах, чтобы подтвердить.
3. Минимальный код-фрагмент, который должен воспроизвести баг локально.
Жду эти три пункта.

Без этого паттерна модели любят «исправить» симптом, оставив корневую причину.

28. «Это не там, где ты думаешь»

Третий раунд фикса бага про не-сохраняющийся профиль.
Ты предложила два варианта (валидация формы, race condition в API) —
оба не помогли.
Не повторяй уже отвергнутые гипотезы.
Прочитай @src/middleware/auth.ts @src/middleware/csrf.ts @src/api/profile/update.ts.
Поищи менее очевидные причины: middleware, кеширование, заголовки.
Если не находишь — скажи, что нужно посмотреть в логах.

Очень полезный шаблон, когда модель зациклилась.

29. Debug-логи временные

Добавь логирование в путь POST /api/orders для отладки.
Логи через наш logger (@src/lib/logger.ts).
Где: вход в handler, перед каждым внешним вызовом, в catch.
Формат: logger.debug({ op: 'orders.create', step: '...', data: { /* критичное */ } })
Не логируй пароли, токены, полный body.
В конце добавь TODO: cleanup после фикса.

30. Бинарный поиск по истории

Баг появился между релизом 2.4.0 (5 мая) и 2.5.0 (12 мая).
В этот период 47 коммитов.
Помоги сузить:
1. Прочитай @CHANGELOG.md и список коммитов (я приложу через @git-log.txt).
2. Выдели коммиты, которые могут касаться функционала Х (баг — здесь).
3. Предложи порядок git bisect (с какого коммита начать).
Не запускай команды, только план.

31. Reproduction в тесте

Перед тем как чинить — напиши падающий тест, который ловит баг.
Если тест проходит на main, баг не воспроизведён, не чини.
Тест должен быть в src/__tests__/regressions/issue-1234.test.ts.
Внутри — комментарий с ссылкой на issue и краткое описание.

32. Race condition

Подозреваю race condition в @src/uploader/queue.ts.
Симптом: иногда (1 из 50) загрузка пропадает.
Не предлагай мьютекс сразу.
Сначала:
1. Найди все async-операции, которые могут пересечься.
2. Опиши таймлайн «вот два запроса А и Б, что между ними может пойти не так».
3. Предложи минимальный тест, который воспроизводит проблему детерминированно.
Только потом — фикс.

Opus 4.7. Race conditions, ровно его жанр.

33. Утечка памяти

Heap snapshot показывает рост retained size в EventEmitter listeners.
@src/socket/connection.ts — основной кандидат.
Найди:
1. Где добавляются listeners (.on, .addListener, .addEventListener).
2. Где они удаляются.
3. Где может быть забыт removeListener в cleanup-пути (componentWillUnmount, finally).
Покажи список пар add ↔ remove, и где remove отсутствует.

34. Прод-баг по логам

В Sentry эта ошибка ловится 200+ раз в день:
[вставить sentry payload]
Не нашли воспроизведения локально.
1. Прочитай @related-files.
2. Выдвини три гипотезы (best/middle/worst-case).
3. Для каждой — какие доп. данные нужны от пользователя/Sentry, чтобы подтвердить.
4. Минимальный фикс для самой вероятной гипотезы (с откатом, если не помогло).

35. CI-флейк

Тест @src/api/orders.test.ts падает раз в 10 прогонов в CI,
локально не воспроизводится. Это флейк.
Не помечай его @skip и не повышай timeout.
Найди корневую причину:
- Гонки на shared state (БД, моки, глобальные переменные)?
- Зависимость от текущего времени (Date.now / new Date)?
- Сетевые моки с реальными запросами?
Покажи доказательство гипотезы — конкретные строки кода.

7 промптов для документацииСкопировано

36. README с нуля

Сделай README.md для проекта.
Прочитай @package.json @src/ @docker-compose.yml @CHANGELOG.md.
Структура (ровно эти разделы, не больше):
1. Что это (3-5 предложений).
2. Стек (короткий список с версиями).
3. Quickstart (3-5 команд, чтобы запустить локально).
4. Структура проекта (дерево, только верхний уровень).
5. Контрибьюция (где документация, как открывать PR).
Не пиши Badge'ы. Не пиши «Table of Contents».

37. Docstring/JSDoc для модуля

Добавь JSDoc-комментарии в публичные экспорты @src/lib/cache.ts.
Только для публичных функций (не private, не internal).
Стандарт:
- @param с типом и описанием
- @returns с описанием
- @throws если функция может бросать
- @example — один реалистичный
Не описывай self-evident параметры тривиально.
Не добавляй комментарии внутри тела функций.

38. ADR (Architecture Decision Record)

Запиши ADR-0007: «Переход с REST на tRPC для внутренних API».
Формат:
- Status: Accepted
- Context: почему встал вопрос (3-5 предложений)
- Decision: что выбрали и почему
- Consequences: плюсы, минусы, какие траты, что усложняется
- Alternatives considered: REST с openapi-codegen, GraphQL — почему НЕ
Файл: docs/adr/0007-trpc.md.

39. Документация эндпоинта

Документируй POST /api/orders.
@src/api/orders/create.ts (handler), @src/schemas/order.ts (валидация).
Формат — OpenAPI 3.1 YAML:
- requestBody с примером
- 4 ответа (201, 400, 401, 403) с примерами error-payload (RFC 7807)
- security: bearer
- tags: ["orders"]
Запиши в docs/api/orders.yaml. Не правь существующее.

40. Onboarding-документ для нового разработчика

Сделай onboarding.md для нового бэкенд-разработчика.
Структура:
1. Первый день: доступы (список систем), инсталляция (5 команд), как запустить локально.
2. Первая неделя: какие 3 PR закрыть для прогрева, ссылки на 5 ключевых модулей.
3. Где задавать вопросы (каналы, имена, когда кого тегать).
4. Как мы делаем код-ревью (3-5 правил).
5. Где документация (карта).
Не пиши «добро пожаловать в команду».

41. CHANGELOG из git-лога

Сгенерируй CHANGELOG.md для версии 2.6.0 из последних 80 коммитов.
@git-log.txt
Стандарт Keep a Changelog:
- Added / Changed / Deprecated / Removed / Fixed / Security
Группируй коммиты по этим заголовкам.
Игнорируй коммиты «chore», «ci», «docs» (если в них только опечатки).
Каждый пункт — одно предложение, активный залог.

42. Tutorial по своему API

Напиши tutorial «Первый заказ через API» для нашей публичной документации.
Аудитория: разработчик, видит наш API впервые.
Структура:
1. Получите API-key (1 параграф + ссылка на dashboard).
2. Создайте корзину (curl + ответ).
3. Добавьте товар (curl + ответ).
4. Оформите заказ (curl + ответ).
5. Что дальше (ссылки на эндпоинты для отмены, статуса).
Тон — без «легко!», «просто!», «всего за минуту». Сухой технический.

8 промптов для ревью чужого кодаСкопировано

43. Базовое ревью PR

Сделай ревью этого PR @diff.patch.
Контекст: @CLAUDE.md (соглашения проекта).
Жду:
1. Критичные замечания (баги, security, регрессии) — с цитатой строки.
2. Стилистические — отдельным списком.
3. Что хорошо (одно-два предложения, не приторно).
Без оценок типа «отличный код» и «можно лучше». Конкретика по строкам.

44. Security-фокус

Security-ревью diff @pr-diff.patch.
Проверь:
- SQL-инъекции (raw query / template literals в DB-вызовах)
- XSS (innerHTML, dangerouslySetInnerHTML)
- IDOR (доступ к ресурсам без проверки владельца)
- Открытые секреты в коде (API keys, токены)
- Небезопасный десериализованный input
- Race conditions в auth-флоу
По каждому пункту: нашёл / не нашёл, если нашёл — где (строки) и почему.

Opus 4.7. Security, здесь не экономьте на модели.

45. Performance-фокус

Перформанс-ревью @diff.patch.
Конкретные вещи:
- N+1 запросы в БД (внутри циклов запросы)
- Тяжёлые операции в hot path (sync IO, парсинг гигабайтных JSON)
- Утечки в подписках/listeners (без cleanup)
- Re-renders в React (отсутствие useMemo / useCallback где надо, или наоборот over-memo)
- Большие зависимости в bundle (typeof lib проверь)
Где нашёл — что предлагаешь сделать (но это draft, не финальный фикс).

46. Тесты — достаточно ли

В этом PR @diff.patch добавлены 4 теста и поменяна логика @src/billing/calc.ts.
Оцени:
1. Покрыта ли каждая новая ветка кода (if/else, try/catch, switch)?
2. Есть ли тесты на edge cases (граничные значения, null, пусто)?
3. Что НЕ покрыто, но должно быть?
Не предлагай переписать тесты, только укажи пробелы списком.

47. Архитектурное ревью

Этот PR @diff.patch добавляет 800 строк нового кода в фичу платежей.
Архитектурное ревью:
- Соответствует ли разделению слоёв (controller / service / repo)?
- Не нарушает ли SOLID (особенно SRP и Dependency Inversion)?
- Есть ли дубли с уже существующим кодом? (Прочитай @src/billing/, @src/payments/ и сравни.)
- Логика, которая должна быть в core, не уехала ли в UI-слой?
По каждому пункту — короткий вердикт + конкретная цитата.

48. Доступность (a11y)

Этот PR меняет компоненты UI: @diff.patch.
A11y-ревью:
- Семантические теги (button vs div role="button")
- aria-label / aria-labelledby у иконок-кнопок
- Контраст текста (если меняются цвета — флагнуть)
- Управление фокусом в модалках (focus trap, return focus)
- Клавиатурная навигация (Esc закрывает, Tab последовательность)
Реплей: где провал, почему, как починить (одной строкой).

49. Ревью миграции БД

Ревью миграции @migrations/0050_orders_index.sql.
Проверь:
1. Блокирующие операции (ALTER TABLE без CONCURRENTLY, full table scan, добавление NOT NULL без default).
2. Совместимость со старым кодом (что будет, если миграция применена, а старый код ещё крутится?).
3. Стратегия отката (есть ли .down.sql и работает ли она?).
4. Размер таблицы: 50M строк — это допустимая операция или нужно бить на чанки?
Дай вердикт safe/risky/dangerous + почему.

50. Ревью на соответствие CLAUDE.md / AGENTS.md

Прочитай @CLAUDE.md (или AGENTS.md) — это конвенции проекта.
Затем — @diff.patch.
Найди:
1. Места, где PR нарушает наши конвенции (стиль, naming, импорты, тесты).
2. Места, где соблюдает, но как-то слабо (например, тест есть, но без edge cases).
3. Места, где конвенция вообще не покрыта (предложи дополнить CLAUDE.md).
Не повторяй то, что в diff и так пройдёт линтер.

Антипаттерны — что точно не работаетСкопировано

Хорошие промпты, половина дела. Вторая половина, перестать делать то, что любая модель ненавидит. По нашему опыту работы с Cursor, Claude Code и Codex в последний год, вот шесть антипаттернов, которые сжигают токены и нервы.

«Сделай хорошо»

Промпт «сделай хорошо», «оптимизируй», «улучши код», «сделай быстрее» — это инструкция без критерия успеха. Модель сделает что-то, но вы не поймёте, лучше ли стало. Всегда добавляйте измеримый критерий: «уменьши количество запросов к БД до одного», «сократи bundle на 200 КБ», «сократи cyclomatic complexity ниже 10».

Контекст копипастой вместо файла

Когда вставляете 400 строк кода в чат, модель видит их без названий файлов, без импортов, без структуры папок. Использует @file.ts в Cursor или читай src/file.ts в Claude Code. Модель понимает контекст лучше, а вы экономите токены.

Несколько задач в одном промпте

«Сделай рефакторинг, добавь тесты, обнови документацию и закоммить», здесь четыре задачи. Модель либо сделает только первую, либо всё сразу плохо. Разделяйте по одному действию за раз. Лучшая модель всё равно не вытянет четыре в один проход.

Отсутствие критерия «когда задача готова»

Без «done definition» модель не знает, когда остановиться. Закладывайте в промпт: «задача считается выполненной, когда тесты зелёные и npm run typecheck проходит». Или «когда я скажу OK». Это даёт модели сигнал остановки и не приведёт к over-engineering.

Запрет на уточняющие вопросы

«Делай, не спрашивай», популярная установка, которая стоит часов. Если модель не уверена, она угадает, и угадает в 9 случаях из 10 не туда. Лучше: «если у тебя меньше 90 % уверенности в любом шаге, остановись и задай вопрос мне».

Кормление модели старой версией модели

В статьях двухлетней давности до сих пор пишут промпты под GPT-4 или Claude 3.5 Sonnet. Промпты, которые работали тогда, на Claude Opus 4.7 и Sonnet 4.6 не всегда оптимальны: новые модели лучше понимают неявные намерения и хуже, шаблонные «магические фразы». Перепроверяйте свои промпт-библиотеки раз в полгода.

Что делать с этой библиотекой дальшеСкопировано

Сохраните себе те 5-10 промптов, которые покрывают 80 % вашей работы, и вынесите их в CLAUDE.md, .cursorrules или AGENTS.md вашего проекта. Тогда модель будет применять их без напоминаний. Сложные многоступенчатые сценарии можно завернуть в Skills или slash-команды Claude Code, тогда вместо длинного промпта будет один токен /refactor или /review.

Если работаете в команде, договоритесь про общий набор промптов. Это снижает разброс в качестве: один разработчик не будет получать аккуратный PR, а другой, разваленный, только потому что один знает магическую фразу, а второй нет. Подробнее про настройку командной работы, в статье про subagents в Claude Code и hooks.

Эта статья, спутник к большому материалу про вайбкодинг: там разобраны основы подхода, выбор инструмента, настройка окружения и первый рабочий цикл. Если только начинаете, читайте сначала её, потом возвращайтесь сюда за конкретными промптами.

Где научиться промпт-инжинирингу системноСкопировано

Промпты по статьям и Telegram-каналам — это лоскутное одеяло. Чтобы понять, почему одни формулировки работают, а другие нет, и уметь строить промпты под свою задачу, а не копировать чужие, стоит сесть на нормальный курс. В нашей подборке 33 программы по промпт-инжинирингу от коротких 2-недельных интенсивов до годовых треков с портфолио и стажировкой.

Больше программ — в полном каталоге курсов по промпт-инжинирингу

Если интересует более широкая тема, нейросети и AI в целом, агенты, разработка, ML, у нас собрана подборка из 316 курсов про нейросети и искусственный интеллект. И отдельно, подборка курсов по инструментам: Cursor и Claude.

А если вы не программист, но хотите подключить AI к своей работе, загляните в статью Claude Code для не-программистов: там разобрано 10 реальных кейсов из маркетинга, аналитики и редакции.