| 1 | # Linear Tickets |
| 2 | |
| 3 | ## What this source contains |
| 4 | |
| 5 | - Issues describing features, bugs, and their motivation |
| 6 | - Project docs attached to issues (often PRDs or specs) |
| 7 | - Parent/sub-issue relationships (broader initiative → specific tickets) |
| 8 | - Comments on issues (clarifications, scope changes, "why we're doing this" rationale) |
| 9 | - Labels (e.g., `compliance`, `customer-request`, |
| 10 | - Status updates that explain scope changes |
| 11 | - Attachments and linked GitHub PRs |
| 12 | |
| 13 | Linear is where the product/business context often lives: the "we're doing this because customer X asked" or "this is for the Q3 compliance initiative" layer. |
| 14 | |
| 15 | ## How to search it |
| 16 | |
| 17 | Use the Linear MCP. |
| 18 | |
| 19 | 1. **Start with linked tickets.** If the seed commits or PRs reference ticket IDs (e.g., |
| 20 | 2. **List related issues by keyword.** Use |
| 21 | 3. **Walk the issue tree.** If you land on a sub-issue, fetch its parent. Sub-issues are tactical. Parents often carry the "why." |
| 22 | 4. **Read project docs.** If the issue belongs to a project, use |
| 23 | 5. **Check labels and milestones.** Labels hint at the category of motivation (customer-request, incident-followup, compliance). Milestones tie work to deadlines, which often reveal motivation. |
| 24 | |
| 25 | ## What good evidence looks like here |
| 26 | |
| 27 | - An issue description stating the business problem: "Customer Acme needs X because of their SOC2 audit" |
| 28 | - A comment recording a decision: "We decided to go with approach B because approach A would require touching the billing service" |
| 29 | - A parent issue titled like an initiative: "Q3 Enterprise Readiness" or "Reduce Payment Failures" |
| 30 | - An attached PRD or spec |
| 31 | - Labels like `customer:acme`, `incident-followup`, |
| 32 | |
| 33 | ## Common pitfalls |
| 34 | |
| 35 | - **Scope drift.** The ticket the PR references may have been closed and reopened with a different scope. Read the whole history. |
| 36 | - **Mechanical templates.** Some teams require "Why" sections but fill them with boilerplate. Generic text ("improve user experience") is probably not a real answer. |
| 37 | - **Stale tickets.** Old tickets often reflect a version of the plan that changed. Check dates and cross-reference with the code's ship date. |
| 38 | - **Closed-as-duplicate chains.** Follow the duplicate-of relationships back to the canonical ticket. |
| 39 | - **Private workspace content.** If you can't access an issue, note that as a gap rather than guessing. |
| 40 | |
| 41 | ## What to return |
| 42 | |
| 43 | For each relevant ticket: |
| 44 | - Ticket ID and title |
| 45 | - The problem/motivation quoted from the description or comments (not paraphrased. The synthesizer needs the exact text to cite) |
| 46 | - Labels, parent issue, project |
| 47 | - Author, created date, closed date |
| 48 | - Link to the ticket if available |