Агент в Claude Code: проверяем продуктовый бриф перед разработкой
Помощник для продакта в Claude Code: найдёт пробелы в брифе, подготовит вопросы и поможет уточнить задачу для команды. Без программирования.
Перед передачей задачи в разработку продакту полезен второй взгляд: понятно ли, для кого делается функция, какую проблему она решает и как команда поймёт, что всё готово? В Claude Code можно создать отдельного помощника для такой проверки. Он прочитает продуктовый бриф и вернёт вопросы, которые стоит обсудить до начала работы.
Разберём учебный кейс: напоминание пользователям, которые начали оформлять заявку, но не закончили. Писать код не потребуется. Результат — список пробелов в брифе и более точная постановка задачи, а не автоматически принятое продуктовое решение.
Мой подход. Я бы использовал такого помощника перед обсуждением задачи с командой. Его ценность — заметить неясные условия и подготовить хорошие вопросы. Приоритет функции и смысл эксперимента всё равно нужно обсуждать с людьми, которые знают продукт.
1. Подготовь учебный бриф
Если Claude Code ещё не настроен, начни с руководства по настройке проекта. Здесь предполагается, что ты уже можешь открыть рабочую папку и написать запрос Claude Code.
Создай отдельную папку для упражнения и открой в ней Claude Code. Попроси сохранить следующий текст в файл brief.md. Это обычный текстовый документ; расширение Markdown не требует знания программирования.
Сохрани следующий учебный бриф в brief.md без дополнений.
Название: напоминание о незавершённой заявке.
Пользователь: человек, который начал заявку на демо продукта.
Проблема: часть пользователей не заканчивает заполнение.
Решение: отправлять письмо через некоторое время после ухода.
Цель: увеличить количество завершённых заявок.
Содержание: короткое напоминание и ссылка на продолжение.
Успех: конверсия должна заметно вырасти.
Ограничение: не раздражать пользователей.Открой сохранённый документ и проверь, что ИИ ничего не добавил. Здесь намеренно нет точного времени отправки, правил повторного письма и измеримого критерия успеха. Эти пробелы нужны для упражнения. В реальной задаче приложи доступные исследования и правила коммуникаций, чтобы помощник не оценивал бриф вне контекста.
2. Создай помощника простым запросом
Отдельный помощник, или subagent, получает свою инструкцию и набор доступных действий. В Claude Code настройки проектных агентов хранятся в .claude/agents/. Создание файла можно поручить самому Claude: такой способ описан в официальной документации.
Отправь запрос:
Создай в этом проекте агента brief-reviewer для продакт-менеджера.
Сохрани его в .claude/agents/brief-reviewer.md.
Его задача — читать продуктовый бриф перед передачей в разработку.
Разреши только Read, Grep, Glob: инструменты чтения и поиска.
Инструкция агенту:
Проверь аудиторию, проблему, сценарий, границы задачи,
исключения, метрику успеха и критерии приёмки.
Возвращай максимум пять наиболее важных замечаний.
Для каждого приведи фрагмент брифа, объясни риск неясности
и задай конкретный вопрос продакту.
Разделяй противоречия, недостающие решения и необязательные идеи.
Не придумывай исследования, числа, сроки и решения команды.
Если информации недостаточно, прямо обозначь это.
Сам документ не редактируй. Пиши простым русским языком.Попроси Claude показать получившуюся инструкцию и объяснить права агента. В списке действий должны остаться чтение и поиск, без редактирования файлов и выполнения команд. Это ограничение конкретного помощника, а не всего Claude Code.
Начни новую сессию Claude Code в той же папке, чтобы загрузить сохранённого агента. Если агент не обнаруживается, попроси основной Claude проверить расположение файла и его настройки. Самостоятельно разбираться в служебном формате для этого кейса не нужно.
3. Получи вопросы к брифу
Теперь вызови помощника явно:
Используй brief-reviewer для проверки brief.md.
Это ранний бриф перед обсуждением с командой.
Выдели пять решений, без которых нельзя однозначно описать поведение.
Не предлагай новые функции и не меняй файл.Формулировки ответа будут различаться. Оценивай его по содержанию. В нашем учебном брифе полезно найти следующие неопределённости:
| Фрагмент | Полезный вопрос |
|---|---|
| «Через некоторое время» | Через сколько и от какого события считать время? |
| «После ухода» | Как определить незавершённую заявку и отменить письмо, если её уже отправили? |
| «Не раздражать» | Как часто можно напоминать и кому нельзя отправлять письмо? |
| «Ссылка на продолжение» | Что человек увидит после перехода, сохранятся ли заполненные данные? |
| «Конверсия заметно вырастет» | Что считаем конверсией, с чем сравниваем и когда принимаем решение? |
Это эталон вопросов для упражнения, а не отчёт о проведённом запуске агента. Хорошее замечание связано с исходным текстом и помогает принять решение. Фраза «нужно улучшить UX» без конкретного вопроса почти бесполезна. Предложение сразу добавить SMS и пуши расширяет задачу, хотя для проверки брифа этого не просили.
Проверь отсутствие выдумок. Если помощник пишет «пользователи жалуются на письма», в приложенных материалах должно быть основание. Иначе попроси заменить утверждение вопросом или гипотезой.
4. Уточни решения и проверь снова
Ответь на вопросы самостоятельно или вместе с командой. Для продолжения упражнения можно принять такие условные решения:
Учебные решения, не рекомендации для любого продукта:
Письмо отправляем один раз через 24 часа после начала заявки.
Перед отправкой проверяем, что заявка ещё не завершена.
Исключаем пользователей, которым нельзя отправлять такие письма
по действующим правилам коммуникаций продукта.
Ссылка открывает сохранённую заявку после необходимой авторизации.
Тестируем только email, без SMS и пушей.
Метрика: доля начавших заявку, завершивших её за 7 дней.
Сравнение: группа с напоминанием и группа без него.
Порог успеха, размер групп и срок эксперимента ещё не согласованы.Попроси основной Claude добавить решения в бриф, сохранив нерешённые вопросы явно. Снова вызови brief-reviewer: попроси указать, какие прежние замечания закрыты, а какие остаются. Помощник должен заметить уточнение времени и однократной отправки, но не объявлять эксперимент полностью готовым: условия принятия решения ещё не определены.
Для передачи в разработку отдельно попроси черновик критериев приёмки. Например: завершивший заявку до отправки не получает напоминание; повторное письмо по той же заявке не отправляется; ссылка ведёт к нужной заявке. Сверь каждый критерий с решениями команды — агент может помочь сформулировать проверку, но не должен незаметно добавить новые требования.
Если задача разовая, подобную проверку можно провести и в обычном чате. Отдельный агент удобен, когда ты регулярно проверяешь брифы по одним правилам. После нескольких применений оставь в инструкции только полезные требования. Для сравнения редакций документа пригодится разбор Claude, а для проверки самой идеи — сценарий валидации с ИИ.
Собери своего ИИ-агента и проверь результат
«AI Agents: от vibe coding к AI-команде»: desktop agents, MCP, skills, evals и harness. Отдельные воркшопы — от подключения инструментов до контроля качества.
7 практических воркшопов · записи · вопросы автору в чате
Посмотреть программу курса ↗