linear-ticket-batch

Linear Ticket Batch (full coverage)

Take any loose, unstructured context — most often a discovery-call transcript, but equally meeting notes, a requirements brief, a PRD, an email or Slack thread, a voice-note dump, a whiteboard photo, a half-formed spec, or several of these at once — and turn the whole thing into a set of well-structured Linear tickets that cover every requirement, each sized to a single PR, all landing in Triage.

Transcripts are the primary case, but the skill is source-agnostic: if it contains requirements, it can be turned into tickets. The differentiator vs. the per-ticket flow is coverage: a large or rambling input hides requirements in asides, decisions, "oh and also" remarks, and constraints stated once in passing. This skill exists to make sure none of them are lost. The deliverable is not just tickets — it's tickets plus a traceability audit mapping every extracted requirement to the ticket that carries it.

The mechanics of creating each individual ticket (team, labels, description structure, image upload, moving to Triage) are owned by the linear-ticket-create skill. This skill is the front-end: ingest the big document, extract exhaustively, de-duplicate, carve into PR-sized tickets, then hand each one to that flow. Read linear-ticket-create and follow its per-ticket steps rather than re-deriving them here.

When to use

• User pastes or points at a long transcript / meeting notes / spec and says "make tickets".
• User wants a brain-dump or email thread broken into tracked Linear issues.
• Any time the input is big enough that ad-hoc reading risks missing requirements.

For a single small request (one chat snippet, one screenshot, one bug), use linear-ticket-create directly — you don't need the extraction/audit overhead.

When NOT to use (explicit request only)

This skill only runs when the user explicitly asks to create tickets from a document. Do not trigger it just because a transcript, meeting notes, or requirements happen to be in context, pasted, or open in the editor. In particular, do not run it when the user is only:

• asking you to read, summarise, or explain a transcript / notes / spec;
• discussing the document or asking questions about it;
• working on something else while such a file merely sits in context.

If you think tickets would help but the user hasn't asked, offer ("Want me to turn this into Linear tickets?") and wait — don't start creating. Treat ambiguous mentions as discussion, not a request to ticket.

Inputs

Accept any of: a file path (.md, .txt, .vtt, .srt, .docx exported to text, an image of a whiteboard — use the Read tool), pasted text, or several of these at once. If multiple sources describe the same project (e.g. a transcript and the tidied meeting notes), read all of them — one often contains requirements the other omits — and merge.

Workflow

Steps 1–4 run once over the whole input. Step 5 runs the linear-ticket-create flow per ticket. Steps 6–7 close the loop with the coverage audit and report.

1. Read everything, completely

• Read every supplied source end to end (Read tool on files/images). Do not skim or sample a large file — requirements hide in the back half and in throwaway lines.
• If several sources cover the same project, read them all and reconcile; note where they disagree (the transcript says one thing, the notes another) — that's an open question, not a silent pick.

2. Extract requirements exhaustively (the core step)

Build a flat, numbered requirements list before thinking about tickets. Sweep the document for every category below — each is a place requirements hide:

• Explicit features / asks — "we need X", "can it do Y".
• Constraints & non-functionals — performance, accessibility (e.g. WCAG level), browser/ device support, security, "no database", "keep dependencies minimal", branding/palette.
• Decisions stated in passing — "let's use React + TypeScript", "history is local-storage only", "delivered as an embedded component". These are requirements too.
• Acceptance signals — anything that tells you how someone will judge "done" ("must work on iPad", "last 10 entries", "Enter = equals").
• Implicit / follow-on work — testing, docs, analytics/telemetry the goal implies (e.g. an "engagement" objective implies usage tracking), error/edge-case handling raised verbally.
• Out-of-scope & non-goals — capture these explicitly so they become exclusions in the relevant tickets, not accidental tickets. (Out-of-scope items do not become tickets.)
• Open questions / unconfirmed scope — anything "to confirm", "we'll decide later", "I think". These travel into tickets as flagged questions, never as invented certainty.

For each requirement record: a short id (R1, R2, …), the requirement in one line, and a verbatim source quote (so the audit can prove provenance). Quoting matters where exact wording is the point (copy, thresholds, labels).

