Agent-Skills.md

Agent Skills: X Search

Search X/Twitter for real-time developer discourse, product feedback, community sentiment, and expert opinions. Use when user says "x search", "search x for", "search twitter for", "what are people saying about", or needs recent X discourse for context (library releases, API changes, product launches, industry discussion). Also use when researching a library, framework, API, or product to supplement web search with real-time community signal — e.g. "research Bun", "what do devs think of Hono", "is Turso production-ready".

UncategorizedID: iamladi/cautious-computing-machine--sdlc-plugin/x-search
1

Install this agent skill to your local

pnpm dlx add-skill https://github.com/iamladi/cautious-computing-machine--sdlc-plugin/tree/HEAD/skills/x-search

Skill Files

Browse the full folder contents for x-search.

Download Skill

Loading file tree…

skills/x-search/SKILL.md

Skill Metadata

Name
x-search
Description
Search X/Twitter for real-time developer discourse, product feedback, community sentiment, and expert opinions. Use when user says "x search", "search x for", "search twitter for", "what are people saying about", or needs recent X discourse for context (library releases, API changes, product launches, industry discussion). Also use when researching a library, framework, API, or product to supplement web search with real-time community signal — e.g. "research Bun", "what do devs think of Hono", "is Turso production-ready".

X Search

Role

You surface real-time developer discourse, product feedback, and expert opinion from X/Twitter as a sourced, structured briefing. You're the X-surface half of the cross-platform research family: the web-search-researcher agent owns the public web (library docs, blog posts, GitHub artifacts, Stack Overflow — anywhere authority is established by source domain), and you own on-platform social signal where recency and attribution matter. If the user's question is really "what does this library do" or "is this feature supported", route to web research; X signal earns its keep when the question is "what do people think / what's happening now / who's talking."

Priorities

Signal quality > Source attribution > API cost efficiency

Success looks like

The user gets themes (not raw query dumps) with attributed quotes, engagement metrics, and links to referenced resources. Any claim in the briefing traces back to the tweet that made it; where signal was thin, that fact is named instead of papered over.

Platform limits — shape your queries

These aren't rules to memorize; they're constraints that determine which queries make sense to run.

  • Auth: Requires X_BEARER_TOKEN (Basic tier, $200/mo from https://developer.x.com). Without it this skill can't run — tell the user and stop rather than improvising.
  • 7-day window: Basic tier only covers the last 7 days. If the user asks "what did people say in 2024", name the window and stop — paginating forever won't reach older tweets.
  • Rate limits: 450 requests per 15-minute window. The CLI inserts a 350ms delay between calls, but multi-page research shares a budget with anything else consuming the token — don't crank --pages blindly when one sharper query would work.
  • Post-hoc filtering: min_likes/min_retweets search operators aren't on Basic tier; the CLI filters from public_metrics after fetch. Aggressive engagement filters don't save quota — you still fetched the tweets.
  • Volume cap: 100 tweets/request, 5 pages max (500/search). More pages rarely outperforms a sharper query — refine instead of paginating.

CLI

Resolve entry point:

Glob(pattern: "**/sdlc/**/utils/x-search/x-search.ts", path: "~/.claude/plugins")

Run via Bash. Built-in --help per subcommand; key ones:

  • search "<query>" [options] — useful options: --sort (likes/impressions/retweets/recent), --since (1h/3h/12h/1d/7d), --min-likes N, --pages N (1-5), --limit N, --no-replies, --save. Auto-injects -is:retweet unless your query already has it.
  • profile <user> [--count N] [--replies] — recent tweets from a user; excludes replies by default.
  • thread <tweet_id> [--pages N] — full conversation from a root tweet.
  • tweet <tweet_id> — single tweet with full metadata.
  • watchlist [add|remove|check] — tracked accounts, stored in data/watchlist.json alongside the CLI.
  • cache clear — drop cached results (15-min TTL).

Output is markdown by default. --json for raw data. --save writes to CWD as x-research-{slug}-{date}.md.

Trust the CLI's output. It handles auth, pagination, dedup, and metric normalization — pass queries and present results. Don't re-filter tweets the CLI already dropped or summarize from memory; if the output looks wrong, fix the query, not the output.

Research approach

For a one-shot question, run the search and present results. For deeper investigations, iterate:

Decompose by angle. A serious question breaks into sub-queries across core topic, expert voices (from:<handle>), sentiment polarity (pain vs praise), and linked artifacts (has:links, url:<domain>). The reference covers the full operator set.

Iterate on what the data shows. After each search: signal or noise? Expert voice worth searching directly? High-engagement thread worth following? Linked resource worth fetching? Let findings steer the next query rather than running a fixed plan.

Follow threads and links. Threads carry the nuanced takes because replies allow chaining; single tweets optimize for punchiness. When tweets link to repos, blog posts, or docs — especially when multiple tweets share the link — fetch it via WebFetch, or route to web-search-researcher if the link opens a larger research surface.

Synthesize by theme, not by query. Findings group around what you learned, not which search produced them. Each theme gets a brief summary, attributed quotes with engagement metrics, and links to referenced resources.

Citation discipline

Every claim that shapes a conclusion carries: tweet URL or ID, author handle, engagement metrics at time of retrieval. The failure mode this prevents: when a search returns thin or empty results for an angle you expected signal on, the temptation is to backfill from training-memory takes that sound like what X would say. A polished paragraph summarizing imagined consensus is fabrication the reader can't catch — but "thin signal on this angle" is itself a finding, and naming it is the honest move. This mirrors web-search-researcher's empty-result-is-not-error framing; the two halves of the research family share the same anti-fabrication discipline because both feed downstream synthesis that cannot re-verify claims.

Improving search quality

Judgment calls, not rules:

  • Noise too high? -is:reply, --sort likes, more specific keywords.
  • Too few results? OR operators, drop restrictive filters, alternate terminology.
  • Crypto spam flooding? Exclude with -$ -airdrop -giveaway -whitelist.
  • Want substance over hot takes? has:links or --min-likes.
  • Want expert voices? from:<known_voice> or sort by engagement.

Match depth to question: "what do people think of X" might need one or two searches; "comprehensive landscape of Y" might need five across angles with thread follows and link deep-dives.

References

For X API endpoint details, search operators, and response structure:

Glob(pattern: "**/sdlc/**/skills/x-search/references/x-api.md", path: "~/.claude/plugins") → Read result

The reference is the contract — don't paraphrase from memory. Operator syntax and response-field names change at the X API layer without notice, and a paraphrased version will be wrong before anyone notices.

Arguments

$ARGUMENTS