git:20261010.bdccdd9 to git:20261019.10080fd

---

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:

Обязательные данные:

- Что произошло (фактический результат)

- Что ожидалось (ожидаемый результат)

- Шаги воспроизведения

- Окружение (стенд, браузер, устройство)

Опциональные:

- Проект (по умолчанию — из конфигурации)

- Приоритет (если не задан, выводится из масштаба, см. раздел 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»)

- Не линковать созданный баг с другими тикетами автоматически — только по явной просьбе пользователя

## 4. Превью перед созданием

ОБЯЗАТЕЛЬНО показать пользователю полный текст тикета и дождаться подтверждения перед вызовом mcp__atlassian__jira_create_issue. Формат превью:

```

**Тип:** Bug

**Приоритет:** Medium

**Масштаб:** <кого задевает сейчас>; <что теряет пользователь> → <почему такой приоритет> (только в превью, в Jira не уходит)

**Assignee:** (если указан)

**Проект:** PROJ

**Заголовок:** ...

**Описание:**

(полный текст description)

```

Только после явного подтверждения ("да", "ок", "создавай") - вызывать API создания.

## 5. После создания

Вывести ключ и ссылку на созданный тикет. Если assignee не назначился - предупредить.

**Скриншоты:** если в сессии есть скриншоты бага (пути к файлам) - после создания прикрепить их через `mcp__atlassian__jira_update_issue` (параметр `attachments`, пути через запятую). Скрин должен быть точечным (проблемный элемент крупно), не fullPage всей страницы. Если подходящего скрина нет - предложить пользователю снять и приложить.