Промптотека

Готовые формулировки. Копируйте, подставляйте своё в <...>. Каждый промпт построен по схеме: контекст → задача → ограничения → формат → запрет.

1. Стартовые

1.1 План без правок

Прочитай <путь/файлы>. Задача: <одно предложение>.
Покажи план из 4–6 шагов, каждый с проверяемым результатом.
Файлы не меняй, код не пиши. Жду подтверждения плана.

1.2 Онбординг в чужой проект

Это проект <название>. Прочитай README, package.json/pyproject.toml и структуру папок.
Ответь: стек, как запустить, как тестировать, 3 самых важных файла, 3 непонятных места.
Файлы не меняй.

1.3 Инструкция проекта

Создай AGENTS.md со стеком, командами запуска/тестов/линта, правилами стиля и
запретами (не править тесты, не менять legacy, не добавлять зависимости без
согласия). Основано на реальном содержимом проекта, без домыслов.

2. Постановка задачи

2.1 Спека из сырой идеи

Идея: <как есть, сумбурно>.
Преврати в спеку: цель, пользователь и сценарий, входы/выходы с примерами,
edge-кейсы (пусто, очень много, неверный тип), ограничения, 4 критерия приёмки
(проверяемые да/нет), что НЕ делаем.
Не пиши код. Максимум 15 строк.

2.2 Проверка спеки на дырки

Вот спека. Найди 5 мест, где исполнитель будет угадывать: неоднозначные
формулировки, отсутствующие edge-кейсы, непроверяемые критерии.
Только список проблем, без переписывания.

2.3 Декомпозиция

Разбей задачу на шаги по 15–20 минут работы агента. Для каждого: название,
файлы, критерий приёмки, что не трогать. Шагов не больше 6.
Не пиши код.

2.4 Критерий приёмки → /goal

/goal <команда тестов> выходит с кодом 0, <линт> чист,
git diff --name-only показывает только <папка>/, или стоп после <N> ходов

Требования: измеримый признак, доказательство в выводе сессии, границы по файлам, лимит ходов. Снять гол: /goal clear. Статус: /goal без аргументов.

2.5 Проверка критерия на пригодность для /goal

Вот критерий приёмки: <текст>. Проверь его на три вещи: (1) можно ли проверить
командой или кодом возврата, (2) увидит ли доказательство агент в своём выводе,
(3) какие файлы надо явно запретить менять. Если критерий непроверяем —
переформулируй в проверяемый и покажи разницу.

3. Реализация

3.1 Минимальная правка

В <файл>, функция <имя>: <что изменить>.
Требования: <точное поведение, включая границы>.
Только этот файл. Не рефакторить, не менять форматирование, не добавлять
зависимостей. После правки покажи дифф и вывод проверки.

3.2 Новый модуль

Создай <файл> с <функция/класс>, который <поведение>.
Вход: <тип, пример>. Выход: <тип, пример>. Ошибки: <какие и как>.
Стиль как в <соседний файл>. Без новых зависимостей. Добавь 2 теста:
главный сценарий и <граница>.

3.3 Работа по тесту

Тест: <код теста>. Он падает. Реализуй минимальный код, чтобы он прошёл.
Тест не менять. Не добавлять функциональность сверх теста.
Покажи вывод теста после правки.

3.4 Продолжение после паузы

Состояние: сделано <A, B>, коммит <hash>. Осталось <C>.
Задача сейчас: только <C>. Контекст: <файлы>.
Не пересматривай решения по A и B.

4. Проверка и ревью

4.1 Самопроверка перед сдачей

Проверь свою правку по списку и ответь по пунктам:
1) удалены ли проверки/валидация; 2) нет ли тихого catch/except; 3) нет ли
хардкода и магических констант; 4) тронуты ли файлы вне задачи; 5) добавлены ли
зависимости; 6) изменены ли тесты.
Код не меняй, только отчёт.

4.2 Объясни решение

Объясни в 5 строках: почему выбрано это решение, какие альтернативы
рассматривались, какие компромиссы приняты. Код не меняй.

4.3 Проверка критериев приёмки

Вот критерии приёмки: <список>. По каждому: выполнен / не выполнен / не проверял,
и как именно проверить командой. Код не меняй.

