/bug-report

name: bug-report
description: Quick bug report in Jira. Invoke via /bug-report. Gathers data, shows a preview, creates the defect in Jira after confirmation.
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

You help file a bug in Jira quickly. Follow this algorithm:

0. Project configuration (fill in for your Jira)

The values below are an example; adapt them to your instance (right here or in the project's `CLAUDE.md`):

• **Default project:** `PROJ`
• **Issue type for a defect:** `Bug` (check the exact type name in your project - in localized instances the type may be named differently, e.g. "Defect"/«Дефект» in Russian ones)
• **Priority values:** as in your Jira (e.g. Highest / High / Medium / Low - or localized)
• **Required custom fields:** in many projects, issue creation fails without them. Example format:
• `customfield_XXXXX` (Team): `"..."`
• `customfield_XXXXX` (Detection environment): `{"value": "Test"}`; for a bug found in production - `{"value": "Prod"}`

Find your fields and their allowed values via `jira_search_fields` and `jira_get_field_options`, or inspect the filled fields of a colleague's recent defect via `jira_get_issue`. Two common traps. First, the write format does not match the read format - some fields accept a plain string only and reject `{"value": ...}` with a "value not found" error, even though reading the very same field returns an object; do not copy what you read straight back into a write. Second, the security level field (`security`) is mandatory in restricted projects but is not always named in the error message. Once you have a working set, record it in your local skill or project memory - otherwise every defect starts with the same investigation.

1. Data gathering

If the user passed the bug description in the arguments - use it. If not - ask questions via AskUserQuestion:

Required data:

• What happened (actual result)
• What was expected (expected result)
• Steps to reproduce
• Environment (environment name, browser, device)

Optional:

• Project (default - from the configuration)
• Priority (default medium)
• Assignee

2. Ticket format

Type and priority - per the configuration (section 0).

Summary: a brief description of the problem, no [BUG] prefixes or similar.

Description structure - plain text with bold headers:

**Steps to reproduce:**

1. Step 1
2. Step 2

**Actual result:**

Description of what happens.

**Expected result:**

Description of what should happen.

**Environment:**

Environment/browser/device.

If preconditions are needed - add a **Preconditions:** block before the steps. If there is useful context - add an **Additional info:** block at the end.

3. Text rules

• Do not use markdown headings (##), only **bold** - Jira does not render the description as markdown; check the rendering on your instance
• Do not use tables in the description
• Language - whatever is standard in your issue tracker
• Write browser names the user-facing way: Chrome (not Chromium), Safari (not WebKit). This also applies to the test engine (run in Chromium → write "Chrome", in WebKit → "Safari")
• Do not link the created bug to other tickets automatically - only on explicit user request

4. Preview before creation

ALWAYS show the user the full ticket text and wait for confirmation before calling mcp__atlassian__jira_create_issue. Preview format:

**Type:** Bug
**Priority:** Medium
**Assignee:** (if specified)
**Project:** PROJ

**Summary:** ...

**Description:**
(full description text)

Only after explicit confirmation ("yes", "ok", "create it") - call the creation API.

5. After creation

Output the key and link of the created ticket. If the assignee was not set - warn the user.

**Screenshots:** if the session has bug screenshots (file paths) - after creation, attach them via `mcp__atlassian__jira_update_issue` (the `attachments` parameter, comma-separated paths). The screenshot must be targeted (the problem element up close), not a fullPage shot of the whole page. If no suitable screenshot exists - suggest the user take one and attach it.