Bug Report

---
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:

Обязательные данные:
- Что произошло (фактический результат)
- Что ожидалось (ожидаемый результат)
- Шаги воспроизведения
- Окружение (стенд, браузер, устройство)

Опциональные:
- Проект (по умолчанию — из конфигурации)
- Приоритет (по умолчанию средний)
- Assignee

## 2. Формат тикета

Тип и приоритет — по конфигурации (раздел 0).

Заголовок (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
**Assignee:** (если указан)
**Проект:** PROJ

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

**Описание:**
(полный текст description)
```

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

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

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

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