Twitter Post

Post tweets to Twitter/X via the official API v2 (OAuth 1.0a). Use when the user asks to tweet, post to Twitter/X, send a thread, reply to a tweet, or quote...

Security Scan

The skill appears to implement tweeting correctly, but its registry metadata does not declare the four required Twitter OAuth credentials (and primary credential), which is a significant inconsistency the user should understand before installing.

Purpose & Capability

The name/description, SKILL.md, and scripts/tweet.js all align: the code posts tweets via Twitter API v2 using OAuth 1.0a. However, the registry metadata lists no required environment variables or primary credential, while both SKILL.md and scripts/tweet.js require four sensitive OAuth env vars (TWITTER_CONSUMER_KEY, TWITTER_CONSUMER_SECRET, TWITTER_ACCESS_TOKEN, TWITTER_ACCESS_TOKEN_SECRET). This mismatch between declared requirements and actual required credentials is incoherent and should be resolved.

Instruction Scope

SKILL.md instructs the agent to execute scripts/tweet.js via exec and to rely on the four OAuth env vars; those instructions are within the stated purpose (posting tweets). But the instructions access environment variables that are not declared in the registry metadata (see above). SKILL.md also suggests storing credentials in the OpenClaw instance config or shell profile — guidance that has security implications but stays within tweeting scope. There are no instructions to read unrelated files or exfiltrate data to unexpected endpoints.

Install Mechanism

There is no install spec that downloads remote code; the skill bundles a local script (scripts/tweet.js). No external downloads, package installs, or extract steps are present. This is a low-risk install mechanism in that nothing arbitrary is fetched at install-time.

Credentials

The four OAuth env vars required by the script are appropriate for a Twitter posting skill, but the registry metadata does not declare them (no primaryEnv and 'Required env vars: none'). Requesting four sensitive secrets is proportionate to the function itself, but the omission in the declared requirements is a notable governance/visibility problem: users may not realize the skill needs OAuth tokens and may store them in places that broaden exposure. The script also recognizes HTTPS_PROXY and TWITTER_DRY_RUN, which are reasonable optional env vars.

Persistence & Privilege

The skill does not request always:true and is user-invocable only. It does not modify other skills or system-wide settings and does not ask to persist credentials itself beyond recommending storing env vars in instance config or shell profiles (which is normal but has security implications).

What to consider before installing

This skill's code implements posting to Twitter/X and legitimately needs four OAuth credentials (consumer key/secret and access token/secret). However, the registry metadata incorrectly shows no required credentials — treat that as a red flag. Before installing: (1) verify you obtained the credentials from developer.x.com and understand where you'll store them; prefer per-skill secret storage rather than plain shell profiles; (2) create a dedicated Twitter app / tokens with least privilege (Read+Write only for this app) and use tokens you can revoke/rotate; (3) inspect scripts/tweet.js (it posts only to api.twitter.com and supports an optional HTTPS_PROXY) and run with TWITTER_DRY_RUN=1 first to check behavior; (4) confirm OpenClaw's secret storage protections (who/what can read instance config) because storing OAuth tokens in instance config can expose them to other skills or admins; (5) ask the publisher to correct the registry metadata to declare the required env vars/primary credential and provide a homepage or source provenance. If you cannot verify provenance or the secret-storage protections, treat installation as higher risk and consider alternatives (official integrations or verified plugins).

Post tweets via the official Twitter/X API v2 using OAuth 1.0a authentication.

Prerequisites

Four environment variables must be set. Obtain them from developer.x.com:

TWITTER_CONSUMER_KEY=<API Key>
TWITTER_CONSUMER_SECRET=<API Key Secret>
TWITTER_ACCESS_TOKEN=<Access Token>
TWITTER_ACCESS_TOKEN_SECRET=<Access Token Secret>

Optional:

• HTTPS_PROXY — HTTP proxy URL (e.g. http://127.0.0.1:7897) for regions that need it
• TWITTER_DRY_RUN=1 — validate and print without posting

Setup

Store credentials as env vars. Recommended: add to the OpenClaw instance config or export in shell profile. Never hardcode keys in SKILL.md or scripts.

If the user hasn't set up OAuth yet, guide them:

1. Go to developer.x.com → Dashboard → Create App
2. Set App permissions to Read and Write
3. Go to Keys and tokens tab
4. Copy API Key, API Key Secret
5. Generate Access Token and Access Token Secret (ensure Read+Write scope)
6. If the portal only shows Read, use PIN-based OAuth flow:
   • Call POST /oauth/request_token with oauth_callback=oob
   • User opens https://api.twitter.com/oauth/authorize?oauth_token=<token>
   • User provides the PIN code
   • Call POST /oauth/access_token with the PIN as oauth_verifier

Usage

All commands via exec. Script path: scripts/tweet.js (relative to this skill directory).

Single tweet

node scripts/tweet.js "Your tweet content here"

Reply to a tweet

node scripts/tweet.js --reply-to 1234567890 "Reply text"

Quote tweet

node scripts/tweet.js --quote 1234567890 "Your commentary"

Thread (multiple tweets)

node scripts/tweet.js --thread "First tweet" "Second tweet" "Third tweet"

Output

JSON to stdout:

{"ok":true,"id":"123456789","url":"https://x.com/i/status/123456789","remaining":"99","limit":"100"}

On error: {"ok":false,"error":"..."}

Character Limits

• Max 280 weighted characters per tweet
• CJK characters (Chinese/Japanese/Korean) count as 2 each
• URLs count as 23 each regardless of length
• Script auto-validates before posting; rejects if over limit

Rate Limits

• 100 tweets / 15 min per user (OAuth 1.0a)
• 3,000 tweets / month on Basic plan ($200/mo)
• Check remaining field in output to monitor quota

Tips

• For content from Notion/database: fetch the text first, then pipe to tweet.js
• For cron-based auto-posting: use exec with env vars set, parse JSON output to confirm success
• Thread mode posts sequentially; each tweet auto-replies to the previous one
• Combine --thread with --reply-to to attach a thread under an existing tweet