X Twitter Scraper
Use this skill when a user wants to integrate Xquik into an app, script, data pipeline, or AI agent workflow for X API and Twitter scraper tasks.
Use Cases
- Search tweets, fetch tweet details, read timelines, and download media.
- Look up users, check relationships, and export followers or following.
- Start extraction jobs for replies, reposts, quotes, likes, lists, communities, articles, and search results.
- Create account monitors and verify HMAC-signed webhook events.
- Add TypeScript, Python, Go, Java, Kotlin, C#, Ruby, PHP, CLI, or Terraform clients.
- Connect agent runtimes through the Xquik MCP server.
- Install TweetClaw when the workflow belongs inside OpenClaw and needs plugin-managed approvals for X account actions.
Source Checks
Before writing code, inspect the current Xquik source material:
Do not invent endpoint names, request fields, response fields, scopes, pricing, limits, or package names. Read the relevant SDK README and API reference page first.
Implementation Flow
- Identify the workflow: search, lookup, extraction, monitor, webhook, media, write action, billing, or MCP.
- Choose the integration surface: generated SDK for application code, REST for custom clients, MCP for agents, TweetClaw for OpenClaw plugin workflows, or webhooks for event delivery.
- Confirm authentication requirements from the docs and use environment variables for API keys.
- Use typed request and response models when an SDK exists for the user's language.
- Add retries and pagination according to the SDK or API docs.
- Add explicit user confirmation before write actions, payment flows, or long-running monitoring.
- Keep webhook verification server-side and compare HMAC signatures before processing events.
- Return structured data to the caller instead of scraping generated UI output.
SDK Pattern
When application code is involved, match the SDK to the user's project language:
- Inspect project files and package manifests to identify the language and framework.
- Open the SDK index, then read the matching SDK README before choosing install commands, package names, imports, or client methods.
- Prefer the official SDK for the detected language when one exists.
- Use REST only when the project language has no suitable official SDK or the user asks for a custom client.
- Keep API keys in environment variables or the project's existing secret manager.
Use project-native typed request and response models. Keep network calls in server-side code unless the SDK docs explicitly support browser use.
Webhook Pattern
When adding webhook handlers:
- Read the documented signing header name and payload format.
- Verify the HMAC signature before parsing business logic.
- Reject missing, malformed, or mismatched signatures.
- Make handlers idempotent because webhook delivery can retry.
- Store only the fields needed for the product workflow.
MCP Pattern
Use the MCP server when the user wants an agent to explore or call Xquik tools directly. Keep application code on REST or SDK clients when the app needs stable typed contracts, tests, or internal abstractions.
OpenClaw Plugin Pattern
Use TweetClaw when the user is working in OpenClaw, wants installable plugin metadata, or needs an approval-reviewed path for account-changing X actions. Keep application services on REST or SDK clients when the project needs typed contracts, server-side abstractions, or long-lived backend jobs outside OpenClaw.
Before suggesting install commands or tool names, read the TweetClaw README and package metadata. Do not assume the published npm version matches source HEAD.
Treat create, reply, quote, like, bookmark, retweet, follow, delete, media, and monitor actions as approval-worthy unless the current TweetClaw docs state a narrower policy. Keep read-only tweet search, reply search, profile lookup, follower export, and evidence collection low risk, while still respecting rate limits and account authorization.
Safety And Accuracy
- Keep language neutral and technical.
- State that Xquik is a third-party X data and automation API.
- Do not claim affiliation with X Corp.
- Do not bypass access controls or platform policies.
- Do not expose API keys, webhook secrets, account cookies, tokens, or raw signatures.
- Do not hard-code credentials in examples or tests.
- Do not document private infrastructure details.
- Prefer official Xquik docs, SDK READMEs, and the OpenAPI spec over memory.
Source: github/awesome-copilot → skills/x-twitter-scraper/SKILL.md
1---2name: x-twitter-scraper-23description: Build GitHub Copilot workflows with Xquik X API SDKs, REST endpoints, MCP tools, TweetClaw OpenClaw plugin installs, signed webhooks, tweet search, user lookup, follower exports, media actions, and agent automation.4---5# X Twitter Scraper
6
7Use this skill when a user wants to integrate Xquik into an app, script, data pipeline, or AI agent workflow for X API and Twitter scraper tasks.
8
9## Use Cases
10
11- Search tweets, fetch tweet details, read timelines, and download media.
12- Look up users, check relationships, and export followers or following.
13- Start extraction jobs for replies, reposts, quotes, likes, lists, communities, articles, and search results.
14- Create account monitors and verify HMAC-signed webhook events.
15- Add TypeScript, Python, Go, Java, Kotlin, C#, Ruby, PHP, CLI, or Terraform clients.
16- Connect agent runtimes through the Xquik MCP server.
17- Install TweetClaw when the workflow belongs inside OpenClaw and needs plugin-managed approvals for X account actions.
18
19## Source Checks
20
21Before writing code, inspect the current Xquik source material:
22
23- REST API docs: https://docs.xquik.com/api-reference/overview
24- SDK index: https://docs.xquik.com/sdks
25- OpenAPI spec: https://xquik.com/openapi.json
26- MCP server docs: https://docs.xquik.com/mcp/overview
27- Skill repo: https://github.com/Xquik-dev/x-twitter-scraper
28- TweetClaw OpenClaw plugin: https://github.com/Xquik-dev/tweetclaw
29- TweetClaw npm registry metadata: https://registry.npmjs.org/@xquik%2Ftweetclaw
30
31Do not invent endpoint names, request fields, response fields, scopes, pricing, limits, or package names. Read the relevant SDK README and API reference page first.
32
33## Implementation Flow
34
351. Identify the workflow: search, lookup, extraction, monitor, webhook, media, write action, billing, or MCP.
362. Choose the integration surface: generated SDK for application code, REST for custom clients, MCP for agents, TweetClaw for OpenClaw plugin workflows, or webhooks for event delivery.
373. Confirm authentication requirements from the docs and use environment variables for API keys.
384. Use typed request and response models when an SDK exists for the user's language.
395. Add retries and pagination according to the SDK or API docs.
406. Add explicit user confirmation before write actions, payment flows, or long-running monitoring.
417. Keep webhook verification server-side and compare HMAC signatures before processing events.
428. Return structured data to the caller instead of scraping generated UI output.
43
44## SDK Pattern
45
46When application code is involved, match the SDK to the user's project language:
47
48- Inspect project files and package manifests to identify the language and framework.
49- Open the SDK index, then read the matching SDK README before choosing install commands, package names, imports, or client methods.
50- Prefer the official SDK for the detected language when one exists.
51- Use REST only when the project language has no suitable official SDK or the user asks for a custom client.
52- Keep API keys in environment variables or the project's existing secret manager.
53
54Use project-native typed request and response models. Keep network calls in server-side code unless the SDK docs explicitly support browser use.
55
56## Webhook Pattern
57
58When adding webhook handlers:
59
60- Read the documented signing header name and payload format.
61- Verify the HMAC signature before parsing business logic.
62- Reject missing, malformed, or mismatched signatures.
63- Make handlers idempotent because webhook delivery can retry.
64- Store only the fields needed for the product workflow.
65
66## MCP Pattern
67
68Use the MCP server when the user wants an agent to explore or call Xquik tools directly. Keep application code on REST or SDK clients when the app needs stable typed contracts, tests, or internal abstractions.
69
70## OpenClaw Plugin Pattern
71
72Use TweetClaw when the user is working in OpenClaw, wants installable plugin metadata, or needs an approval-reviewed path for account-changing X actions. Keep application services on REST or SDK clients when the project needs typed contracts, server-side abstractions, or long-lived backend jobs outside OpenClaw.
73
74Before suggesting install commands or tool names, read the TweetClaw README and package metadata. Do not assume the published npm version matches source HEAD.
75
76Treat create, reply, quote, like, bookmark, retweet, follow, delete, media, and monitor actions as approval-worthy unless the current TweetClaw docs state a narrower policy. Keep read-only tweet search, reply search, profile lookup, follower export, and evidence collection low risk, while still respecting rate limits and account authorization.
77
78## Safety And Accuracy
79
80- Keep language neutral and technical.
81- State that Xquik is a third-party X data and automation API.
82- Do not claim affiliation with X Corp.
83- Do not bypass access controls or platform policies.
84- Do not expose API keys, webhook secrets, account cookies, tokens, or raw signatures.
85- Do not hard-code credentials in examples or tests.
86- Do not document private infrastructure details.
87- Prefer official Xquik docs, SDK READMEs, and the OpenAPI spec over memory.
88
89---
90
91**Source:** [`github/awesome-copilot`](https://github.com/github/awesome-copilot) → `skills/x-twitter-scraper/SKILL.md`
thedixitjain