Import your backlog

Your roadmap already lives somewhere — Jira, Linear, Productboard, GitHub, Asana, a spreadsheet someone maintains. partyline is the execution layer, not a second backlog, so the job isn't to replace that. It's to bring specific items across, keep them linked, and build them.

How you import: use your LLM

There is no Jira integration to set up. No OAuth screen, no API key to paste, no per-tool connector.

Your LLM is the integration. It already has your tracker connected — that's what its MCP servers are for. So you ask it to read your roadmap and hand items over, one at a time, through a partyline tool it already has.

You: import the P1 bugs from our Jira board into partyline

Claude: [reads Jira via your Jira MCP]
      [calls import_work_item ×7]

      Started 7 planning sessions. They're waiting in your Planning column.

That's the whole mechanism. It works for any tracker you can read — including ones we've never heard of — because partyline never talks to the tracker at all.

Why it's built this way

Three reasons, and they're the same reasons you'd want it this way:

No credentials. partyline never holds a token for your Jira. There's nothing to leak from our side, and nothing to revoke if you leave.
It can't break. A vendor changing their API breaks integrations. There is no integration here — your LLM adapts, the same way it already does.
Every tracker, day one. Internal tools, a Notion database, a CSV your PM emails around. If your LLM can read it, you can import it.

What arrives — a conversation, not a task

Each ticket opens a planning session: a describe conversation, seeded with the ticket verbatim, waiting in your Planning column.

It carries:

the title and body, word for word — your LLM is told not to rewrite or summarise, because a paraphrase quietly becomes the spec the work gets built against
a link back to the ticket in your tracker

Why not just create the task?

Because a ticket isn't one. A Jira ticket is a statement of a problem, written by someone who wasn't thinking about how it would be built. Filing it as a task asserts it's buildable — and an agent handed a vague ticket doesn't stall, it produces a confident, wrong diff.

So the import gives you the thing that's actually true: someone needs to have a conversation about this. You open the session, the agent interviews you across the product, technical and UX decisions, and that produces tasks with acceptance criteria that an agent can genuinely build.

The shaping step becomes impossible to skip rather than merely discouraged. Importing never starts work.

Re-importing is safe

Every item is keyed on its source tool + the tracker's own id (PROJ-412, an issue number, a row id).

Import the same roadmap again and matching tickets resume their existing session — nothing is duplicated. That matters more than it sounds: an LLM asked to "import the roadmap" will be asked again next month, and twenty duplicate planning conversations is worse than none.

Because of the key, your LLM should always pass the tracker's real id — never invent one.

From imported to built

An imported item is unshaped, and the readiness gate keeps it that way until someone decides otherwise:

Imported → a seeded planning session in your Planning column
Shaped → you work the conversation; Finalize files the result into the planning tree as tasks with acceptance criteria and a readiness score
Started → pick a project and machine; it becomes a run and moves into Build

Step 2 is the whole point, and it cannot be skipped — there is no task to start until the conversation produces one.

Sending status back

Two ways, neither of which needs an integration either:

GitHub — a crank PR writes Closes <issue-url> into its body, so GitHub's own issue-closing syncs status on merge.
Everything else — subscribe to webhooks and route the event to your tracker with tools you already own: a GitHub Action, Zapier, n8n, or the same LLM that did the import.

Same principle as the import: you own the connection to your tools, we don't.

The tool, for reference

import_work_item ships with the partyline MCP server — it's there in any session where partyline is wired, no extra install. See Context Threads for what else is in that toolbox.

field
`title`	required	how it reads on the board
`source_tool`	required	`jira`, `linear`, `productboard`, … — free text, just be consistent
`source_id`	required	the tracker's own id. With `source_tool`, this is what makes re-import safe
`source_url`		link back to the original
`document`		the body, carried verbatim — seeds the session's working doc

Each call returns the session's URL, and whether it was newly started or already existed — so your LLM can report "9 new, 3 already imported" rather than an opaque success.