X bookmarks are a useful signal source, but they are a terrible source of truth.
They collect ideas, workflows, teardown threads, product angles, and market hints faster than a human can process them. The failure mode is obvious: you pull everything into your project tracker, create a pile of low-quality tickets, and then pay again later to rediscover the same inputs.
The better pattern is to treat X as a paid inbox and Linear as the operating queue.
That means the workflow starts with Linear, not X.
The rule: check backlog capacity before calling X
Before fetching bookmarks, check how many Linear issues are still not done.
For our Build Lean SaaS queue, the cap is intentionally simple:
If the queue is already at or above the cap, the automation stops before touching X.
That one gate prevents the expensive failure mode: paying for more inputs when the team has no room to act on them.
X is the scarce input; Linear is the work queue
The cost model matters.
Linear API calls are cheap enough for normal operational use. They still have rate limits, but counting, creating, and updating a small number of issues is not the scarce resource.
X API calls are different. For meaningful API usage, they are paid or credit-limited. So every X read should produce one of three outcomes:
- A Linear ticket was created.
- The bookmark was identified as a duplicate of something already captured.
- The bookmark was intentionally skipped and recorded as processed.
If none of those things happen, the read was waste.
The ingestion loop
The workflow I want is intentionally conservative:
The important safety rule is this:
Never remove the X bookmark until the idea has either been captured in Linear or intentionally recorded as processed.
Bookmarks should disappear only after the system has somewhere else to point.
Why delete bookmarks after capture?
Leaving processed bookmarks in X creates two problems:
- Future ingestion runs see the same material again.
- Humans cannot tell what still needs review.
If a bookmark has become a Linear ticket, the bookmark has done its job. The source URL belongs in the ticket description, not in an ever-growing X backlog.
This turns bookmarks into an actual inbox:
That is much cleaner than using bookmarks as a permanent archive.
Dedupe by source URL, not title
Titles drift. Summaries vary. Agents rewrite things differently from run to run.
The stable keys are:
- tweet ID
- tweet URL
- Linear issue ID
A local cache can be as simple as a JSONL file:
Linear descriptions should also include the source URL. That gives you a second dedupe path if the local cache is missing or the automation runs from a different machine.
What happened on the first gated run
The first real test did exactly what it was supposed to do: it stopped.
The Build Lean SaaS Linear queue was already above the cap, with more than 200 issues still not done. Because of that, the automation did not fetch new X bookmarks and did not spend additional X API credits.
That is the point of the gate. A quiet stop is a successful run when the queue is full.
The next step is backlog grooming: close completed work, cancel stale ideas, merge duplicates, and park low-value items before asking X for more inputs.
The operating principle
A good automation does not just move data between tools. It protects the system from creating work it cannot absorb.
For this workflow, the principle is:
Pull from X only when Linear has room. Create tickets only when the bookmark is actionable. Delete bookmarks only after capture.
That keeps the queue clean, preserves the source trail, and avoids paying to process the same idea twice.