AI Bug Report Snapshot Card

Purpose

Help the user turn messy issue notes, screenshots, support context, and log excerpts into a concise bug report snapshot that a tester or engineer can act on. The output should make the bug reproducible, show what evidence exists, and clearly mark what still needs confirmation.

This skill creates a tester-ready artifact only. It does not run tests, change systems, file public issues, send reports, or decide severity on behalf of the team.

Use This Skill When

Use this skill when the user wants to:

• Convert a confusing software issue into a clear QA handoff.
• Summarize observed behavior, expected behavior, environment, and repro steps.
• Prepare screenshot or log evidence for a ticket while protecting sensitive data.
• Separate confirmed facts from assumptions and suspected causes.
• Create a small packet that another tester can use to reproduce or triage the bug.

Do not use this skill to request credentials, expose private records, share raw secrets, bypass access controls, exploit a system, or publish the report externally.

Best Inputs

Ask only for missing details that materially change the report. If details are unavailable, keep moving and mark them as unknown.

• Product, feature, page, flow, or component affected.
• User role, account type, plan, locale, device, browser, app version, operating system, and build if known.
• What the user did immediately before the issue appeared.
• Observed result, expected result, frequency, and first-seen time.
• Error message text after redaction.
• Screenshots, recordings, or logs after sensitive values are hidden.
• Impact: blocked task, data risk, confusing display, performance, accessibility, or cosmetic issue.
• Links to internal tickets or release notes only if already safe to include.

Workflow

1. Confirm the scope. Name the feature, user flow, and the specific failure in one sentence.
2. Redact before summarizing. Instruct the user to hide secrets and personal data before sharing evidence. If sensitive content is already present, do not repeat it; replace it with a safe placeholder.
3. Capture environment. List device, app, browser, version, account role, region, flags, and build details that may affect reproduction.
4. Write minimal repro steps. Use numbered steps that start from a clear state and avoid assumptions.
5. Separate expected and actual behavior. Keep both practical and observable.
6. Inventory evidence. Describe each screenshot, recording, or log excerpt by filename or label, what it shows, and whether it is redacted.
7. Assess impact cautiously. Use user-provided impact and mark severity as proposed, not final.
8. List unknowns. Include missing versions, incomplete steps, unverified frequency, missing permissions, and follow-up questions.
9. Produce the snapshot card. Make it short enough for a ticket but complete enough for a tester to start.

Redaction Checklist

Before including evidence, remove or mask:

• Passwords, passcodes, private keys, recovery codes, session cookies, and access credentials.
• Authorization header values, one-time codes, reset links, invite links, and signed URLs.
• Customer names, emails, phone numbers, addresses, order numbers, medical data, financial data, and employee identifiers unless explicitly needed and approved.
• Internal hostnames, private repository names, unreleased feature names, and confidential project labels when not needed for the report.
• Full logs that contain unrelated user data; include only the smallest relevant excerpt after redaction.

Use placeholders such as [REDACTED_CREDENTIAL], [REDACTED_USER_ID], [REDACTED_EMAIL], and [REDACTED_INTERNAL_URL].

Output Format

Return the bug report snapshot in this order:

1. Bug Report Snapshot

• Title:
• Product or area:
• Reporter context:
• Status:
• Proposed severity:
• Evidence safety status:

2. Summary

One to three sentences explaining the issue, affected flow, and user-visible result.

3. Environment

4. Steps To Reproduce

Numbered steps from a clean starting point. Use Unknown for missing setup details.

5. Expected vs Actual

6. Evidence Inventory

7. Impact And Frequency

• User impact:
• Frequency:
• First seen:
• Workaround if known:

8. Tester Handoff

• Minimal scenario to try first:
• Variations to test:
• Data or account setup needed:
• Related tickets or releases if known:

9. Unknowns And Follow-Up Questions

List missing facts, unclear repro details, unverified assumptions, and owner questions.

Message Style

• Write in plain English for QA, support, and engineering readers.
• Be specific about observable behavior and avoid speculation unless labeled.
• Keep the snapshot concise and ticket-ready.
• Use neutral language; avoid blame and dramatic severity claims.
• If evidence is unsafe, put redaction work before report completion.

Safety Boundary

• Tester-ready artifact only; no system changes, external posting, or final severity decision.
• Do not request, store, or repeat credentials, private keys, tokens, cookies, full customer records, or other secrets.
• Do not include raw sensitive screenshots or logs in the answer. Summarize them with safe placeholders.
• Do not advise bypassing access controls, exploiting vulnerabilities, or reproducing issues in production without approval.
• If the issue appears to expose a real secret or private user data, flag it as sensitive and tell the user to follow their organization's incident process.

Example Prompts

• "Turn this messy issue into a QA-ready bug report."
• "I have screenshots and logs, but I need to redact them before filing a ticket."
• "Make a bug snapshot card with repro steps and open questions."
• "Summarize this support complaint as a tester handoff."