Единица работы с Claude Code - не prompt и не diff, а контракт результата. Агент работает тем лучше, чем меньше запрос диктует алгоритм печатания кода и чем яснее описывает, каким должно стать наблюдаемое поведение и как это проверить. Расплывчатое "сделай авторизацию лучше" не даёт ни цели, ни границ, ни критерия - и почти гарантированно приводит к дрейфу: агент меняет много, а проверить нечего.

Минимальный контракт состоит из пяти частей. Цель - какое наблюдаемое поведение должно измениться. Контекст - где проявляется проблема и как её воспроизвести. Границы - что нельзя менять и какие интерфейсы сохранить. Проверка - тест, команда, UI-сценарий или метрика успеха. Отчёт - изменённые файлы, команды, коды возврата, риски. Эти пять пунктов превращают пожелание в задачу, у которой есть однозначный признак выполнения.

Разница между слабым и рабочим запросом видна на примере. "Сделай авторизацию лучше" - это не задача. "Исправь refresh-token race в src/auth без изменения публичного API; сначала воспроизведи ошибку тестом с двумя параллельными запросами, сохрани формат cookies, после фикса прогони focused-тест, общий auth-suite и typecheck, в конце перечисли файлы, команды с exit codes и что осталось непроверенным" - это контракт с целью, границами и проверкой.

Полезно один раз увидеть шаблон минимального контракта, чтобы держать его перед глазами при постановке задачи. Ниже - пять строк, из которых собирается любой рабочий запрос. К этому шаблону возвращаются каждый раз, когда рука тянется написать одну расплывчатую фразу: пять минут на формулировку контракта дешевле, чем оценка красивого, но неверного diff, к которому привёл запрос без критерия.

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

Discovery и implementation стоит разделять, оставляя себе точку контроля. Длинный запрос может содержать фазы - исследование без записи, план с затронутыми файлами, подтверждение, реализация, проверка, review diff, - но переход между ними должен оставаться за вами. Plan mode технически ограничивает правки, но не заменяет ясную задачу; напротив, хороший контракт полезен и в обычном режиме, где никакой переключатель агента не сдерживает.