read-x-articles

Read X (Twitter) Articles

Turn any X link a user shares into the full article text. Do NOT default to "I can't read X" — X long-form Articles DO extract cleanly via the right URL.

When to Use

• A user drops an x.com/... or twitter.com/... link and expects you to read it.
• The link is an X Article (long-form essay/interview) — canonical path

/i/article/<ID>.

• You need primary source text from an X essay/thread as material for work

(e.g. writing, video scripts, analysis).

• Anyone claims "X content can't be read" — that is the signal to trigger, not

capitulate.

The core insight (learned 2026-08-12)

• X Articles are readable end-to-end at the canonical

`https://x.com/i/article/<ID>` when fetched by a JS-executing web-extractor / browser tool — that returns the FULL body, not a snippet.

• **Bare HTTP fetch (urllib/curl) of the article often returns a login/JS

shell.** The canonical URL is necessary but a plain request is NOT sufficient — you need a render-capable tool. This is why web_extract (SE/agent-grade) succeeds where curl fails.

• `/status/<id>` posts and profile pages are JS-rendered and hit the

login wall → they come back empty even to a browser. That is the apparent "can't read X." The fix is resolving the article URL AND using the right fetch tool, not giving up.

• Images matter. The article's cover, diagrams, charts, and screenshots

can be essential to understanding it. Extract the media URLs and analyze them (vision) as part of the read — do not stop at the text.

Steps

1. Try first, judge later. When given any X link, immediately attempt it

with a web-extract/browser tool. Declaring it unreadable before trying is the exact mistake this skill prevents.

1. Use the right fetcher: prefer the agent's web_extract-style tool or a

browser render — NOT bare curl/urllib. If the only tool is a plain HTTP client, expect a login shell and fall back to a browser.

1. If it's a `/status/` URL or returns a login/JS shell, resolve the

canonical article URL:

• The article ID often appears in the status link's query/path when the

post is an article share.

• Find the author's /i/article/<ID> share link on their profile, or ask

the user for the article link directly.

• Then fetch https://x.com/i/article/<ID> with a render-capable tool.

1. Validate the body: a real extract contains substantive paragraphs, NOT

just "Log in or sign up for X." A 1,900+ word essay returns complete.

1. Fallbacks if a render-capable extract still fails:

• Use a browser tool (CDP-style) to render the JS page, then read the

rendered text/DOM.

• If the account has X API access (e.g. an xurl-style CLI), query the

article tweet and read data.article.plain_text. A dead/unauthed CLI token is NOT a blocker — prefer web/browser first.

1. Use the content. It's legitimate primary source. Quote it and cite the

author. If it's a community take (e.g. a power-user writing about a product), it's still real material for summaries, scripts, and analysis.

1. Read the images too. After extracting the body, the text extractor may

drop inline images (screenshots, diagrams, UI captures) that are essential to understanding the article. Fetch the raw HTML of the page (curl or similar) and extract all pbs.twimg.com/media/ URLs — these are the article's inline images. Analyze the meaningful ones (not user avatars) with a vision tool. Report any visual info that adds to the text: screenshots of a UI, diagrams that explain a workflow, charts with data, or a cover that sets the tone. Do not skip this — images are part of the article.

Pitfalls

• Do not assume "articles are paywalled/login-walled." The canonical

/i/article/<ID> endpoint serves plain text; the wall applies to the JS-rendered profile/status pages, not this endpoint.

• A dead X API token (401) is unrelated to article reading — do not block the

task on fixing xurl/auth when web extraction works.

• Verify you got the actual article (thesis + body), not just a title + login

prompt, before treating it as read.

Verification

• Did the extraction return the article's real prose (title, paragraphs,

thesis) rather than a shell? If yes, it's read.

• Report the exact URL you read + a short grounded summary so the user can

verify.