← All Skills
Enhanced · live dataX (Twitter) Agent

X (Twitter) Data Skill

The X (Twitter) Data Skill is the source-sliced data guide a Platform Agent owns: it names the concrete `x/...` operations, response shapes, and gotchas for reading public X/Twitter data through UnifAPI MCP, so any X-first research (KOL pricing, creator vetting, buying signals, competitor and listening work) runs from one deterministic workflow. Read-only — it never posts.

Agent-native

Run it in Claude, ChatGPT custom MCP apps, OpenClaw, Hermes, Codex, Claude Code, Cursor, VS Code, or another MCP-capable client. No dedicated GUI flow and no separate LLM API key.

Backed by live public data

Every step is grounded in live public-data records UnifAPI returns, so the output cites what is actually ranking, posting, or being said — not a generic best-practice list.

Composable & open source

Skills cross-reference each other and live in a public, MIT-style repo. Read the full SKILL.md on GitHub, fork it, or run it as-is inside your agent.

Run prompt

Paste this into Codex or Claude Code

The prompt is intentionally editable. Replace the handles, market, budget, and campaign goal, then let the agent call UnifAPI MCP when it needs live public data.

Using the X (Twitter) Data Skill, pull the public profile and recent engagement for @vercel and @shadcn: resolve each handle, read follower count and recent-tweet public_metrics, and return a cited summary. Read-only.
How the skill works

The full skill, rendered from its SKILL.md

The deterministic read path for public X (Twitter) data through UnifAPI. This is a Data Skill: it does not run a marketing job on its own — it names the concrete x/... operations, response shapes, and gotchas so any X-first workflow (KOL pricing, creator vetting, buying signals, competitor and listening work) reads from one known recipe instead of rediscovering the surface each time.

Read-only — eyes, not hands. It researches public X data and returns cited records; it never posts, replies, follows, or DMs, and UnifAPI never holds X credentials.

Use the unifapi skill for live evidence

Connect once through the shared unifapi skill (OAuth MCP), then call the operations below. The X integration is backed by RapidAPI SocialLab but the public contract uses X-style /x/... paths — do not use legacy /twitter/... paths. Keep any billing metadata so the output can state record cost.

Response contract

Single-entity endpoints return the object in data:

{
  "request_id": "unif_...",
  "data": {},
  "billing": { "records_charged": 1, "balance_remaining": 99 }
}

List endpoints return an array in data plus pagination:

{
  "request_id": "unif_...",
  "data": [],
  "pagination": { "has_more": false, "next_cursor": null },
  "billing": { "records_charged": 1 }
}

When pagination.has_more is true, pass pagination.next_cursor as the next request's pagination_token (next_token is also accepted). Always preserve billing when reporting cost.

Core operations

NeedOperation
Profile by handlex/users/by/username/{username}
Profiles by handlesx/users/by (?usernames=a,b)
Profile by idx/users/{id}
Profiles by idsx/users (?ids=123,456)
Recent authored postsx/users/{id}/tweets (?max_results=10&exclude=replies)
Search recent postsx/tweets/search/recent (?query=...&max_results=10)
Autocomplete users/topicsx/autocomplete (?query=...)
Post by id / posts by idsx/tweets/{id} · x/tweets (?ids=123,456)
Who amplified a postx/tweets/{id}/retweeted_by · x/tweets/{id}/quote_tweets
Who liked a postx/tweets/{id}/liking_users
What a user likesx/users/{id}/liked_tweets
Followers / followingx/users/{id}/followers · x/users/{id}/following
Verified followersx/users/{id}/verified_followers
Regional trendsx/trends/by/woeid/{woeid}

Need a field not listed here? Use the unifapi skill's get_operation to read the exact schema before calling — but pick the operation from this table, don't discover blind.

Workflow

