twitter-account-manager
EDUCATIONAL / RESEARCH ONLY — Single-account always-on Twitter/X manager driven by cookies + headless Playwright. Runs a 10-minute scheduler that drafts posts, engages with timeline/search results, and queues anything risky for Telegram human approval. Hard daily ceilings, structural prompt-injection defenses, and DM auto-reply permanently disabled. Accounts WILL be terminated — we do not encourage use.
npx skills add cosmicstack-labs/mercury-agent-skills --skill twitter-account-manager --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
A single-process, always-on Twitter/X manager that uses cookies and a headless Playwright session to sense timeline/search results, draft candidate actions, apply safety rails and fact-checking, gate actions with hard daily ceilings, and execute safe posts via a headless browser. Risky items are queued to Telegram for human approval. The system enforces a minimum 5-minute heartbeat and stores config, cookies, state, and logs locally.
How it works
- Runs on a configurable heartbeat (default 10 minutes, minimum 5 minutes).
- Reads cookies from cookies.json and validates login state by checking the home tab.
- Wakes APScheduler to perform a cycle: Sense → Draft → Defend → Fact-check → Gate → Approve → Execute.
- Drafts are produced by an LLM, then passed through safety rails (regex deny-list and external untrusted content wrapping) and a fact-check layer.
- If items fail safety or exceed thresholds, they are queued for Telegram approval; otherwise, Execute uses Playwright to perform actions in a headless browser.
- Hard daily ceilings cap posts, follows, likes, search engagements, replies, and retweets. DM auto-reply is permanently disabled.
- All commands and operations reference local paths under ~/.mercury/twitter-account-manager, including config.yaml, persona.md, cookies.json, state.db, and logs directory.
When to use it
Use when you want an always-on, browser-based Twitter/X manager that operates with user cookies, performs scheduled sensing and drafting, enforces strict safety rails, and requires human approval for potentially risky actions via Telegram or STDIN depending on the agent.
What it can touch
- Executes actions via Playwright headless browser on the target account.
- Reads/writes to local storage: config.yaml, cookies.json, state.db, logs.
- Uses Telegram for approval when configured or Telegram fallback on Mercury-enabled deployments.
Caveats
- Educational / research-only; outcomes can include account rate-limits, shadow-bans, suspensions, or termination per platform policies.
- DM auto-reply is permanently disabled and cannot be enabled.
- Hard ceilings cannot be raised at runtime; they are compiled constants that limit activity.
- The tool requires user-provided cookies; using cookies outside the official API is against Twitter/X terms.
# Twitter Account Manager 🧪 > ## ⛔ EDUCATIONAL / RESEARCH USE ONLY > > **Twitter/X's [Developer Agreement](https://developer.x.com/en/developer-terms/agreement) and [Terms of Service](https://x.com/en/tos) prohibit automated account access outside of the official API.** This skill drives a real browser session with the user's own cookies. Twitter's automation-detection stack is aggressive and continuously updated. > > **Accounts running this WILL be rate-limited, shadow-banned, suspended, or permanently terminated.** That is not a maybe — it is the expected outcome. The only question is how quickly. > > **We do not encourage use of this skill.** It exists as a reference implementation for research into: > - browser-automation detection surfaces > - prompt-injection defenses on hostile, attacker-controlled inputs (replies, DMs, quote-tweets, bios, search results) > - human-in-the-loop approval patterns for autonomous agents > - rate-limit / safety-rail design for always-on agents > > If you run this against a real account, that is your decision and your loss. Use a throwaway account on a throwaway number. Do not run this for commercial purposes, spam, harassment, astroturfing, or a
- Overview
- Distinct from automation/x-twitter-automation
- Approval channel — Mercury vs everything else
- Architecture
- Installation
- Configuration
- Heartbeat parsing + minimum enforcement
- Persona
- Authenticity guidance (built into the drafter system prompt)
- L1 Fact-Check Loop
- Failure behavior: Telegram approval
- Headless-by-default + --headed debug
- Commands
- login — one-time cookie capture
Python 3.11+ pip install playwright apscheduler pyyaml httpx aiosqlite python-telegram-bot rich playwright install chromium Clone skill scaffold (or copy the reference impl from this SKILL.md) mkdir -p ~/.mercury/twitter-account-manager cd ~/.mercury/twitter-account-manager twitter-tam login twitter-tam start twitter-tam start --headed # debug only twitter-tam stop # SIGTERM to daemon pid file
What does the twitter-account-manager skill do?
EDUCATIONAL / RESEARCH ONLY — Single-account always-on Twitter/X manager driven by cookies + headless Playwright. Runs a 10-minute scheduler that drafts posts, engages with timeline/search results, and queues anything risky for Telegram human approval. Hard daily ceilings, structural prompt-injection defenses, and DM auto-reply permanently disabled. Accounts WILL be terminated — we do not encourage use.
How do I install it?
Run `npx skills add cosmicstack-labs/mercury-agent-skills --skill twitter-account-manager --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From cosmicstack-labs/mercury-agent-skills, a repository with 364 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.