--- name: bug-report description: Быстрый баг-репорт в Jira. Вызывай по /bug-report. Собирает данные, показывает превью, создает дефект в Jira после подтверждения. disable-model-invocation: true allowed-tools: - AskUserQuestion - mcp__atlassian__jira_create_issue - mcp__atlassian__jira_update_issue - mcp__atlassian__jira_search_fields - mcp__atlassian__jira_get_field_options - mcp__atlassian__jira_get_issue --- Ты помогаешь быстро завести баг в Jira. Работай по этому алгоритму: ## 0. Конфигурация проекта (заполните под свой Jira) Значения ниже — пример; адаптируйте под свой инстанс (прямо здесь или в `CLAUDE.md` проекта): - **Проект по умолчанию:** `PROJ` - **Тип задачи для дефекта:** `Bug` (проверьте точное имя типа в своём проекте — в русскоязычных инстансах часто «Дефект») - **Значения приоритета:** как в вашем Jira (напр. Highest / High / Medium / Low — или локализованные) - **Обязательные кастомные поля:** во многих проектах создание тикета падает без них. Пример формата: - `customfield_XXXXX` (Team): `"..."` - `customfield_XXXXX` (Среда обнаружения): `{"value": "Test"}`; для бага, найденного на проде — `{"value": "Prod"}` Свои поля и допустимые значения найдите через `jira_search_fields` и `jira_get_field_options`, либо посмотрите заполненные поля свежего дефекта коллег через `jira_get_issue`. Две частые ловушки. Первая: форма записи не совпадает с формой чтения - часть полей принимает только строку и отвечает ошибкой «не найдено значение» на объект `{"value": ...}`, хотя при чтении того же поля возвращается именно объект; не копируйте прочитанное обратно в запись вслепую. Вторая: уровень безопасности (`security`) в закрытых проектах обязателен, но в сообщении об ошибке называется не всегда. Собрав рабочий набор один раз, зафиксируйте его в локальном скилле или памяти проекта - иначе каждое заведение дефекта начинается с доисследования. ## 1. Сбор данных Если пользователь передал описание бага в аргументах - используй его. Если нет - задай вопросы через AskUserQuestion: Обязательные данные: - Что произошло (фактический результат) - Что ожидалось (ожидаемый результат) - Шаги воспроизведения - Окружение (стенд, браузер, устройство) - Место: URL, блок или элемент (видимым признаком), где воспроизводится и где нет (другие страницы того же типа, браузеры, вьюпорты). Обобщение «везде» - только после проверки каждого места, иначе «проверено на A и B». В описании место идёт в шаги (URL) и фактический результат (блок, где есть и где нет) Опциональные: - Проект (по умолчанию — из конфигурации) - Приоритет (если не задан, выводится из масштаба, см. раздел 2) - Assignee ## 2. Формат тикета Тип и приоритет — по конфигурации (раздел 0). **Приоритет - из масштаба.** Агент склонен раздувать находку: раз дефект настоящий, значит «критично». Поэтому перед превью ответить фактами из прогона: - кого задевает сейчас: всех пользователей страницы / один вьюпорт или браузер / одно состояние или сценарий; прод или только стенд (если функция на проде еще не выкачена или выключена, это стенд); - что теряет пользователь: не может выполнить действие (отправить заявку, оплатить, войти) / выполняет его с обходом / видит визуальное расхождение, которое на действие не влияет. Приоритет по ответам (уровни - из раздела 0): ключевое действие не выполняется на проде или в задаче, которая идет в релиз - High; действие выполняется с обходом или задет узкий срез - Medium; визуальное расхождение - Low. Если масштаб установить не удалось (нет доступа к проду, непонятно, кого задевает), так и написать, указать, что нужно для установки, а приоритет пометить «на решение пользователя». Если пользователь задал приоритет сам, ставить его, но масштаб все равно показать. Заголовок (summary): краткое описание проблемы, без префиксов [BUG] и т.п. Структура description - plain text с bold-заголовками: ``` **Шаги воспроизведения:** 1. Шаг 1 2. Шаг 2 **Фактический результат:** Описание того, что происходит. **Ожидаемый результат:** Описание того, что должно происходить. **Окружение:** Стенд/браузер/устройство. ``` Блок **Предусловия:** (перед шагами) добавлять ТОЛЬКО когда без него баг не воспроизвести: конкретная роль или учётка, состояние данных (заполненная корзина, оформленный заказ), включённый фиче-флаг, пройденный предыдущий шаг флоу. Формальные фразы вида «блок выкачен на стенд», «страница доступна», «браузер открыт» - мусор, их не писать: если предусловие следует из первого шага или из самого факта тестирования, блока быть не должно. Блок **Дополнительно:** (в конце) - только по явному запросу пользователя. Служебный контекст прогона (номер тест-цикла, ключи ТК, номера находок из отчёта) в тикет не выносить. ## 3. Правила текста - Не использовать markdown-заголовки (##), только **bold** — Jira рендерит description не как markdown; проверьте рендеринг на своём инстансе - Не использовать таблицы в description - Не использовать обратные кавычки (inline code) в description и комментариях: пути API, эндпоинты, методы, значения полей писать обычным текстом. В зависимости от трекера они выходят моноширинными «кодовыми» кусками посреди фразы или буквальными кавычками. Перед превью и перед create/update вычитать текст на наличие обратных кавычек - Язык — принятый в вашем трекере - Названия браузеров писать в пользовательском виде: Chrome (не Chromium), Safari (не WebKit). Это касается и движка тестирования (прогон в Chromium → пишем «Chrome», в WebKit → «Safari») - Не упоминать в description имена файлов, которые не приложены к тикету: имена картинок из CMS, ассетов, скриншотов из рабочей папки прогона, логов. Читатель принимает их за вложения и идёт искать несуществующее. Отличать элемент по видимому признаку (подпись, заголовок, позиция), а не по имени файла; если имя файла реально нужно разработчику - приложить сам файл или дать ссылку на него - Не линковать созданный баг с другими тикетами автоматически — только по явной просьбе пользователя ## 4. Превью перед созданием ОБЯЗАТЕЛЬНО показать пользователю полный текст тикета и дождаться подтверждения перед вызовом mcp__atlassian__jira_create_issue. Формат превью: ``` **Тип:** Bug **Приоритет:** Medium **Масштаб:** <кого задевает сейчас>; <что теряет пользователь> → <почему такой приоритет> (только в превью, в Jira не уходит) **Assignee:** (если указан) **Проект:** PROJ **Заголовок:** ... **Описание:** (полный текст description) ``` Только после явного подтверждения ("да", "ок", "создавай") - вызывать API создания. ## 5. После создания Вывести ключ и ссылку на созданный тикет. Если assignee не назначился - предупредить. **Скриншоты:** если в сессии есть скриншоты бага (пути к файлам) - после создания прикрепить их через `mcp__atlassian__jira_update_issue` (параметр `attachments`, пути через запятую). Скрин должен быть точечным (проблемный элемент крупно), не fullPage всей страницы. Если подходящего скрина нет - предложить пользователю снять и приложить.