The deterministic recipes. Pick the one that matches the job; each names exactly what to call.

  1. Resolve a handle to a profile. Strip the leading @, then call x/users/by/username/{username}. Read data.id (needed for every per-user call below) and data.public_metrics.followers_count.
  2. Read recent engagement. With the id from step 1, call x/users/{id}/tweets?max_results=10&exclude=replies. Compute engagement from each tweet's public_metrics (like_count, retweet_count, reply_count, quote_count, impression_count). Page with x/users/{id}/tweets?pagination_token={next_cursor} when has_more.
  3. Trace who amplified a post. With a tweet id from step 2, call x/tweets/{id}/retweeted_by, x/tweets/{id}/quote_tweets, or x/tweets/{id}/liking_users to see who reposted, quoted, or liked it — the amplification and intent signal behind buying-signal, listening, and competitor work. Use x/users/{id}/liked_tweets for what a user engages with. Page via next_cursor.
  4. Gauge audience quality. Call x/users/{id}/verified_followers; it returns the verified followers as a paginated list, not a ready figure. Measure its size against data.public_metrics.followers_count from step 1 — that verified share is the real-vs-inflated signal that feeds confidence and warnings in downstream pricing/vetting skills. Page via next_cursor for a fuller count.
  5. Discover from a topic (no handles yet). Call x/tweets/search/recent?query=... for recent matching posts, or x/autocomplete?query=... for user/topic suggestions, then resolve the surfaced handles with step 1.
  6. Map a network. Call x/users/{id}/followers or x/users/{id}/following for audience-overlap or reach work; page via next_cursor.
  7. Read regional trends. Call x/trends/by/woeid/{woeid} for what's trending in a location (WOEID), e.g. for listening or content-timing.
  8. Cite everything. Every figure ties back to the post or profile it came from; report billing.records_charged (or estimate when billing metadata is absent).

Shape notes

  • XUser — metrics nested under public_metrics: followers_count, following_count, tweet_count, listed_count. Profile flags at top level: protected, verified, verified_type. Read public_metrics, not legacy flat fields.
  • XTweet — metrics nested under public_metrics: like_count, retweet_count, reply_count, quote_count, bookmark_count, impression_count. May include author and media when available.

Gotchas

  • Use /x/... paths, never /twitter/... (legacy). Old /twitter/users/{screen_name}x/users/by/username/{username}; old /twitter/searchx/tweets/search/recent (use x/autocomplete for user/topic discovery).
  • A protected, too-old, or too-thin timeline lowers confidence — surface it, don't paper over it.
  • Resolve the handle to data.id before any x/users/{id}/... call.
  • A low balance can silently truncate list pages: check billing.truncated_due_to_balance — when true the page is partial, so top up before trusting any count or share computed from it.

Output

Return the records the calling workflow needs, each cited to its post/profile, plus a one-line cost note (records_charged). When this skill is used directly, a compact profile + engagement summary per handle is the default:

**@handle** — followers {N}, verified {yes/no}. Recent 10 posts: avg engagement {x}% ({likes}/{reposts}/{replies}). Evidence: {post URLs}. Records: ~{N}.
  • kol-pricing, creator-shortlist, audience-fit-check (Influencer Marketing) — price and vet X creators on top of this read path.
  • buying-signal-monitor (Social Selling), competitor-profiling (Competitive Intelligence), social-listening-brief (Social Listening) — X-first intent, competitor, and listening work.
  • unifapi — the shared data skill: connect MCP and look up exact schemas with get_operation.

Source: x-twitter/SKILL.md on GitHub — open a PR there to improve it.

Public-data tools

The live APIs this skill calls

Every operation the skill names is one of these UnifAPI platforms — still visible and callable for product code, debugging, and custom agent flows.

  • The concrete `x/...` operations for each common X read job
  • Response-contract and `public_metrics` shape notes for users and tweets
  • Deterministic recipes: profile, engagement, discovery, followers, trends
  • Platform gotchas (RapidAPI-backed `/x/...` paths, pagination, billing)