Backlog board next to PRs: see planned work and start threads from issues (Linear, GitHub Issues, Jira…)

[carmichaelt]

Problem

T3 Code covers work that's already started well: threads, PRs, checks. Work that hasn't started yet lives in a separate tool.

To pick the next task I switch to Linear, copy an issue into a new thread by hand, and lose the link between the two. T3 can't tell me which issues already have threads or PRs, and I can't see progress across an epic.

Proposal

A Backlog view next to the PRs view:

• Board or list of issues from a connected tracker, filtered by team, project/epic, cycle, assignee or label.
• "Start thread" on an issue opens a thread with the issue's title, description and links already in the prompt, and links the thread to the issue.
• Linked status: each issue card shows its threads and PRs and their state (running, waiting on me, PR open, merged).
• Group by epic/project, so one epic shows its issues, threads and PRs together.
• Pluggable providers: Linear first, then GitHub Issues (should be cheap given the existing source control integration), then Jira.

Why in T3 rather than the tracker

T3 already knows about threads and PRs, so it's the natural place to connect planned work to work in progress.

Linking threads to issues would also keep context and design decisions on the issue. Today the reasoning behind a change lives in a thread that nobody on the team can find later. If each linked thread wrote back what it decided and why, the issue would become the record of how the work was done, not just of what was asked for.

Datadog's Bits Code is moving the same way from the observability side: a detected issue flows straight into an agent writing the fix.

What works today

With the Linear MCP connector, an agent can read issues, create or update them, and attach PR links. But there's no native UI: no board, no "start thread from issue," and no linked status in the sidebar.

Suggested scope

1. Read-only first: list issues, start a thread from an issue, show the link on the thread and the card.
2. Later: write-back (move the issue to In Progress when a thread starts, to Done when its PR merges, and post a summary of the thread's key decisions to the issue), more providers.

Open questions

• Is one thread linked to one issue, or can several threads attach to one issue?
• Does the board live per project, or across all projects?
• Should write-back be opt-in per provider or per project?

Related

• [Feature]: Thread grouping / filtering #5653 Thread grouping / filtering
• Offering some improvements from my fork: sidebar sections, a Needs me list, less phone traffic, and more #30953 Sidebar sections / "Needs me" list
• Release watch after merge (companion idea): Watch a release after merge: check observability (Datadog, Sentry…) for a few minutes and report back in the thread #30982

[joaocoform]

+1, this would be really useful.

A small first step I'd use every day: a linked issue next to the linked PRs on a thread, the same way PRs show up now. Just the Linear, GitHub or Jira link, shown beside or under the PR. That alone would end the "which ticket was this thread for?" search.

On the "pluggable providers" part: the proposal doesn't say how providers would connect. Two thoughts:

• The link needs no integration. It's a URL plus an ID taken from it (like ABC-123), so it works for any tracker on day one. The agent can add it with a tool like the existing PR-linking one.
• Richer data could come through MCP, and be optional. Status, title and assignee could come from an MCP server the user has already connected (Linear, GitHub and Jira all ship one), so T3 wouldn't need its own integration for each tracker. With no tracker connected, you'd still see the link.

This would also make a clean first slice of the board idea, since the board could be built on these links later.

[djgilcrease]

NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease.

Dj's From Issue workflow is now available as an external plugin: digitalxero/t3-from-issue, stable v0.1.0.

The full plugin announcement, installation instructions, evidence and limitations is in the plugin-prototype discussion.

Enable From Issue for a project under Settings → Projects → New threads. Choose Source Control or Linear, then search and multi-select issues from the thread information panel before first send or on a saved thread. Links survive draft creation; multiple issues expand like linked PRs, and each opens its current description inside the client. Remove and clear are supported. Refreshed issue context is bounded to 14,000 characters per turn for at most twenty links, with durable provider/repository/issue identity.

Source Control supports GitHub and GitLab through the project's existing host selection/authentication, including glab. Linear requires a project-scoped personal API key and explicit consent. This release covers the linked-issue workflow; it does not include a backlog board, epic progress, Jira, tracker writeback, comments/attachments, or association transfer through thread rehoming.

Requires the prototype host fork and does not imply upstream approval. Minimum verified host: djgilcrease/t3code at d91fdaa33acf40b471c75d0939a484dc07aae15e, including merged fork PR #3. Install https://github.com/digitalxero/t3-from-issue through Settings → Plugins on that fork.

Real Linux web/packaged-host repository installation and lifecycle, GitHub selection, public GitLab reads and public release artifacts were verified. Live Linear and native mobile/Electron UI were not exercised; one live environment was tested. The announcement separates the passing required plugin CI and focused local host checks from the fork's queued hosted CI, which has no registered Blacksmith runner.

Project opt-in:

Multiple selected issues before first send: