AI Bug Report Snapshot Card

Problem

Software defects often arrive as customer notes, frustrated reports, screenshots, and partial logs. The symptoms may be clear, but the environment, trigger conditions, evidence chain, and open questions are mixed together. A tester may still need to ask for the app version, account role, error text, and whether the screenshot contains private data. This skill addresses that QA handoff gap by turning messy material into a concise bug report snapshot card that can be pasted into Jira, Linear, or GitHub Issues.

It only prepares a tester-ready artifact. It does not run tests, modify systems, file public issues, or make the final severity decision. Instead, it proposes severity and lists what still needs confirmation.

How It Works

The skill organizes output around reproducibility, verification, and redaction:

• Confirm scope: name the affected feature, user flow, and specific failure in one sentence.
• Redact before summarizing: mask passwords, tokens, cookies, contact details, order numbers, internal hostnames, and other sensitive values with placeholders such as [REDACTED_CREDENTIAL].
• Capture environment: record version, device, browser, account role, locale, flags, and build details, marking each value as Confirmed / Unknown.
• Write minimal repro steps: start from a clean state and avoid assumptions; missing setup details remain Unknown.
• Separate expected and actual behavior: keep both observable and practical.
• Inventory evidence: describe screenshots, recordings, and log excerpts, what they show, and whether they are safe to attach.
• Produce a tester handoff: list the first scenario to try, variations to test, required setup, and open questions.

The final card typically includes Summary, Environment, Steps To Reproduce, Expected vs Actual, Evidence Inventory, Impact And Frequency, and Unknowns And Follow-Up Questions.

Boundaries And Caveats

Use it to prepare support complaints, bug notes, or log excerpts for triage, not to execute tests, change production state, or publish reports externally. When real credentials, user data, or internal sensitive details are present, redaction should come first. If the material appears to expose a secret or private user data, flag it as sensitive and follow the organization's incident process instead of embedding it in a normal bug card.