Brainforge Knowledge

linear-ticket-generation-from-transcript

7 min read

Cursor Agent → Linear Ticketing Playbook

Purpose

This file defines how to create or update Linear tickets from a wide range of inputs, including messy, inconsistent, and differently-written requests from multiple people.

You may receive inputs such as:

  • One-line asks (“please track this”, “can we make tickets from this”, “log action items”)
  • Bulleted meeting notes
  • Copy/pasted Slack messages
  • Partial requirements
  • Status updates (“this is blocked”, “we decided X”, “shipping next week”)
  • Transcripts or call notes (most common): extract action items, decisions, owners, deadlines, and context, then convert them into clear Linear issues and updates

You must interpret different phrasings that mean similar things. Examples:

  • “Make a ticket”, “log this”, “track this”, “capture this”, “add to Linear”, “follow up on this” → Create an issue (or update if it already exists)
  • “Update the ticket”, “reflect this decision”, “add context”, “this is now blocked/unblocked”, “we changed scope” → Update an existing issue
  • “Action items”, “next steps”, “to-dos”, “follow-ups” → Likely multiple issues or sub-tasks (split when appropriate)
  • “Decision”, “we agreed”, “finalized”, “alignment” → Add as a comment and/or update scope/acceptance criteria
  • “Owner”, “point person”, “DRI”, “who’s doing this” → Assignee
  • “Due by”, “ETA”, “target date”, “by end of day/week”, “next sprint” → Due date / milestone only if explicit

Your goal is to:

  • Turn unstructured text into clear, actionable tickets
  • Keep Linear current based on new information
  • Avoid duplicates
  • Preserve context and decisions in a way the team can execute

Scope

You may:

  • Search/find existing issues
  • Create issues
  • Update issue fields (title, description, status, priority, labels, assignee, due date/estimate if provided)
  • Add comments with progress, questions, and decisions

You must NOT:

  • Invent requirements, deadlines, or owners
  • Close issues without an explicit user instruction or clear completion evidence
  • Change scope silently (always note changes)

Operating Principles

  1. Be literal. Use only information in the user’s message(s) and any referenced context they provided.
  2. Prefer updating over creating when an existing issue clearly matches.
  3. No duplicates. Search before creating.
  4. Ask in-ticket questions if something blocks action (via a comment), instead of guessing.
  5. Keep history. If you change a field (status, priority, assignee), leave a brief comment explaining why.

Step-by-step Workflow

When run as part of a Linear board audit: Transcripts must be gathered using the audit SOP’s transcript-discovery step: client-named meetings (assigned + unassigned) plus content search for client name or ticket prefix in recent transcripts (so standups and other shared meetings that discuss the client are included). Use this document to turn the content of those transcripts into tickets; do not assume transcripts are only under the client folder or only in client-named meetings.

Step 1 — Confirm the user’s intent

Classify the request into one of:

  • Create: new work items that do not exist yet
  • Update: changes to existing issues
  • Create + Update: add missing tickets and fix/refresh existing ones

If unclear, proceed with best effort:

  • Search for related issues first
  • Comment questions on the most likely matching issue (or create a single “Clarify requirements” ticket)

Step 2 — Search Linear first (anti-duplication)

Before creating anything:

  • Search by keywords from the user’s request
  • Search by any provided issue IDs/keys
  • Search within the relevant team/project if specified

If you find matches:

  • Prefer updating the best match
  • If multiple matches exist, update the one with the closest scope and add a comment referencing the others

Step 3 — Decide: create vs update

Create a new issue only if:

  • No existing issue matches the scope, OR
  • The work is clearly a separate deliverable that should be tracked independently

Update an issue if:

  • It is the same deliverable
  • The user is refining requirements, adding acceptance criteria, reprioritizing, or changing status/assignee

Step 4 — Write issues using the standard template

Use the templates below. Keep titles short; put details in the description.

Step 5 — Apply fields consistently

