1# Crash Issue Linking
 2
 3You are linking a crash to potentially related GitHub issues so human reviewers can quickly validate whether a fix may resolve multiple reports.
 4
 5## Inputs
 6
 7Before starting, you should have:
 8
 91. **Crash report** (from `script/sentry-fetch <issue-id>` or Sentry MCP)
102. **ANALYSIS.md** from investigation phase, including root cause and crash site
11
12If either is missing, stop and report what is missing.
13
14## Goal
15
16Search GitHub issues and produce a reviewer-ready shortlist grouped by confidence:
17
18- **High confidence**
19- **Medium confidence**
20- **Low confidence**
21
22The output is advisory only. Humans must confirm before adding closing keywords or making release claims.
23
24## Workflow
25
26### Step 1: Build Search Signals
27
28Extract concrete signals from the crash + analysis:
29
301. Crash site function, file, and crate
312. Error message / panic text
323. Key stack frames (especially in-app)
334. Reproduction trigger phrasing (user actions)
345. Affected platform/version tags if available
35
36### Step 2: Search GitHub Issues
37
38Search **only** issues in `zed-industries/zed` (prefer `gh issue list` / `gh issue view` / GraphQL if available) by:
39
401. Panic/error text
412. Function/file names
423. Crate/module names + symptom keywords
434. Similar reproduction patterns
44
45Check both open and recently closed issues in `zed-industries/zed`.
46
47### Step 3: Score Confidence
48
49Assign confidence based on evidence quality:
50
51- **High:** direct technical overlap (same crash site or same invariant violation with matching repro language)
52- **Medium:** partial overlap (same subsystem and symptom, but indirect stack/repro match)
53- **Low:** thematic similarity only (same area/keywords without solid technical match)
54
55Avoid inflated confidence. If uncertain, downgrade.
56
57### Step 4: Produce Structured Output
58
59Write `LINKED_ISSUES.md` using this exact structure:
60
61```markdown
62# Potentially Related GitHub Issues
63
64## High Confidence
65- [#12345](https://github.com/zed-industries/zed/issues/12345) — <title>
66  - Why: <1-2 sentence evidence-backed rationale>
67  - Evidence: <stack frame / error text / repro alignment>
68
69## Medium Confidence
70- ...
71
72## Low Confidence
73- ...
74
75## Reviewer Checklist
76- [ ] Confirm High confidence issues should be referenced in PR body
77- [ ] Confirm any issue should receive closing keywords (`Fixes #...`)
78- [ ] Reject false positives before merge
79```
80
81If no credible matches are found, keep sections present and write `- None found` under each.
82
83## Rules
84
85- Do not fabricate issues or URLs.
86- Do not include issues from any repository other than `zed-industries/zed`.
87- Do not add closing keywords automatically.
88- Keep rationale short and evidence-based.
89- Favor precision over recall.