Перестань объяснять одно и то же с нуля. Держи под рукой несколько проверенных шаблонов под частые задачи — фича, баг, ревью, рефакторинг, доки — и подставляй конкретику. Внутри готовые промты и правила, чтобы они работали.
Хороший вайбкодер отличается от плохого не тем, что знает секретные слова, а тем, что ставит задачу понятно. Со временем замечаешь: одни и те же типы работ повторяются — написать фичу, разобраться с багом, отревьюить чужой код. Под каждый такой тип есть формулировка, которая стабильно даёт хороший результат. Собрать их в личную библиотеку — и есть весь секрет. Ниже — рабочие шаблоны и логика, по которой они устроены.
Что узнаешь из гайда
Часть 1 · Основа
Главное
Рабочий промт держится на четырёх частях: контекст, задача, ограничения, критерий готовности. Убери любую — и агент начнёт додумывать, а додумывает он не всегда в твою сторону.
Разберём по частям. Контекст — где это происходит: какой файл, какая фича, что вокруг. Задача — что конкретно сделать. Ограничения — чего не трогать, в каком стиле, какие правила соблюсти. Критерий готовности — как понять, что задача решена: тест зелёный, страница открывается, число сходится. Эти четыре блока и есть скелет любого шаблона ниже.
| Плохо | Хорошо |
|---|---|
| «Сделай форму» | «Добавь форму логина в src/auth с валидацией email, в стиле соседних компонентов» |
| «Почини баг» | «Вот ошибка и шаги воспроизведения. Найди причину, минимальный фикс, проверь» |
| «Улучши код» | «Раздели этот файл по ответственности, поведение не меняй, тесты должны остаться зелёными» |
Агент не читает мысли. Он читает промт. Что вписал — то и получил.
Часть 2 · Создание
Главное
Для новой логики проси сначала тест, потом код. Так у задачи появляется чёткий критерий готовности — зелёный тест, а не «вроде работает».
Это самый ходовой шаблон. Он заставляет агента сначала зафиксировать ожидаемое поведение, а уже потом писать реализацию под него. Подставь в квадратные скобки своё:
Нужна фича: [что должно делать].
Контекст: [файл/модуль, где это живёт].
Сначала напиши падающий тест на ожидаемое поведение.
Потом — минимальную реализацию, чтобы тест стал зелёным.
Не трогай [что нельзя трогать]. Стиль — как в соседних файлах.
В конце прогони тесты и покажи результат.Почему это работает: ты задал критерий готовности (зелёный тест) и ограничения (что не трогать), а агент не может схалтурить — результат проверяемый. Подробнее про цикл «тест → код» — в гайде про TDD с Claude Code.
Часть 3 · Проверка
Главное
Для бага дай ошибку и шаги воспроизведения и проси искать причину, а не латать симптом. Для ревью — точку входа (дифф или файл) и на что смотреть.
Главная ловушка отладки — когда агент гасит симптом, не найдя причину. Шаблон явно требует корневую причину и минимальный фикс:
Баг: [что происходит вместо ожидаемого].
Ошибка: [текст ошибки/лог].
Шаги воспроизведения: [1, 2, 3].
Найди корневую причину, не гаси симптом.
Предложи минимальный фикс. Объясни, почему ломалось.
Проверь, что фикс не задел соседнее поведение.Для ревью важно задать, на что смотреть, иначе агент расскажет про всё и ни про что:
Отревьюй изменения: [дифф / файл / ветка].
Смотри на: логику, обработку ошибок, граничные случаи, безопасность.
Не переписывай — отметь проблемы по убыванию важности.
По каждой: где, чем плохо, как починить.Важно
Не сваливай в один промт «и почини, и отрефактори, и доки напиши». Один промт — одна задача. Смешанные задачи агент делает хуже: контекст размывается. Отдельные шаблоны для отладки и ревью разобраны в гайдах про отладку и про код-ревью.
Часть 4 · Поддержка
Главное
Для рефакторинга главное правило — поведение не меняется, и это надо вписать в промт явно. Для доков — задать читателя и не давать выдумывать то, чего в коде нет.
Отрефактори [файл/функцию]: [что не так — длинно, дублируется, путано].
Поведение не меняй. Тесты должны остаться зелёными на каждом шаге.
Иди маленькими шагами, не переписывай всё разом.
Если тестов нет — сначала предложи их добавить как сеть безопасности.Напиши [README / комментарии / докстринги] для [что].
Читатель: [новичок в проекте / коллега / будущий я].
Опиши только то, что реально делает код — не выдумывай.
Коротко и по делу. Примеры команд, если уместно.Коротко
Часть 5 · Хранение
Главное
Промт, который набираешь часто, превращай в slash-команду (.claude/commands). Постоянный подход к типу задач — в скил. Разовое — просто пиши в чат.
Не держи шаблоны в голове и в случайных заметках — они теряются. Логика простая: чем чаще используешь промт, тем «ближе к рукам» его держи. Часто набираемый шаблон оформляется кастомной slash-командой: кладёшь файл в .claude/commands, и теперь шаблон вызывается одной командой с подстановкой аргументов.
# Кладём шаблон отладки в команду проекта
mkdir -p .claude/commands
# Внутри .claude/commands/fix.md — текст промта с подстановкой $ARGUMENTS.
# Дальше в чате: /fix [описание бага] — и шаблон подставится сам.Как именно устроены такие команды (аргументы через $ARGUMENTS, вывод bash, настройки) — в отдельном гайде про кастомные slash-команды. А если это не разовый шаблон, а постоянный подход — заведи скил, и Claude будет подключать его сам по описанию, без явного вызова.
Готовая база
Не хочешь собирать с нуля — можно подсмотреть готовые. В маркетплейсе скилов ИИ-офиса лежат тысячи готовых навыков по разработке, ревью, документации и данным: ставишь, смотришь как устроено, и на этой базе собираешь свой набор формулировок.
Когда шаблон мешает
Шаблон — это рамка, а не замена мышлению. Если задача нетиповая, шаблон только сожмёт её в неподходящую форму — пиши промт под неё с нуля. И не превращай шаблоны в простыни на двести слов: длинный промт размывает фокус. Держи их короткими и затачивай под себя, а не копируй чужие вслепую.
Коротко
.claude/commands.Вопросы
Готовый промт — это заранее собранный шаблон постановки задачи под повторяющийся тип работы: написать фичу, отладить ошибку, отревьюить дифф. Ты держишь несколько проверенных формулировок и подставляешь в них конкретику задачи, вместо того чтобы каждый раз заново объяснять с нуля. Это экономит время и даёт стабильно предсказуемый результат.
Хороший промт даёт контекст, конкретную цель и критерий готовности. Скажи, что и где сделать, на какой результат рассчитываешь и как проверить, что задача решена. Размытое «почини баг» работает плохо — дай ошибку, шаги воспроизведения и ожидаемое поведение. Чем точнее вход, тем меньше итераций. Подробно про это — в гайде про постановку задач.
Повторяющиеся промты удобно хранить как кастомные slash-команды в папке .claude/commands — тогда шаблон вызывается одной командой с подстановкой аргументов. Разовые формулировки можно держать в заметках или в файле проекта. А постоянный подход к задаче лучше оформить скилом, который Claude подключает сам по описанию.
Промт ты пишешь руками в чате под конкретную задачу, slash-команда — это сохранённый промт, который вызывается явно, а скил Claude подключает сам по описанию. Промт живёт одну сессию. Если одну и ту же формулировку набираешь часто — заведи slash-команду; если это постоянный подход к типу задач — заведи скил.
Читать дальше
Прикладной материал, разборы и рабочие приёмы — то, чем пользуюсь сам, без воды. Залетай, там самое полезное.
Зайти в Telegram