Bug Report

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.