{{ summaryTitle }}{{ summaryValue }}{{ summaryLine }}

Use a searchable symptom, such as “Retry export stays disabled after failure.”
This becomes the report prefix and first routing clue.
Include only context that could change reproduction.
Use at least two ordered actions another person can follow.
Describe the result that should have occurred.
Keep observed facts separate from diagnosis.
Choose harm level before scheduling priority.
Tie the selected severity to user or operational harm.
Retest only when it is safe and does not mutate important data.
Remove secrets, private URLs, customer identifiers, and personal data before filing.
The local pattern reminder cannot prove that pasted evidence is safe.
Do not recommend a workaround that risks data loss or security exposure.
Treat timing as evidence, not proof of cause.
Labels appear in the report and handoff payload but do not change readiness.
{{ values.ticket_markdown }}
FieldValueTriage useCopy
{{ row.field }}{{ row.value }}{{ row.use }}
GateStatusReview noteCopy
{{ row.gate }}{{ row.status }}{{ row.note }}
Test Case Generator Turn one feature workflow into traceable manual, Gherkin, or automation-ready test cases with risk coverage and focused review cues.
CI Failure Log Analyzer Find actionable clues in a failed CI log, map them to pipeline stages, and mask common secret patterns before sharing the evidence.
Stack Trace Signature Analyzer Group stack traces into repeatable fingerprints, compare frame evidence across common runtimes, and keep sensitive trace text in your browser.
Incident Timeline Report Turn incident notes into a sorted chronology with phase coverage, evidence gaps and response-cadence checks for a review-ready handoff report.

A useful bug report lets someone who was not present reproduce the failure, understand its impact, and decide where it belongs. The report should describe evidence rather than guess at a cause or prescribe a fix.

Start with a searchable symptom and the smallest affected area. Then preserve the conditions that could change the outcome: build or version, browser or device, account role, feature flags, data state, and the exact actions taken. Expected behavior and actual behavior belong in separate statements so the reviewer can see the mismatch without reconstructing it from a narrative.

Severity describes harm; reproducibility describes how reliably the same path triggers the observation. A severe failure may occur once, and a minor visual defect may occur every time. Priority is a later planning choice that can also depend on reach, deadlines, risk, and available workarounds.

QuestionEvidence that helps
Can it be reproduced?Ordered actions, starting state, environment, and test data
What failed?Expected result beside the observed result
Who is affected?Impact, severity, frequency, and any safe workaround
When did it start?First affected and last known good build or date
What supports the report?Sanitized screenshots, recordings, request IDs, logs, or related tickets

Evidence can contain credentials, personal data, customer content, internal addresses, or session details. Include the smallest excerpt that proves the symptom, remove sensitive values, and follow the destination project's reporting and disclosure policy.

How to Use This Tool:

Draft the reproducible core first; add optional evidence only after it has been sanitized.

  1. Write Bug title as a symptom and name the Affected area. Avoid titles such as “broken” or “does not work.”
  2. Record Environment and enter at least two Steps to reproduce, one action per line. Existing numbers or bullets are normalized in the report.
  3. Separate Expected behavior from Actual behavior, then choose Severity, describe Impact, and set Reproducibility.
  4. Add Evidence references, Logs or diagnostics, Workaround, Regression or first seen, and Tracker labels when known. Replace credentials, email addresses, and personal data before pasting.
  5. Review Repro checklist and the privacy warning. Fix every Needs work item, assess each Review item, then test the generated Markdown in the destination tracker.

Interpreting Results:

Ready to triage means all eight local checks are marked Ready. Ready with notes means the required reproduction core is present but one or more optional review items could strengthen the handoff. Needs work means at least one required gate is missing.

The status measures report completeness under a repository-authored checklist, not whether the reported behavior is truly a defect. A reviewer still needs to reproduce the issue, compare it with requirements, search for duplicates, and apply the destination project's severity and disclosure rules.

Technical Details:

The report model normalizes text into a consistent Markdown handoff, then evaluates eight gates. Required gaps outrank optional review notes, so one missing reproduction field produces Needs work even when every other check is ready.

Rule Core

GateReady whenOtherwise
Specific titleAt least 12 characters and not one of six generic titlesNeeds work
Environment capturedEnvironment is nonblankNeeds work
Reproduction stepsAt least two normalized stepsNeeds work
Expected vs actual splitBoth fields are nonblankNeeds work
Impact and severityImpact is nonblankReview
Evidence attachedAt least one evidence line or nonblank diagnosticsReview
Regression contextRegression or first-seen text is nonblankReview
Sensitive data scrubNo obvious pattern is detectedReview

The six generic title values are bug, issue, problem, broken, does not work, and not working, compared without regard to letter case. Severity and reproducibility must use one of the visible choices, but their labels do not change readiness counts.

Status selection follows this exact precedence:

  1. If one or more gates are Needs work, the report status is Needs work.
  2. Otherwise, if one or more gates are Review, the status is Ready with notes.
  3. Only eight Ready gates produce Ready to triage.

Transformation Core

Leading and trailing whitespace is removed from every field. Reproduction lines lose an initial number, dash, or asterisk before being renumbered in Markdown. Blank lines disappear. Labels are split at commas and exact duplicates are removed while the first occurrence keeps its position.

The generated report places triage data first, followed by ordered reproduction steps, expected and actual behavior, evidence, a fenced diagnostics block, workaround, and regression context. Triple backticks inside diagnostics are replaced with three apostrophes so pasted text cannot close the surrounding Markdown fence.

FieldMaximum characters
Title / affected area160 / 100
Environment / impact / workaround1,000 each
Steps / diagnostics4,000 each
Expected / actual / evidence2,000 each
Regression / labels500 each

Privacy and Filing Notes:

Drafting and pattern checks happen in the browser. The privacy reminder scans only evidence and diagnostics for obvious occurrences of API-key wording, token, secret, password, bearer credentials, or an email-address pattern.

  • A clear reminder does not prove that the report is sanitized; many credentials and personal-data formats will not match.
  • A warning may be a false positive because ordinary prose can contain words such as “token” or “password.” Review the actual value rather than deleting useful context blindly.
  • Generated Markdown is not submitted automatically. Confirm access controls, attachments, labels, severity, and disclosure policy in the destination tracker.
  • Do not paste live credentials merely to test the warning.

References: