Which designs shipped and which are still waiting: reporting across Figma and Linear

The Monday design review

It is 9:40 on a Monday. Priya, the design lead, has the Figma file for the billing redesign open on her left screen. Twenty-two frames, most of them marked with a green "Ready for dev" section label she added herself three weeks ago. On her right screen is the Linear board for the Payments team, filtered to the current cycle: forty-one issues, eleven in Done, nine in In Progress, the rest in Backlog and Todo.

Her VP asked one question in Slack an hour ago: which of the billing designs are actually live, and which ones are sitting there finished but unbuilt?

Priya cannot answer it from either screen. The Figma file tells her what she drew and when she last touched it. The Linear board tells her what engineering picked up and closed. Nothing in either place tells her that the "Invoice history, empty state" frame she finalised on 14 July has no corresponding Linear issue at all, or that SKX-2210 called "clean up billing page" shipped last Thursday and quietly covered three of her frames without anyone linking them.

So she does what everybody does. She opens the Figma file, opens Linear next to it, and starts matching things by eye. It takes ninety minutes. She finds four designs nobody picked up. She is not confident she found all of them.

This is the report neither product can produce, and the reason is more structural than it looks.

What Figma shows on its own

Figma is genuinely good at the design half. The file gives Priya frame names, page structure, version history with named checkpoints, and Dev Mode, which is a real handoff surface: it marks sections as ready for development, exposes specs and code snippets, and shows engineers what changed since they last looked. Comments carry threaded discussion attached to specific coordinates on specific frames. If you want to know when a design was last edited, who touched it, and what the current state of the artboard is, Figma answers that precisely.

Where it stops is the word "shipped." Figma has no visibility into your repository, your deploy pipeline, or your issue tracker's status column. "Ready for dev" is a label a designer applies to communicate intent. It does not update itself when the work gets built, and it does not clear itself when the work gets cancelled. Priya's file has frames still marked ready for dev that shipped in May, because nobody goes back to un-mark things. The label describes a moment, not a current state.

Figma also does not know which frames are load-bearing. Twenty-two frames in a file might represent six user-facing changes, with the rest being variants, error states, and one abandoned exploration Priya kept for reference. The file structure does not encode that distinction unless someone maintained it by hand.

What Linear shows on its own

Linear is equally good at the delivery half, and it is unusually disciplined about it. Every issue has a state, a cycle, an assignee, labels, a project, and a full history of transitions with timestamps. Linear's Figma integration is real and useful: paste a Figma link into an issue and it unfurls with a live preview thumbnail, and the file stays attached to the issue. Linear also has natural language search and its own AI features, and it will happily tell you what closed in the last cycle.

Where it stops is the design side of the ledger. Linear knows about designs that somebody attached to an issue. It knows nothing about designs that exist and were never ticketed, which is precisely the population Priya's VP is asking about. The four orphaned frames she found by eye are, from Linear's point of view, not data. They are an absence, and no query against Linear can return an absence in a system Linear cannot see.

There is a second, subtler stop. Even where a Figma link is attached, Linear treats it as an attachment, not as a claim about scope. SKX-2210, "clean up billing page," has one Figma link on it, pointing at the file, not at any frame. Whether closing that issue means three frames are now built is a fact that exists only in the sentence somebody wrote in the issue description, and in a comment from the engineer that says "did the empty state too while I was in there."

Why the gap is structural, not a missing feature

Look at what each half of the evidence actually is.

Both products hold clean records. Both are queryable. The problem is that the thing connecting a frame to an issue is very often not a record on either side. It is a sentence: "this covers the empty states from Priya's file," or a comment on frame 14 saying "moved to Q4, deprioritised," or an engineer noting in the PR that the design changed during implementation and the Figma file is now stale.

That is why this is not a reporting feature Figma or Linear forgot to build. A reporting feature operates over the records a product holds. Neither product holds the sentence that lives in the other, and even inside Linear, the sentence in a description is prose, not a field. You could ask both products for perfect exports and still not have the answer, because the answer depends on reading text and forming a view.

It is worth being precise about the two adjacent categories people reach for here, because both are good at things this is not.

