Orqestria Download
← Back to Zora
AgentZora

Skill · Version 1.0.0

Bug evidence intake

Organizes incoming bug evidence into reported claims, observations and testable hypotheses before asking for missing context.

bug-intake-evidence-analysis

See how it helps

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.

Details…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:

  1. Original Report (Reported Claim): Exact words, screenshots, timestamps, and steps supplied by the reporter—preserved verbatim even if parts later prove inaccurate.
  2. Direct Observation (Measured Evidence): Exact HTTP status codes, stack traces, DOM state, database rows, log entries, or console errors captured during controlled attempts.
  3. 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/5xx body, 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:

  1. Codebase Search: Locate the exact error string, toast key (i18n message ID), API route, or component referenced in the report or screenshot.
  2. Log & Trace Correlation: Match timestamps, request IDs (x-request-id / traceparent), user/tenant roles, and input validation boundaries around the failure path.
  3. 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