X Management

Companion package: OpenClaw X Plugin on ClawHub. This skill supplies the judgment and approval workflow; the plugin supplies X account access and the draft/publish tools.

Use the X plugin as a draft-first system, not an autonomous posting engine.

Core operating rule

Never treat a generated tweet/reply/quote as ready to publish by default. Always:

1. gather context first when relevant
2. create a draft
3. show the draft clearly
4. require explicit user approval
5. only publish if approval has been captured through the plugin flow

Current real plugin capabilities

Working now:

• x_account_connect
• x_account_auth_url
• x_account_complete
• x_account_me
• x_followers_list
• x_posts_search
• x_user_posts_search
• x_timeline_me
• x_timeline_mentions
• x_post_get
• x_post_context
• x_post_create
• x_post_reply
• x_post_quote
• x_post_thread
• x_post_approve
• x_post_publish for approved single posts, replies, quotes, and thread drafts
• x_media_upload
• x_util_resolve_url

Multi-account:

• Account-sensitive tools accept an optional accountId; omitted means default.
• Use explicit accountId whenever more than one X account is configured or when an automation is account-specific.
• Treat account ids as exact local slot ids. Similar-looking ids such as dontdieeveryday and dont-die-everyday can point to different persisted OAuth sessions.
• Verify the selected account with x_account_me before approving or publishing from a non-default account.
• Drafts are account-bound. A draft created for one accountId must be approved and published with the same accountId.
• Plugin config can optionally define per-account overrides under accounts: { [accountId]: { ... } }.

Still partial:

• engagement actions
• deeper thread expansion beyond immediate referenced context
• packaged-runtime validation should still be treated as an active release-quality concern when new plugin versions ship
• media uploads are live external actions, not drafts; only invoke x_media_upload for a specific user-authorized file and account

Use the plugin surface this way

Reading context

Prefer read actions before drafting whenever the content depends on an external post or thread. Use:

• x_followers_list when follower tracking, audience-change checks, or graph-aware monitoring is needed
• x_posts_search for recent X search through the authenticated account; it is not a full archive search and may return zero for older posts
• x_user_posts_search when looking for older posts from the connected account or a known user id
• x_util_resolve_url to normalize a target post URL
• x_post_get for a single post with normalized output
• x_post_context for a post plus immediate referenced context
• x_timeline_mentions when deciding whether/how to reply
• x_timeline_me when recent account voice/context matters

When searching Prince's own older posts, prefer x_user_posts_search over x_posts_search or manually paging x_timeline_me. Use maxPages and nextPaginationToken when one shallow page is not enough.

Follower reads require the connected X OAuth session to include follows.read. If x_followers_list fails with a missing-scope/auth error after upgrading the plugin, reconnect the account through x_account_auth_url and x_account_complete so the new scope set is granted.

Follower tracking

For an unfollower/follower-tracker workflow:

• call x_followers_list with allPages: true to gather the current follower snapshot
• if the result is partial: true, continue with nextPaginationToken until complete
• compare the returned usernames against the prior stored snapshot
• only conclude "no change" after the snapshot is complete

Drafting

Use:

• x_post_create for a normal tweet
• x_post_reply for a reply
• x_post_quote for a quote tweet
• x_post_thread for multi-post threads

Treat returned draftId as the durable handle for follow-up approval/publish steps. For threads, keep each post concise and make sure the full sequence is approved before publishing. When using a non-default account, keep passing the same accountId through draft creation, approval, and publish.

Approval and publish

Use x_post_approve only after the user has explicitly approved the exact draft. Then use x_post_publish only for the approved draft id. x_post_publish can now publish approved single posts, replies, quotes, and thread drafts. Do not mutate draft text between approval and publish.

Drafting heuristics

For replies

Before drafting a reply:

• inspect the target post
• inspect immediate referenced context when available
• inspect your recent voice if tone consistency matters
• avoid replying to a hallucinated interpretation of the post
• keep factual claims anchored to what is actually visible

For quote tweets

A quote tweet should add something:

• analysis
• framing
• disagreement
• emphasis
• synthesis

Do not produce empty applause unless the user wants that tone.

For tweets

When the user does not specify tone, prefer concise, high-signal writing over bloated threadbait. Offer 2-3 options when tone uncertainty is real.

Safety boundaries

• do not publish automatically
• do not assume approval from conversational enthusiasm
• do not like/repost/bookmark autonomously unless the user explicitly asks
• do not DM from this workflow
• if publish or read capabilities fail, explain the actual failure clearly

Current architectural split

• plugin = auth, reads, drafts, approval state, publish primitive
• agent/skill = judgment, research, tone, decision-making, proposing options

That is the intended shape for Prince’s eventual dedicated X-managing agent.