5. Отладка

5.1 Факт, потом гипотеза

Ошибка: <симптом>. Стектрейс:
<вставить>
Сначала процитируй 3 строки стектрейса, которые указывают на наш код.
Затем предложи 3 гипотезы. Для каждой — команда проверки.
Правок не делай, пока я не выберу.

5.2 Против угадывания

Ты предлагаешь причину, не проверив. Ответь: какие данные подтверждают это?
Какая команда это подтвердит или опровергнет? Если проверка невозможна — скажи прямо.

5.3 Минимальный кейс

Сократи проблему до минимального воспроизводимого примера: 10–15 строк,
без нашего проекта, только стандартная библиотека. Покажи его и ожидаемое/реальное.

5.4 Тупик

Две попытки не сдвинули проблему. Останавливаемся.
Сформулируй: что точно известно, что проверено, что осталось непроверенным,
какие 2 варианта есть. Правок не делай — я решу, откатывать или продолжать.

5.5 Версия библиотеки

Стек: <библиотека> версии <X> (из package.json). Используй только API этой версии.
Если не уверен, что API существует в этой версии — скажи об этом, а не угадывай.

6. Тесты

6.1 Тест до кода

Напиши тест на поведение: <описание>. Тест должен падать сейчас.
Не реализуй функциональность. Покажи, что он падает, и по какой причине.

6.2 Проверка теста на прочность

Сломай реализацию так, чтобы <поведение> перестало работать. Тесты не правь.
Скажи, какие тесты упали. Если ни один не упал — тесты бесполезны, скажи это прямо.

6.3 Запрет на правку тестов

Тесты — спецификация. Если тест падает, чини реализацию. Менять тест нельзя.
Если считаешь ожидание в тесте неверным — объясни почему и жди моего решения.

6.4 Границы

Добавь тесты на границы для <функция>: пустой вход, один элемент, максимум,
неверный тип, отсутствующее поле. По одному тесту на кейс, названия говорящие.

7. Данные и API

7.1 По реальному ответу

Вот реальный ответ API (сокращён):
<вставить>
Используй только эти поля и эту структуру. Не придумывай поля, которых нет.
Сделай клиент с валидацией и обработкой 4xx/5xx/таймаут/невалидный JSON.

7.2 Секреты

Ключи только через переменные окружения. Добавь .env.example с именами без
значений. Убедись, что .env в .gitignore и не попал в историю git.
Если ключ уже в истории — скажи, что нужен отзыв ключа.

7.3 Валидация на границе

Добавь валидацию входных данных на границе через <zod/pydantic>:
обязательные поля, типы, ограничения. На невалидных данных — 400 с понятным
текстом, без падения. Плюс 3 теста на плохие данные.

8. Деплой и гигиена

8.1 Первый деплой

Подготовь проект к деплою на <Vercel/Netlify>: проверь команду сборки и выходную
папку, перечисли переменные окружения для панели, укажи версию рантайма.
Ничего не выдумывай про настройки — если не уверен, скажи, что проверить руками.

8.2 Чек-лист перед мерджем

Пройди по PR <номер> и ответь по каждому пункту: проверки не ослаблены, тесты
не менялись, нет тихих catch, нет секретов, нет хардкода путей, нет новых
зависимостей без обоснования, нет SQL-конкатенации, нет правок вне задачи.
Формат: пункт — ок / проблема (файл:строка).

8.3 Сообщение коммита / описание PR

Сделай сообщение коммита в формате тип(область): что сделано, до 70 символов.
И описание PR: что меняется, зачем, как проверить (шаги), что не входит,
какие компромиссы приняты. По диффу, без домыслов.

9. Перезапуск сессии

9.1 Чистый старт

Новая сессия. Контекст: <проект, стек, 3 важных файла>.
Проблема: <симптом>. Проверено: <факты>. Не проверено: <...>.
Стектрейс: <...>.
Предложи 3 гипотезы с командой проверки. Правок не делай.

9.2 Передача состояния

Итог сессии: сделано <...>, коммиты <hash...>, осталось <...>.
Открытые вопросы: <...>. Известные ограничения: <...>.
Сохрани это в notes/session-<дата>.md, чтобы продолжить завтра.

10. Антипаттерны: как не надо