Automation platforms like Zapier and Make will absolutely connect Figma and Linear. They are trigger based: something happens, so do the next thing. Create an issue when a frame is marked ready, post to Slack when an issue closes. That moves work forward, and it does it well. What a trigger cannot do is answer a question about the accumulated present state of things that already happened, including the things that never triggered anything. Priya's orphaned frames generated no event. There was nothing to fire on.

BI tools have the opposite shape. Power BI Copilot and Looker's Conversational Analytics genuinely handle natural language over data, and they are strong at it. But they operate over connected databases and modelled sources. A comment on a Figma frame and a paragraph in a Linear issue description are not in the model. They are not badly modelled, they are outside the set of things the tool can see at all. You cannot chart your way to evidence that is a sentence.

What the join actually requires

Two things, and only one of them is mechanical.

The key. In practice it is the Figma node URL, the one containing node-id, appearing somewhere in Linear: in an issue description, an attachment, or a comment. That is a matchable string. Normalise it, strip query parameters, map file key plus node id to frame name via the Figma file, and you have a hard link from a subset of frames to a subset of issues. This part is deterministic and you should do it first, because it resolves most of the volume cheaply.

The judgement. Everything the key misses. A frame with no node link anywhere, where an issue titled "billing empty states" plainly covers it. An issue with a link to a frame that has since been replaced by a redesigned version, where the link resolves but the design is stale. A Figma comment saying "parking this until pricing lands," which means the frame is not waiting on engineering at all and should not appear in a "designed but not built" count. An engineering comment saying the final build diverged from the design.

None of that is a matching problem. It is a reading problem: pulling the text from both sides and forming a defensible view about what it means, then showing the text so a human can disagree.

How you would answer it with Skopx

Skopx connects to nearly 1,000 SaaS tools, Figma and Linear among them, and answers questions across them with citations back to the source. The realistic thing Priya types, in chat, on the Monday morning:

Go through the Billing Redesign Figma file and the Payments team's Linear issues for the last two cycles. For every frame marked ready for dev, tell me whether it shipped, is in progress, or has nothing tracking it. Use node links where they exist, and read issue descriptions and comments for the rest. Flag anything where the design changed after the issue closed.

What comes back is a list per frame, each row carrying its evidence: the Linear issue and its state where one was found, the specific sentence in a description or comment that justifies the match where the link was missing, and an explicit "no issue found" for the orphans, with the frame's last edit date so she can see how long it has been sitting.

The distinction that matters is that the last-resort evidence is a quotation, not a join. When SKX-2210's link to a frame does not exist but the engineer's comment says "did the empty state too," that comment is what the answer rests on, and it is shown, so Priya can look at it and decide it is not good enough.

If that question turns out to be a recurring one, and this kind of question always is, the second half is that the same sentence can become a standing console. You describe what you want to look at, and Skopx builds it: a table of ready-for-dev frames with linked issue, current state, days since design finalised, and a match-confidence column separating hard node-link matches from inferred ones, plus a filter for the orphans. That is what Internal Apps does, and it is worth being exact about the shape of the thing. It reads from Figma and Linear and it can act back into them: an approved button on a row can create the missing Linear issue, or drop a comment on a frame, after a confirmation dialog. It stores nothing of its own. There is no form, no new record type, no scheduled run, no alert, no public link. It is a live view over your two systems with a small number of deliberate write buttons on it.

Honest limits

This does not make the join true. It makes the reasoning visible. If an engineer shipped a design and wrote nothing anywhere, no tool recovers that, and this one will report the frame as untracked because that is what the evidence says.

Inferred matches are inferences. The confidence column exists because the reading step is genuinely fallible, and a "designed but not built" list produced this way is a starting point for a fifteen-minute conversation, not a number to put in a board deck unreviewed.

It does not watch. There are no alerts when a frame goes stale and nothing runs overnight. You ask, or you open the console, and it reads current state at that moment.

It does not fix your hygiene. Teams that consistently paste node links into issues get near-deterministic answers here. Teams that do not will lean on the reading step much harder, and should expect to check more rows.

Skopx is $16 per seat per month for Team, including 2.3 million AI tokens per seat, and $5 for Solo. SOC 2 controls are in place. The honest pitch is narrow: this does not replace Figma or Linear, both of which are doing their own jobs correctly. It answers the question that sits in the space between them, the one that currently costs a design lead ninety minutes and a lingering doubt that she missed something.