Bug evidence intake
Organizes incoming bug evidence into reported claims, observations and testable hypotheses before asking for missing context.
bug-intake-evidence-analysis
Team members using this skill
When is it useful?
Use when a vague bug report needs a precise, testable failure signature.
What does it help you do?
- Separates the original report, direct observations and unverified hypotheses.
- Correlates error messages, timestamps and request identifiers with code paths.
- Finds the smallest missing fact while removing secrets from evidence.
Try asking this
Investigate a failed save screenshot and identify which logs would establish the same failure. Match the screenshot time to a request identifier and validation response. If they do not match, keep the proposed cause explicitly unconfirmed.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Bug Intake & Evidence Analysis
When to Use
Use at the start of any bug reproduction, triage, or investigation task when translating user reports, support tickets, screenshots, stack traces, or logs into a structured reproduction plan.
Strict Separation of Epistemic Tiers
Never blur what was reported with what you observed or inferred. Maintain three distinct categories throughout the investigation:
- Original Report (Reported Claim): Exact words, screenshots, timestamps, and steps supplied by the reporter—preserved verbatim even if parts later prove inaccurate.
- Direct Observation (Measured Evidence): Exact HTTP status codes, stack traces, DOM state, database rows, log entries, or console errors captured during controlled attempts.
- Working Hypothesis (Unverified Inference): Candidate conditions that might trigger the failure, paired with the test experiment designed to confirm or falsify them.
Extracting the Failure Signature
Before attempting to reproduce, define the exact Failure Signature so you never mistake an unrelated setup error or a different bug for the original issue:
- Expected Behavior: What the specification, contract, or user workflow requires at the failure point.
- Actual Observed Behavior: The specific exception class/message, wrong calculation, missing UI transition, HTTP
4xx/5xxbody, corrupted state, or hang. - Distinguishing Marker: The exact stack frame, error code, log line, or invariant violation that proves a reproduction attempt hit the same underlying failure mode.
Mining Existing Evidence Before Asking Questions
Exhaust every local and repository artifact before asking the reporter for more details:
- Codebase Search: Locate the exact error string, toast key (
i18nmessage ID), API route, or component referenced in the report or screenshot. - Log & Trace Correlation: Match timestamps, request IDs (
x-request-id/traceparent), user/tenant roles, and input validation boundaries around the failure path. - Redaction & Privacy Discipline: Strip API keys, bearer tokens, session cookies, passwords, and unnecessary PII from screenshots, HAR files, and payload dumps before storing them in test fixtures or reports.
Formulating High-Leverage Clarifying Questions
Only ask a question when its answer directly prunes the reproduction search space:
- Ask about state transitions ("Did this happen immediately after login or after switching workspaces?"), data shape ("Did the item have attachments or special characters?"), or frequency ("Does refreshing the page recover the state, or does it fail on every retry?").
- Never blame the user or dismiss an intermittent report as "works on my machine."
Included files 1
SKILL.md