Notion and Linear: finding the spec items with no engineering issue

It is Thursday afternoon, eight days before the Billing v2 release. Priya, the product manager, has the spec open in Notion. It is a long page: a context section, a scope section with about thirty bulleted requirements under four headings, and an acceptance criteria table near the bottom that two people edited last week. Dan, the engineering manager, has Linear open on the other screen, filtered to the Billing project, current cycle, 41 issues, six of them still in Backlog.

The question on the call is simple to ask and slow to answer: is anything in the spec not represented by an issue. Not "are we on track", which the cycle graph answers. The narrower one. Which written requirements have nothing in Linear that covers them.

So they do what everyone does. Priya reads a bullet out loud. Dan types four words of it into Linear search. Sometimes an issue comes up. Sometimes it does not, and they cannot tell whether the work is missing or the issue is worded differently. Thirty bullets, forty minutes, and at the end they are still not confident. Two weeks later, in the release retro, somebody finds the dunning email requirement that nobody ever filed.

What Notion shows on its own

Notion holds the spec well. It has the full text, the edit history, the comment threads where the pricing question got settled, and backlinks from any page that references this one. If the requirements are rows in a Notion database rather than bullets in a paragraph, Notion can filter and group them, and it can show a property for status, owner, or a pasted Linear URL.

Notion also connects to Linear. With the connection set up, a Linear link pasted into a page unfurls into a titled preview showing the issue state, and a synced view can bring Linear issues into a Notion page so you can read them without switching tabs. This is genuinely useful and it is what most people mean when they search for a notion linear integration.

Here is precisely where it stops. Notion can show you issues, and it can filter rows by a property. What it cannot do is evaluate a sentence in a bulleted list against a set of issues and tell you the sentence has no counterpart. Notion search finds pages that contain words. There is no query for a requirement that lacks something elsewhere, because in Notion the requirement is prose, and prose has no field to be empty.

There is one honest exception worth naming. If every requirement is a database row, and every row has a Linear URL property, and somebody fills that property in every time, then a filter for "Linear URL is empty" answers the question exactly. That is a real answer. It just depends entirely on a discipline that decays the week a release gets tight.

What Linear shows on its own

Linear is the better half of this pair for structure. Every issue has an identifier, a state, an assignee, a team, a project, an estimate, labels, and timestamps. Views and filters over that are fast and precise. You can list everything in the Billing project that is unestimated, unassigned, or still in Backlog with six days left. Linear also holds documents and project resources, so the spec link often lives right on the project, and an issue description can carry a link back to the exact Notion block.

Where Linear stops is not a weakness in Linear. Linear can describe, filter, and sort every issue that exists. It cannot report on an issue that was never created. Absence, here, is defined by a document Linear does not own. The set you are asking about, requirements with no issue, has no rows in Linear at all. There is nothing to filter.

Why the gap is structural

Look at the two halves of the evidence side by side.

The Linear half is a record. BIL-214, In Progress, assigned, in project Billing v2, created 11 days ago. It has fields. Fields can be joined, counted, filtered, and left empty.

The Notion half is a sentence somebody wrote. "Dunning emails must stop as soon as a card succeeds, including retries already queued." That sentence sits in a bulleted list under a heading, written by a person who was thinking about billing behaviour, not about data structure. It has meaning. It does not have a key.

A join needs a key on both sides. That is the whole problem in one line. When people search for notion linear sync, what they get, correctly, is machinery for moving records between two tools that both hold records. The requirement was never a record. It became one only in the sense that a page stores it as text.

This is also why the neighbouring categories of tool do not close it. Zapier and Make are excellent at what they do, and workflow automation is trigger based by design: something happens, and the platform moves a record forward. Nothing happened here. The event you care about is a non-event, a bullet that quietly never became an issue, and there is no trigger for something failing to occur. On the other side, Power BI Copilot, Looker Conversational Analytics and Retool all sit on top of data you can query. They handle databases and modelled sources very capably. A sentence inside a Notion page is not in the model. It is not that these products read it badly. It is outside what they read at all.

So this is not a reporting feature Notion or Linear forgot to build. Half the evidence lives in a shape neither product's query layer covers.

What the join actually requires

Two things: a key, and a judgement call.

The key, in practice, is whichever of these exists in your setup. An explicit issue identifier or URL written next to the requirement. A Notion page URL in the issue description or in Linear's project resources. Or, failing both, the project boundary itself: everything under the "Billing v2" heading in the spec, against everything in the Linear project of that name.

The judgement call is the part matching cannot do. An issue titled "Retry logic for failed charges" plainly covers two spec bullets and arguably half of a third. A requirement may be handled inside a sub-issue nobody linked, or by an issue on the Payments team's board, or by one that was closed as a duplicate of another. String similarity gets some of these and confidently gets others wrong. Deciding whether an issue covers a requirement means reading both and forming a view.

How you would answer it with Skopx

Skopx sits on top of both tools, along with nearly 1,000 others, and answers questions in chat with citations. The realistic sentence someone types on that Thursday afternoon is close to what Priya would have said out loud:

Read the Billing v2 spec in Notion. Pull every requirement under Scope and Acceptance Criteria, then check the Billing v2 project in Linear and tell me which requirements have no issue covering them. Quote each requirement and link the issue where there is one.

What comes back is a list. Each line carries the requirement quoted verbatim, a link to the Notion block it came from, the matching Linear issue and its state, or the words "nothing found", and one line of reasoning where a judgement was made. The citations matter more than the verdict, because they are what lets Dan disagree with a row in four seconds instead of relitigating the whole exercise.

When the question comes back every release, which it does, the same thing works better as a standing console. You describe it in a sentence and Skopx builds the screen: that is what internal apps are for. The console shows one row per requirement, with columns for the source heading, the matched issue and its state, and a coverage confidence, plus a filter to show only the unmatched. Each unmatched row carries a button that creates the issue in Linear, pre-filled with the requirement text, project and team, behind a confirmation showing exactly what will be written. That is the only write in the whole thing. The console stores nothing of its own. Every row is read fresh from Notion and Linear when someone opens it.

Honest limits

It does not watch. If a requirement gets added to the spec at six in the evening, nobody is notified. The console is a thing you open, not a thing that pings you.

It reads with your permissions. A Notion page you cannot see, Skopx cannot see on your behalf.

It will get coverage calls wrong sometimes. Broad issues are the usual failure: it will mark a requirement covered when the issue really handles two thirds of it. This is why every row shows the quote and the link. The output is built to be checked, not trusted blind.

If the spec is vague, the answer is vague. "The billing flow should feel faster" is not a requirement that can be matched to anything, and no amount of reading fixes that.

And it is not a substitute for linking issues to the spec in the first place. Where that link exists, matching is trivial and certain. This is for the ninety percent of releases where it does not.

Team is $16 per seat per month and includes 2.3 million AI tokens per seat. Solo is $5.