Вы просите Claude Code исправить ошибку при оформлении заказа. Он изменяет нужный файл и сообщает, что тесты прошли успешно. Но тесты никогда не покрывали просроченный купон, вызвавший эту ошибку, поэтому вы все еще не знаете, работает ли исправление.
Полезный промпт дает Claude Code достаточно информации для устранения этого пробела: ожидаемое поведение, соответствующие файлы, любые ограничения на изменения и проверяемые доказательства. Для исправления ошибки это может означать воспроизведение сбоя до изменения кода. Для вопроса по кодовой базе это может означать указание файлов и функций, стоящих за ответом.
25 промптов для Claude Code, приведенных ниже, охватывают планирование, отладку, код-ревью, миграции и другие повторяющиеся задачи. Каждый из них дает отправную точку для адаптации под ваш репозиторий, с рекомендациями о том, что предоставить и как оценить результат.
Кратко (TL;DR): дайте Claude Code четкую задачу, соответствующий контекст репозитория и строгие ограничения на то, что может быть изменено. Для изменения кода укажите тесты или другие проверки; для исследований и планирования запросите ссылки на источники или план, доступный для проверки. Адаптируйте 25 шаблонов под требования и права доступа вашего проекта, а затем изучите доказательства перед принятием работы.
Чем промпт для Claude Code отличается от промпта для чата?
Промпт для Claude Code может санкционировать работу в вашем репозитории, а не просто запрашивать объяснение. В зависимости от его инструментов и прав доступа, Claude может проверять файлы, запускать команды, редактировать код и проверять результаты. Поэтому ваши инструкции должны определять как саму задачу, так и границы работы.
Чат-ассистенты также могут использовать инструменты и предпринимать действия, поэтому разница не в том, что «чат отвечает, а Claude Code действует». Практическая разница заключается в среде и уровне доступа, которые вы предоставляете ассистенту. Просьба предложить исправление в чате оставляет вам задачу применить его; просьба к Claude Code реализовать это исправление может изменить ваши рабочие файлы.
Это меняет последствия нечеткого запроса. Запрос «Исправь оформление заказа» оставляет решения об области действия, ожидаемом поведении и допустимых изменениях нерешенными. Claude может создать правдоподобную реализацию, которую вам затем придется проверять или отменять. Более полезный запрос определяет проблемный случай, то, что должно остаться неизменным, и то, должен ли Claude проводить исследование, планирование или редактирование.
analysis of 500,000 coding-related interactions иллюстрирует эту разницу на практике. Используя данные за апрель 2025 года, он классифицировал 79% разговоров с Claude Code как автоматизацию по сравнению с 49% разговоров в Claude.ai. Эти цифры описывают наблюдаемые паттерны использования, а не фиксированные ограничения любого из продуктов.
В том же исследовании 35,8% взаимодействий с Claude Code были классифицированы как циклы обратной связи, где люди проверяли работу и предоставляли дополнительные вводные данные, такие как сообщения об ошибках. Предоставление Claude подходящей тестовой команды может помочь ему напрямую исследовать сбои. Вам все равно нужно оценить, покрывают ли эти проверки запрошенное вами поведение.
Для Claude Code в промпте должен быть четко обозначен предполагаемый уровень действий: объяснить код, предложить изменения или реализовать их в рамках определенной области. Настройте разрешения отдельно, а затем изучите доказательства, соответствующие этой задаче.
Анатомия хорошего промпта для Claude Code
Хороший промпт для Claude Code объясняет желаемый результат, контекст, необходимый для его получения, и то, как вы будете оценивать работу. Вопрос об одной функции может потребовать только ссылки на файл и запроса объяснения. Изменение в нескольких файлах требует более четких рамок и ограничений.
Включайте эти шесть деталей везде, где это применимо:
- Что (What): Ожидаемое поведение, например, вывод сообщения о недействительном купоне вместо возврата ошибки оформления заказа
- Где (Where): Файлы, папки или службы в зоне видимости, на которые ссылаются с помощью @, когда они вам известны
- Паттерн (Pattern): Существующая реализация, которой должен следовать Claude, например, API-клиент вашего проекта или соглашения об обработке ошибок
- Верификация (Verification): Команда тестирования или сборки для изменения кода либо ссылки на файлы и ID коммитов для исследований
- Ограничения (Limits): То, что должно оставаться нетронутым, например, публичные API, схемы баз данных или несвязанные модули
- Подход (Approach): Должен ли Claude объяснить, предложить план на рассмотрение или внедрить изменение
Вот как эти детали улучшают три распространенных запроса.
Исправление конкретной ошибки
Вместо: «Исправь ошибку оформления заказа».
Клиенты, использующие просроченный купон, получают ошибку 500 при оформлении заказа. Проверьте @src/checkout/coupons.ts и связанные с ним тесты. Ожидаемое поведение — вывод сообщения о недействительном купоне без создания заказа. Напишите падающий тест, который воспроизводит ошибку, а затем исправьте ее, не меняя поведение для действительных купонов. Запустите [checkout test command] и покажите результаты до и после. Если вы не можете воспроизвести ошибку, сообщите, что вы проверяли перед изменением реализации.
Клиенты, использующие просроченный купон, получают ошибку 500 при оформлении заказа. Проверьте @src/checkout/coupons.ts и связанные с ним тесты. Ожидаемое поведение — вывод сообщения о недействительном купоне без создания заказа. Напишите падающий тест, который воспроизводит ошибку, а затем исправьте ее, не меняя поведение для действительных купонов. Запустите [checkout test command] и покажите результаты до и после. Если вы не можете воспроизвести ошибку, сообщите, что вы проверяли перед изменением реализации.
Добавление функции с использованием существующего паттерна
Вместо: «Добавь выбор даты».
Добавьте выбор даты в [booking form path]. Следуйте соглашениям о компонентах и валидации в @src/components/TimeSelect.tsx. Пользователи должны иметь возможность выбирать [allowed dates], в то время как [unavailable dates] должны оставаться недоступными. Не добавляйте сторонние библиотеки. Запустите [component test command] и [type-check command] и сообщите о любых критериях, которые эти проверки не покрывают.
Добавьте выбор даты в [booking form path]. Следуйте соглашениям о компонентах и валидации в @src/components/TimeSelect.tsx. Пользователи должны иметь возможность выбирать [allowed dates], в то время как [unavailable dates] должны оставаться недоступными. Не добавляйте сторонние библиотеки. Запустите [component test command] и [type-check command] и сообщите о любых критериях, которые эти проверки не покрывают.
Рефакторинг без изменения поведения
Вместо: «Наведи порядок в этом файле».
Разбейте @src/reports/export.py на более мелкие функции, сохранив при этом его входные данные, формат вывода и поведение при ошибках. Запустите [export test command] перед редактированием и сообщите о любых существующих сбоях. После рефакторинга перезапустите тесты и покажите оба результата. Не изменяйте публичный интерфейс или несвязанные файлы.
Разбейте @src/reports/export.py на более мелкие функции, сохранив при этом его входные данные, формат вывода и поведение при ошибках. Запустите [export test command] перед редактированием и сообщите о каких-либо существующих сбоях. После рефакторинга перезапустите тесты и покажите оба результата. Не изменяйте публичный интерфейс или несвязанные файлы.
Замените примеры путей и команд значениями из вашего репозитория. Успешно проходящие тесты служат доказательством для случаев, которые они покрывают; просмотрите diff и убедитесь, что эти случаи соответствуют требованиям.
Эти примеры адаптируют подход ограниченных запросов из рекомендаций по лучшим практикам использования Claude Code от Anthropic. Дополнительные рекомендации, выходящие за рамки написания кода, см. в этих лучших практиках создания промптов для ИИ-агентов.
Почему проверка важнее формулировки
Даже подробный промпт может привести к созданию кода, который решает не ту задачу. Вы можете указать файлы, стиль кодирования и желаемый результат, но при этом упустить условие, определяющее, является ли изменение полезным. В случае с багом просроченного купона утверждение «тесты оформления заказа проходят» является неполным свидетельством, если эти тесты не охватывают неработающий купон и не подтверждают, что заказ не был создан.
Формулировка помогает Claude понять запрос. Проверка позволяет оценить, соответствует ли ей реализация. Это различие имеет значение, когда Claude может редактировать файлы и выполнять команды: убедительное объяснение изменения не является доказательством того, что поведение корректно.
Руководство по лучшим практикам Anthropic’s Claude Code рекомендует давать Claude возможность проверять свою работу с помощью тестов, скриншотов или ожидаемых результатов. Проверка должна отражать требования. Сборка проверяет, компилируется ли проект; целенаправленный тест проверяет определенное поведение; сравнение скриншотов помогает оценить отрисованный интерфейс. Каждый из них отвечает на свой вопрос.
Борис Черный, создатель Claude Code, описывает использование цикла обратной связи на основе браузера в своем собственном рабочем процессе:
«Claude тестирует каждое отправленное мной изменение в claude.ai/code с помощью расширения Claude Chrome. Он открывает браузер, тестирует пользовательский интерфейс и повторяет процесс до тех пор, пока код не заработает, а пользовательский опыт не станет хорошим».
«Claude тестирует каждое отправленное мной изменение в с помощью расширения Claude Chrome. Он открывает браузер, тестирует пользовательский интерфейс и повторяет процесс до тех пор, пока код не заработает, а пользовательский опыт не станет хорошим».
В отчете InfoQ о рабочем процессе Черного сообщается его мнение о том, что верификация может повысить качество результатов в два-три раза. Это субъективная оценка его рабочего процесса, а не контролируемое измерение или гарантированное улучшение.
Сохраняйте ответственность за требования и критерии приемки
Делегирование реализации все равно оставляет за вами ответственность за принятие решений о том, что должно делать программное обеспечение. Claude может предложить тесты, но эти тесты должны отражать ваши бизнес-правила, включая исключения, которые могут быть неочевидны из кода.
В своем исследовании компания Anthropic выяснила, что люди принимают около 70% решений по планированию, но лишь около 20% решений по исполнению. Исследование также связало более высокую предполагаемую экспертную оценку в конкретных задачах с более высокими показателями успешности прохождения верификации: около 15% для сессий, оцененных как новичок, по сравнению с 28%–33% для сессий среднего уровня или экспертных сессий.
Эти цифры требуют контекста. Экспертиза оценивалась по стенограммам, а «успешное прохождение верификации» требовало доказательств успеха в рамках сессии. Anthropic не наблюдала реальных результатов пользователей. Сессии без такого сигнала не обязательно были неудачными, и исследование не доказывает, что изменение формулировки промпта само по себе улучшает результаты.
Практический вывод заключается в том, чтобы предоставлять ту информацию, которую Claude не может безопасно вывести самостоятельно. Бухгалтер, сверяющий счета, должен указать, как должны обрабатываться частичные платежи, возвраты и округление. Разработчик, изменяющий поведение оформления заказа, должен определить, какое существующее поведение должно остаться неизменным. Эти решения определяют, проверяют ли получившиеся тесты то, что нужно.
Прежде чем принять изменения, рассмотрите требование, реализацию и доказательства в совокупности. Спросите, какие случаи были протестированы, какие проверки не прошли или были пропущены и что остается неопределенным. Это дает вам основание для принятия работы, выходящее за рамки заявления Claude о том, что она завершена.
25 промптов для Claude Code, которые можно скопировать и адаптировать
Выберите промпт в зависимости от задачи, которую вам нужно решить, а затем замените детали в квадратных скобках путями к вашему репозиторию, требованиями и командами. Для изменения кода укажите команду теста или сборки. Для исследований и планирования запросите ссылки на источники и четко определенный результат.
Эти шаблоны описывают работу, которую вы хотите поручить Claude. Настройте разрешения Claude Code отдельно; инструкция вроде «не редактируй файлы» не заменяет средства контроля доступа.
Промпты для понимания кодовой базы
Прежде чем менять незнакомый код, выясните, где находится соответствующее поведение и как оно работает. Эти промпты сосредоточены на чтении файлов и истории без внесения изменений.
1. Получите обзор незнакомого репозитория
Используйте это при присоединении к проекту или работе в репозитории впервые. Начните с файла README, конфигурации проекта и структуры каталогов, а не просите Claude читать каждый файл.
Изучите README, конфигурацию проекта и структуру корневого каталога этого репозитория. Переходите по ссылкам только по мере необходимости, чтобы объяснить: Что делает приложение Его основные точки входа и основные компоненты Где находятся тесты и какие команды репозиторий определяет для их запуска Приведите пути к файлам, подтверждающие ваше объяснение. Различайте задокументированное поведение и ваши собственные выводы, а также отмечайте все, что вы не можете определить. Не читайте секреты или файлы окружения, не проверяйте установленные зависимости и не изменяйте файлы. Завершите ответ указанием трех файлов, которые я должен прочитать в первую очередь, и объясните почему.
Изучите README, конфигурацию проекта и структуру корневого каталога этого репозитория. Переходите по ссылкам только по мере необходимости, чтобы объяснить: Что делает приложение Его основные точки входа и основные компоненты Где находятся тесты и какие команды репозиторий определяет для их запуска Приведите пути к файлам, подтверждающие ваше объяснение. Различайте задокументированное поведение и ваши собственные выводы, а также отмечайте все, что вы не можете определить. Не читайте секреты или файлы окружения, не проверяйте установленные зависимости и не изменяйте файлы. Завершите ответ указанием трех файлов, которые я должен прочитать в первую очередь, и объясните почему.
2. Понять, почему изменилась реализация
Используйте историю Git для исследования проектного решения перед его заменой. Запросите зарегистрированные доказательства, а не предполагайте, что текущий код отражает первоначальное намерение автора.
Изучите историю Git для [файла, функции или класса], сосредоточившись на [поведении или вопросе проектирования]. Определите коммиты, которые внесли или существенно изменили это поведение. Для каждого соответствующего коммита укажите его хеш, резюме изменения и объясните любое обоснование, задокументированное в сообщении коммита или связанном обсуждении, к которому у вас есть доступ. Обозначьте предполагаемые причины как выводы. Если история не объясняет решение, так и скажите. Не изменяйте файлы или историю Git.
Изучите историю Git для [файла, функции или класса], сосредоточившись на [поведении или вопросе проектирования]. Определите коммиты, которые внесли или существенно изменили это поведение. Для каждого соответствующего коммита укажите его хеш, резюме изменения и объясните любое обоснование, задокументированное в сообщении коммита или связанном обсуждении, к которому у вас есть доступ. Обозначьте предполагаемые причины как выводы. Если история не объясняет решение, так и скажите. Не изменяйте файлы или историю Git.
3. Отследить определенный поток приложения
Используйте это перед изменением поведения, затрагивающего несколько компонентов, таких как аутентификация, оформление заказа или уведомления.
Отследите, что происходит при [действие пользователя или системное событие], начиная с [известный маршрут, обработчик или папка]. Проследите соответствующие вызовы через валидацию, бизнес-логику и любые записи в базу данных или внешние запросы. Перечислите файлы и функции в порядке выполнения, указав по возможности ссылки на строки. Объясните основные пути возникновения сбоев и укажите существующие тесты, покрывающие этот сценарий. Отметьте любые связи, которые вы не можете подтвердить по коду. Не выполняйте сценарий, не вызывайте внешние службы и не редактируйте файлы.
Отследите, что происходит при [действие пользователя или системное событие], начиная с [известный маршрут, обработчик или папка]. Проследите соответствующие вызовы через валидацию, бизнес-логику и любые записи в базу данных или внешние запросы. Перечислите файлы и функции в порядке выполнения, указав по возможности ссылки на строки. Объясните основные пути возникновения сбоев и укажите существующие тесты, покрывающие этот сценарий. Отметьте любые связи, которые вы не можете подтвердить по коду. Не выполняйте сценарий, не вызывайте внешние службы и не редактируйте файлы.
Промпты для планирования перед началом разработки
Для изменений, которые затрагивают несколько файлов или оставляют важные требования нерешенными, изучите план перед реализацией. Эти промпты помогут вам сформулировать задачу, прояснить решения и определить затронутый код.
4. Планирование функции перед изменением кода
Используйте это, когда вам известното желаемое поведение, но необходимо понять реализацию. Начните в режиме Plan, чтобы Claude мог изучить репозиторий перед предложением изменений.
Запланируйте реализацию [функция] в [область репозитория]. Ожидаемое поведение: [требования], при этом следующие области должны остаться без изменений: [ограничения]. Изучите соответствующий код и существующие тесты. Определите файлы, которые необходимо изменить, порядок реализации, а также любые риски совместимости или миграции данных. Соотнесите каждое требование с предлагаемым тестом или другим этапом проверки. Перечислите нерешенные вопросы и предположения отдельно. Пока не реализуйте функцию. Верните план для моего рассмотрения.
Запланируйте реализацию [функция] в [область репозитория]. Ожидаемое поведение: [требования], при этом следующие области должны остаться без изменений: [ограничения]. Изучите соответствующий код и существующие тесты. Определите файлы, которые необходимо изменить, порядок реализации, а также любые риски совместимости или миграции данных. Соотнесите каждое требование с предлагаемым тестом или другим этапом проверки. Перечислите нерешенные вопросы и предположения отдельно. Пока не реализуйте функцию. Верните план для моего рассмотрения.
5. Уточнение требований перед написанием спецификации
Используйте это, когда запрос функции оставляет неопределенными вопросы относительно поведения пользователя, данных или крайних случаев. Полученная спецификация должна предоставить последующему сеансу реализации достаточно контекста для продолжения.
Я хочу создать [краткое описание] для [пользователи и сценарий использования]. Сначала прочитайте [релевантные файлы или требования], затем используйте AskUserQuestion, чтобы прояснить решения, которые могут существенно повлиять на реализацию. Сосредоточьтесь на краевых случаях, обработке данных, правах доступа, ожидаемом поведении интерфейса и компромиссах. Не задавайте вопросы, на которые уже есть ответы в предоставленном контексте. После того как ключевые решения приняты, составьте спецификацию, охватывающую требования, критерии приемки, ограничения и то, что не входит в область видимости. Отметьте все оставшиеся предположения. Покажите мне спецификацию перед сохранением в [путь к спецификации] и не перезаписывайте существующий файл без одобрения.
Я хочу создать [краткое описание] для [пользователи и сценарий использования]. Сначала прочитайте [релевантные файлы или требования], затем используйте AskUserQuestion, чтобы прояснить решения, которые могут существенно повлиять на реализацию. Сосредоточьтесь на краевых случаях, обработке данных, правах доступа, ожидаемом поведении интерфейса и компромиссах. Не задавайте вопросы, на которые уже есть ответы в предоставленном контексте. После того как ключевые решения приняты, составьте спецификацию, охватывающую требования, критерии приемки, ограничения и то, что не входит в область видимости. Отметьте все оставшиеся предположения. Покажите мне спецификацию перед сохранением в [путь к спецификации] и не перезаписывайте существующий файл без одобрения.
После рассмотрения и сохранения спецификации сошлитесь на нее в сеансе реализации. Включите соответствующие пути к репозиторию, чтобы Claude мог сверить спецификацию с существующим кодом.
6. Определение того, на что может повлиять изменение общего кода
Используйте это перед изменением общей функции, компонента или интерфейса. Инвентаризация вызывающих объектов помогает оценить масштаб, но может не выявить потребителей за пределами репозитория.
Оцените влияние изменения [функция, компонент или интерфейс] с [текущее поведение] на [предлагаемое поведение]. Выполните поиск [область репозитория или каталога] для его определения, прямых вызовов, импортов и связанных тестов. Перечислите файлы, которые, вероятно, потребуют изменений, и объясните, как каждый из них может пострадать, указав по возможности ссылки на файлы и строки. Отметьте динамически разрешаемые вызовы, внешних потребителей или другие зависимости, которые вы не можете проверить. Выявите любые вопросы совместимости, на которые необходимо ответить до реализации. Не изменяйте файлы; верните оценку влияния и дождитесь моего рассмотрения.
Оцените влияние изменения [функция, компонент или интерфейс] с [текущее поведение] на [предлагаемое поведение]. Выполните поиск [область репозитория или каталога] для его определения, прямых вызовов, импортов и связанных тестов. Перечислите файлы, которые, вероятно, потребуют изменений, и объясните, как каждый из них может пострадать, указав по возможности ссылки на файлы и строки. Отметьте динамически разрешаемые вызовы, внешних потребителей или другие зависимости, которые вы не можете проверить. Выявите любые вопросы совместимости, на которые необходимо ответить до реализации. Не изменяйте файлы; верните оценку влияния и дождитесь моего рассмотрения.
Промпты для создания функций
Промпты для создания функций должны описывать ожидаемое поведение и связывать его с кодом, уже имеющимся в вашем проекте. Включайте релевантные примеры, ограничения и проверки, чтобы Claude мог реализовать изменение, не принимая посторонних решений.
7. Создание функции с использованием существующего паттерна
Используйте это, когда аналогичная функция уже существует в вашем репозитории. Укажите Claude на ту реализацию, которой вы хотите следовать, включая доступ к данным, обработку ошибок и тесты.
Добавьте [функция] в [файл или страница] со следующим поведением: [критерии приемки]. Изучите [существующая реализация] и следуйте ее соглашениям по получению данных, обработке ошибок и организации компонентов. Используйте только библиотеки, уже установленные в проекте. Держите изменения в рамках [область видимости] и сохраняйте [существующее поведение или публичный интерфейс]. Добавьте или обновите тесты для критериев приемки. Запустите [команда тестирования] и [команда проверки типов или линтер], а затем отчитайтесь об измененных файлах, результатах и любых проверках, которые вы не смогли завершить. Если существующий паттерн противоречит какому-либо требованию, объясните конфликт перед продолжением.
Добавьте [feature] в [file or page] со следующим поведением: [acceptance criteria]. Проверьте [existing implementation] и следуйте его соглашениям для получения данных, обработки ошибок и организации компонентов. Используйте только те библиотеки, которые уже установлены в проекте. Ограничьте изменения в рамках [scope] и сохраните [existing behavior or public interface]. Добавьте или обновите тесты для критериев приемки. Запустите [test command] и [type-check or lint command], а затем сообщите об измененных файлах, результатах и любых проверках, которые вы не смогли выполнить. Если существующий паттерн противоречит требованиям, объясните это противоречие перед продолжением.
8. Пишите тесты перед реализацией функции
Используйте это для поведения, которое можно выразить через определенные входные и выходные данные. Первоначальный сбой теста должен указывать на отсутствие нужного поведения, а не на поломку настройки тестов.
Реализуйте [function name] в [file] для удовлетворения [requirements]. Охватите [normal case], [edge case] и [invalid-input behavior]. Сначала запустить [relevant test command] и сообщите о любых существующих сбоях. Напишите тесты для запрошенного поведения, затем запустите их перед реализацией. Убедитесь, что новые тесты падают по ожидаемой причине. Реализуйте функцию и перезапустите тесты. Не ослабляйте утверждения (assertions), не пропускайте тесты и не изменяйте ожидаемое поведение ради их прохождения. Если требования противоречат существующим тестам, остановитесь и объясните это противоречие. Покажите результаты до и после.
Реализуйте [function name] в [file] для удовлетворения [requirements]. Охватите [normal case], [edge case] и [invalid-input behavior]. Сначала запустить [relevant test command] и сообщите о любых существующих сбоях. Напишите тесты для запрошенного поведения, затем запустите их перед реализацией. Убедитесь, что новые тесты падают по ожидаемой причине. Реализуйте функцию и перезапустите тесты. Не ослабляйте утверждения (assertions), не пропускайте тесты и не изменяйте ожидаемое поведение ради их прохождения. Если требования противоречат существующим тестам, остановитесь и объясните это противоречие. Покажите результаты до и после.
9. Реализуйте пользовательский интерфейс по эталонному изображению
Используйте это, когда у вас есть скриншот дизайна и работающий способ зафиксировать реализацию. Укажите маршрут, область просмотра (viewport) и состояние интерфейса, чтобы Claude сравнивал эквивалентные экраны.
Реализуйте прикрепленный дизайн в [component or page], используя существующие компоненты и стили проекта. Сохраните [required behavior] и избегайте изменений за пределами [scope]. Используйте [configured browser or screenshot tool] для захвата [local route] в [viewport dimensions] с [test data and UI state]. Если инструмент или приложение недоступны, сообщите, что именно требуется, вместо того чтобы утверждать, что была проведена визуальная проверка. Сравните полученный снимок с эталоном, уделяя особое внимание [layout, spacing, typography, or other acceptance criteria]. Сделайте до [number] проходов коррекции, затем сообщите об оставшихся различиях. Не изменяйте эталонное изображение. Запустите [relevant component tests] и [type-check or build command]. Включите полученный скриншот и актуальные результаты проверки в свою сводку.
Реализуйте прикрепленный дизайн в [component or page], используя существующие компоненты и стили проекта. Сохраните [required behavior] и избегайте изменений за пределами [scope]. Используйте [configured browser or screenshot tool] для захвата [local route] в [viewport dimensions] с [test data and UI state]. Если инструмент или приложение недоступны, сообщите, что именно требуется, вместо того чтобы утверждать, что была проведена визуальная проверка. Сравните полученный снимок с эталоном, уделяя особое внимание [layout, spacing, typography, or other acceptance criteria]. Сделайте до [number] проходов коррекции, затем сообщите об оставшихся различиях. Не изменяйте эталонное изображение. Запустите [relevant component tests] и [type-check or build command]. Включите полученный скриншот и актуальные результаты проверки в свою сводку.
Промпты для отладки и исправления
10. Воспроизведите баг перед его исправлением
12. Сузьте круг поиска ошибки с помощью вопросов