De-duplicate as you go: the same ask voiced three times across a transcript is one requirement (note all the spots it appears). Keep mutually-reinforcing details merged.

3. Gather codebase context

Per linear-ticket-create step 2: for requirements that touch existing code, grep/Glob/Read to find where they live and capture file_path:line references and concrete facts. Don't implement anything. For a greenfield/new project there may be no existing code — that's fine; note it's net-new.

4. Carve requirements into PR-sized tickets, then confirm the plan

Group the requirements list into tickets using the Sizing ("one ticket = one PR") rules in linear-ticket-create — split independent asks, keep tightly-coupled changes together, don't micro-split. Every requirement (except out-of-scope items) must map to exactly one ticket; cross-cutting constraints (accessibility, branding, "minimal deps") attach to the tickets they constrain, or get their own ticket if substantial enough to be a PR on their own.

Then present the plan to the user before creating anything:

• A numbered list of proposed tickets: title + one-line scope each, in dependency/stack order.
• A coverage table: every requirement id (R1…Rn) → the ticket that will carry it (or OUT for out-of-scope, Q for open-question-only). This is the user's chance to catch a dropped or mis-grouped requirement before tickets exist.
• The list of open questions you'll be flagging.

Wait for the user to confirm or adjust the breakdown. (If they've said "just create them", skip the wait but still produce the table so it's on record.)

5. Create each ticket via linear-ticket-create

For each ticket in the agreed plan, run the linear-ticket-create workflow steps 3–7: pick the team (Developer Hut, DEV-), read the live label list and apply what fits, save_issue with the structured Markdown description (literal newlines), attach any images, move to Triage. Additionally, for this skill:

• In each description's Source line, cite the document(s) and date (e.g. "Discovery call transcript + meeting notes, 3 Jun 2026").
• Put the relevant out-of-scope / non-goals into the ticket's What or an Out of scope line so the boundary is explicit.
• Carry the matching open questions into the ticket and add the Need client feedback label when scope is unconfirmed.
• When tickets are dependent, set blocks / blockedBy in PR/stack order and reference sibling identifiers in the description, per linear-ticket-create.

Capture each returned identifier (DEV-…) and url.

6. Coverage audit (prove nothing was dropped)

After all tickets exist, re-walk the requirements list from step 2 and confirm each id now resolves to a created ticket id, an explicit out-of-scope exclusion, or a flagged open question. If any requirement has no home, that's a miss — create the missing ticket (or fold it into an existing one) before reporting. The audit is not optional; it's the reason this skill exists.

7. Report back

• The created tickets in PR/stack order: each DEV-… identifier, title, and clickable url, with dependency links noted.
• The traceability table: R1…Rn → DEV-… (or OUT / open question), so the user can see at a glance that the whole document is accounted for.
• All open questions you flagged, and any source you treated as out of scope.
• Any disagreements between sources you reconciled.

Principles

• Coverage is the job — every requirement in the document ends up in a ticket, an explicit exclusion, or a flagged question. The traceability table is the proof; produce it every time.
• Extract before you carve — build the exhaustive numbered requirements list first, then group into tickets. Don't skip straight to tickets from a long doc; that's how asks get lost.
• One ticket = one PR — defer to linear-ticket-create's sizing rules; split independent asks, keep coupled changes together, link stacked tickets in PR order.
• Out-of-scope ≠ a ticket — non-goals become exclusions inside the relevant tickets, never their own issues.
• Surface, don't fabricate — "to confirm" stays an open question; never upgrade a maybe into a committed requirement, and never invent acceptance criteria the source didn't imply.
• Quote the source — keep verbatim quotes for requirements where wording is the point and for the audit trail.
• Confirm the plan first — show the ticket breakdown + coverage table before creating, so the user can steer the split while it's still cheap.
• Don't re-derive the per-ticket mechanics — team, labels, description shape, image upload, and Triage handling all live in linear-ticket-create; follow it.

Related skills

• linear-ticket-create — the per-ticket engine this skill delegates to; use it directly for a single small request that doesn't need extraction or a coverage audit.
• pr-to-linear-ticket — the reverse direction: back-fill a ticket for an existing PR and stamp the PR title with its identifier.