Bug report

Skill akovalion/paranoid-qa/skills/bug-report

Quick bug report in Jira. Invoke via /bug-report. Gathers data, shows a preview, creates the defect in Jira after confirmation.From its SKILL.md

Install

npx -y skills add akovalion/paranoid-qa --skill bug-report

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.7 KB, 792 tokens by cl100k_base, as published. Nobody here has run it

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.

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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in 792 tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

Use third-person for skill descriptionsin 54 of 1951, across 35 files
Start descriptions with Use whenin 43 of 1951, across 29 files
Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
Use active voicein 40 of 1951, across 36 files
Map file responsibilities before defining tasksin 36 of 1951, across 29 files
Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
Ask one question at a timein 35 of 1951
Offer execution options after saving the planin 33 of 1951, across 24 files
Include complete code in every stepin 33 of 1951, across 27 files
Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
Announce the skill usage at the startin 30 of 1951
Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

Gather bug details from user if not provided
Use bold headers for description sections
Use plain text for ticket description
Output ticket key and link after creation
Attach relevant screenshots after ticket creation
Warn user if assignee is not set

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.