Apply what you can from the request; otherwise leave blank/unset:

  • Team (if specified)
  • Project (if specified)
  • Labels (if specified)
  • Priority (if specified)
  • Assignee (if specified)
  • Status (if specified)
  • Due date / estimate (only if explicitly provided)

Service line + subservice labels (client + Platform + Services engineering work): When the issue is on an in-scope team and the work maps to a service line, include both line-level and subservice-level signal (canonical kebabs and/or approved cap-* proxies per .cursor/skills/linear-service-label-audit/references/taxonomy.md). Use Linear MCP list_issue_labels for exact strings; do not invent names. If save_issue replaces all labels, merge with existing labels per .cursor/skills/linear-service-label-apply/SKILL.md. When list_issues shows labels: [], confirm with get_issue before assuming no labels.

Step 6 — Post an “Action Summary” comment

After creating/updating tickets, add a short comment to the relevant issue(s):

  • What changed
  • What remains unknown
  • What you need from the user (if anything)

Required Ticket Format

Title rules

  • Start with a verb: “Add…”, “Fix…”, “Investigate…”, “Refactor…”
  • Avoid vague titles like “Bug” or “Update”
  • If it’s exploratory, start with “Investigate: …”

Description template (use headings exactly)

Copy this structure into every ticket description:

Context

  • What triggered this work (brief)
  • Links or references (if any)

Goal

  • The outcome in 1–2 sentences

Scope

In scope

  • Bullet list

Out of scope

  • Bullet list

Acceptance Criteria

  • Bullet list of testable conditions

Notes / Constraints

  • Known constraints, dependencies, “do not change” items

Open Questions

  • List only if needed

Update Rules (how to change existing tickets)

When updating an issue description

  • Preserve existing valuable content
  • Append new info under the correct heading
  • If you must remove text, explain why in a comment

When adding a comment

Use this format:

Update

  • What changed

Decision / Rationale

  • Why (1–2 lines)

Next Steps

  • What will happen next (or what’s needed)

When changing status

  • Move to the status requested by the user
  • If status is not specified, do not change it unless:
    • The user says work is “done”, “shipped”, “merged”, etc., AND
    • There is clear evidence in the context

When setting priority

Only set if the user explicitly states priority/urgency. If they imply urgency but don’t give a priority:

  • Add a comment asking which priority to use
  • Do not guess

When setting assignee

Only set if the user names an assignee (person or Cursor).

Creation Rules (when making new tickets)

One request → multiple tickets

Split into multiple issues if:

  • Different owners/teams
  • Different deliverables
  • Work can ship independently
  • Estimated effort differs significantly

If splitting, also create (or update) a “parent” tracking issue only if the user explicitly wants it.

If the user does not specify a naming scheme:

  • Use concise titles
  • Add a label like cursor-generated if available

Output Requirements (what you report back)

After making changes, reply with:

  • A bullet list of tickets created (title + key)
  • A bullet list of tickets updated (title + key)
  • Any blocking questions

Do not include long explanations in the chat response; keep details inside Linear.

Examples (copy/paste patterns)

Example: create a new issue

Title: Investigate: Linear ↔ Cursor MCP failures in auth

Description:

  • Context: user reports intermittent MCP errors
  • Goal: identify root cause and mitigation
  • Scope: reproduce, check logs, propose fixes
  • Acceptance Criteria: documented root cause + recommended fix steps
  • Notes: do not change production config without approval
  • Open Questions: which environment?

Example: update an existing issue

  • Add acceptance criteria under the existing heading
  • Comment with:
    • Update: added criteria + clarified scope
    • Decision: aligning with playbook
    • Next steps: waiting for user confirmation on priority

Checklist (before you finish)

  • Searched for existing issues first
  • No duplicates created
  • Titles are actionable and concise
  • Descriptions use the standard headings
  • Acceptance criteria are testable
  • Any assumptions are explicitly marked as questions
  • Added an Action Summary comment for each touched issue
  • Reported created/updated keys back to the user

End of file.

Graph View

Backlinks