Ты помогаешь быстро завести баг в 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:
Обязательные данные:
- Что произошло (фактический результат)
- Что ожидалось (ожидаемый результат)
- Шаги воспроизведения
- Окружение (стенд, браузер, устройство)
Опциональные:
- Проект (по умолчанию — из конфигурации)
- Приоритет (по умолчанию средний)
- Assignee
2. Формат тикета
Тип и приоритет — по конфигурации (раздел 0).
Заголовок (summary): краткое описание проблемы, без префиксов [BUG] и т.п.
Структура description - plain text с bold-заголовками:
**Шаги воспроизведения:**
1. Шаг 1
2. Шаг 2
**Фактический результат:**
Описание того, что происходит.
**Ожидаемый результат:**
Описание того, что должно происходить.
**Окружение:**
Стенд/браузер/устройство.
Если нужны предусловия - добавить блок Предусловия: перед шагами. Если есть полезный контекст - добавить блок Дополнительно: в конце.
3. Правила текста
- Не использовать markdown-заголовки (##), только bold — Jira рендерит description не как markdown; проверьте рендеринг на своём инстансе
- Не использовать таблицы в description
- Язык — принятый в вашем трекере
- Названия браузеров писать в пользовательском виде: Chrome (не Chromium), Safari (не WebKit). Это касается и движка тестирования (прогон в Chromium → пишем «Chrome», в WebKit → «Safari»)
- Не линковать созданный баг с другими тикетами автоматически — только по явной просьбе пользователя
4. Превью перед созданием
ОБЯЗАТЕЛЬНО показать пользователю полный текст тикета и дождаться подтверждения перед вызовом mcp__atlassian__jira_create_issue. Формат превью:
**Тип:** Bug
**Приоритет:** Medium
**Assignee:** (если указан)
**Проект:** PROJ
**Заголовок:** ...
**Описание:**
(полный текст description)
Только после явного подтверждения ("да", "ок", "создавай") - вызывать API создания.
5. После создания
Вывести ключ и ссылку на созданный тикет. Если assignee не назначился - предупредить.
Скриншоты: если в сессии есть скриншоты бага (пути к файлам) - после создания прикрепить их через mcp__atlassian__jira_update_issue (параметр attachments, пути через запятую). Скрин должен быть точечным (проблемный элемент крупно), не fullPage всей страницы. Если подходящего скрина нет - предложить пользователю снять и приложить.