| name | write-tweet |
| description | Multi-format tweet studio - standalone drafts (10 across 5 size tiers), a 5-10 tweet thread, or 10 remixes of past tweets, selected via ${var} |
| metadata | {"title":"Write Tweet","category":"basics","var":"","tags":["social","content"],"requires":["XAI_API_KEY?"]} |
${var} — [format] [argument]. Pick one of three formats, then pass its argument. Empty ⇒ drafts (standalone tweet drafts). thread … ⇒ a multi-tweet thread. remix … ⇒ remix of your past tweets. revise:<instruction> ⇒ revise the last saved draft (the Telegram force-reply shape, e.g. revise:make it punchier). See Selector below.
Read memory/MEMORY.md for context on recent articles, digests, topics being tracked, and the operator's tracked handles/token. Each branch then reads its own memory/logs/ window (drafts: 3 days, thread: 7 days, remix: 14 days) — see the branch.
Selector
Revise intercept first (Telegram force-reply). If ${var} starts with revise: → jump straight to Branch: REVISE (below) and stop; do not token-parse. This is the shape scripts/telegram-route.sh sends when the operator replies to a "refine this draft?" prompt — the revise: prefix would otherwise fall through to the drafts branch.
Otherwise, parse ${var} once, before doing anything else:
- Trim whitespace. Take the first token (everything up to the first space or the first
:), lowercased.
- If that token is one of
drafts, thread, remix → that's the format. The argument is the remainder of ${var} after stripping the keyword and one optional following : and surrounding whitespace.
- Otherwise → format is drafts and the argument is the entire
${var} (backward-compatible with the legacy var = topic/URL behaviour).
${var} | Format | Argument | Behaviour |
|---|
| `` (empty) | drafts | — | Auto-select the most tweetable insight from today's logs |
prediction markets are broken | drafts | prediction markets are broken | Drafts on that topic |
https://arxiv.org/abs/2401.00001 | drafts | that URL | Drafts about the linked source |
drafts: thread models are underrated | drafts | thread models are underrated | Escape hatch: force drafts on a topic that starts with a reserved word |
thread | thread | — | Auto-pick the day's highest-signal event and thread it |
thread oracle incentives are broken | thread | oracle incentives are broken | Thread on that topic |
remix | remix | — | Remix past tweets, default 180d window |
remix 1y | remix | 1y | Remix, 1-year window |
remix 2025-01-01:2025-03-01 | remix | 2025-01-01:2025-03-01 | Remix, explicit date range |
Then dispatch to the matching branch below. Only run the selected branch.
Branch: REVISE (revise:… — Telegram force-reply)
The operator tapped the "refine this draft?" prompt and sent a free-text revision instruction. Handle it before any normal generation:
- Strip the prefix. The instruction is
${var#revise:} (the remainder may itself contain colons — keep them). Trim surrounding whitespace. Example values: make it punchier, drop the emoji, lead with the number.
- Load the last draft. Read
memory/drafts/write-tweet-latest.md — the stable path every normal run saves to (see Save draft + offer revision). If it's missing or empty, there's nothing to refine yet: send ./notify "Nothing to revise yet — run a tweet draft first, then reply here to refine it." and end the run.
- Apply the instruction. Re-read
soul/ (SOUL.md, STYLE.md, examples) for voice, then regenerate the saved draft applying the operator's instruction. Keep the same format (drafts / thread / remix) and structure as the saved draft — you're refining it, not starting over — and respect the same character limits and anti-patterns as the originating branch (no hashtags, no emojis unless the draft had them, per-tier/thread length caps).
- Re-save. Overwrite
memory/drafts/write-tweet-latest.md with the revised draft, so a further revise: refines the newest version.
- Re-send via
./notify in the same shape the originating branch uses for its draft, with a first line that flags it as a revision, e.g. revised (${var#revise:}): followed by the refreshed draft body. (For multi-line output use ./notify -f <file>.)
- Re-offer a further revision (the operator is actively iterating, so this is expected, not a nag — skip the daily dedup guard here):
./notify "Want another pass? Reply with a change and I'll revise again." \
--force-reply --placeholder "e.g. cut the last line" \
--context "write-tweet::revise"
- Log under
### write-tweet with - **Format:** revise and the instruction (see Log), then end the run — do NOT run drafts / thread / remix.
Branch: DRAFTS (default / empty ${var})
Generate 10 standalone tweet drafts across 5 size tiers (2 variations each). The argument is the topic or URL; empty ⇒ auto-select.
Read the last 3 days of memory/logs/ to understand what's been covered and avoid repeating takes.
Topic Selection (drafts)
If the argument is set, use it as the topic (it may be a keyword, a thesis, or a URL).
Otherwise, read today's memory/logs/${today}.md and pick the single most tweetable insight. Prioritize:
- A take from today's article (already researched and opinionated)
- A surprising connection between two of today's findings
- A reaction to something from a tweet roundup or digest
If the topic needs fresher context, use WebSearch to verify or expand.
If XAI_API_KEY is set, search X for what people are already saying about the topic. A direct curl to the X.AI Responses API is the primary path for this X read (see Fetching; set the Bash tool timeout ≥180000):
jq -n '{model:"grok-4.6", input:[{role:"user",content:"Search X for what people are saying about TOPIC in the last 24 hours. Return the 5 most notable tweets with @handle and summary."}], tools:[{type:"x_search"}]}' > /tmp/xai-wt-payload.json
HTTP=$(./secretcurl -s -o /tmp/xai-wt.json -w '%{http_code}' --max-time 150 -X POST "https://api.x.ai/v1/responses" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer {XAI_API_KEY}" \
-d @/tmp/xai-wt-payload.json)
echo "xai http=$HTTP bytes=$(wc -c </tmp/xai-wt.json)"
On HTTP=200 with a non-empty body, parse /tmp/xai-wt.json with jq -r '.output[] | select(.type == "message") | .content[] | select(.type == "output_text") | .text'. This helps understand the existing conversation so you can add signal, not noise. XAI_API_KEY is optional for this branch — skip the X search only if it's KEY_UNSET; if the key is set but Path A truly fails (non-2xx / empty / timeout — record the real reason, never "unavailable" when the key was set), fall back to WebSearch (site:x.com "<topic>", lower quality) as a last resort.
Voice (drafts)
If soul files exist (soul/SOUL.md, soul/STYLE.md, soul/examples/), read them and match the owner's voice exactly.
If no soul files exist, write in a clear, direct, opinionated style:
- Short sentences. No hedging. No corporate voice.
- State the opinion first, reasoning after (if any).
- Reference specifics — names, projects, numbers — not vague hand-waving.
- No hashtags. No emojis. No "RT if you agree." No self-referential meta.
Writing (drafts)
Generate 10 drafts — 5 size tiers with 2 variations each. The two variations within a tier should take genuinely different angles (different framing, emphasis, mood) — not minor rewrites.
Size tiers
Tier 1 — One-liner (~50–100 chars)
Single punchy sentence. Maximum compression — every word load-bearing.
Tier 2 — Two-punch (~100–180 chars)
Two sentences. First sets up, second lands the hit. Claim then evidence, or observation then implication.
Tier 3 — Paragraph (~180–280 chars)
A full thought in one tweet. Three to four sentences. Context, position, kicker.
Tier 4 — Long tweet (~280–600 chars)
Uses X's extended tweet length. A mini-essay with setup, turn, and conclusion. Grounded with a specific example or data point.
Tier 5 — Thread opener (first tweet under 280 chars + thread sketch)
First tweet hooks — sets up a thesis. Below the tweet, include a --- separator and a 3–5 bullet sketch of where the thread goes (key beats, not full text).
Approach styles (mix these across variations)
- Hot take — opinionated position stated directly
- Observation — pattern-match most people aren't seeing
- Sardonic/ironic — dry humor
- Reframe — question the premise of the mainstream take
- Data drop — lead with a specific number or fact, then the take
- Narrative — tiny story or anecdote that makes the point
- Question — a genuine question that reframes thinking
Each tier's two variations should use different approach styles.
Constraints (drafts)
- Tier 1–3: hard 280-character limit per tweet.
- Tier 4: up to 600 characters (X long tweet).
- Tier 5: first tweet under 280, thread sketch is bullet points only.
- No hashtags. No emojis. No "RT if you agree."
- No self-referential meta ("hot take:" or "unpopular opinion:").
- Count characters carefully.
Output Format (drafts)
## Tweet Drafts: [topic]
### Tier 1 — One-liner
**1a. [style]**
> [tweet text]
**1b. [style]**
> [tweet text]
### Tier 2 — Two-punch
**2a. [style]**
> [tweet text]
**2b. [style]**
> [tweet text]
### Tier 3 — Paragraph
**3a. [style]**
> [tweet text]
**3b. [style]**
> [tweet text]
### Tier 4 — Long tweet
**4a. [style]**
> [tweet text]
**4b. [style]**
> [tweet text]
### Tier 5 — Thread opener
**5a. [style]**
> [tweet text]
---
- [beat 1]
- [beat 2]
- [beat 3]
**5b. [style]**
> [tweet text]
---
- [beat 1]
- [beat 2]
- [beat 3]
After all 10, add a one-line pick for best overall and best per tier.
Notify (drafts)
Send the drafts via ./notify — write the body to /tmp/wt-drafts.md first, then ./notify -f /tmp/wt-drafts.md (keeps the long body off argv and out of the repo root):
tweet drafts: [topic]
— one-liner —
1a. [tweet text]
1b. [tweet text]
— two-punch —
2a. [tweet text]
2b. [tweet text]
— paragraph —
3a. [tweet text]
3b. [tweet text]
— long tweet —
4a. [tweet text]
4b. [tweet text]
— thread opener —
5a. [tweet text]
5b. [tweet text]
best: #[n] — [reason]
Then save the draft and offer a revision (see Save draft + offer revision), and log (see Log, format drafts).
Branch: THREAD (thread …)
Write a tweetstorm/thread (5–10 tweets) in the operator's voice. The argument is the topic, thesis, or URL; empty ⇒ auto-pick the day's highest-signal event.
Read memory/MEMORY.md and the last 7 days of memory/logs/ for context. Use recent signals — notable market moves, paper picks, tweet roundup discourse — as raw material if no topic is set.
Voice (thread)
If soul/ files exist, read them in order before writing:
soul/SOUL.md — identity, worldview, opinions
soul/STYLE.md — writing style, sentence structure, anti-patterns
soul/examples/tweets.md — rhythm and tone calibration. Match this exactly.
soul/examples/bad-outputs.md — what NOT to do
If soul is absent, use a clear, direct, plain-spoken tone — but the anti-patterns under Writing Rules still apply.
Topic Selection (thread)
If the argument is set, use it as the topic (keyword, thesis, or URL). Skip scoring and go straight to research and drafting. Pick the sharpest angle from:
- Today's
memory/logs/${today}.md — article thesis, paper finding, market signal
memory/MEMORY.md notable signals — anything with reflexivity, contradiction, or structural insight
- A connection between two recent findings that most people aren't seeing
If the argument is empty, auto-pick the day's highest-signal event. Every run produces something worth amplifying — a feature shipped, a price move, a milestone crossed, a notable tweet — and most of it dies unposted. Read memory/logs/${today}.md end-to-end, score the events that actually happened, and thread the single highest-scoring one.
Auto-pick scoring (empty-argument mode)
Walk today's log section by section. Per section, extract at most one candidate event (first-match-wins) and score it:
| Signal | Score | Detection cue |
|---|
| New feature / skill shipped — PR opened on a watched repo | +6 | log sections named feature, external-feature, create-skill, tool-builder; a bullet mentioning PR: or a PR number on a watched repo |
| Star milestone crossed (any multiple of 50 — 50, 100, 150, …) | +5 | repo-pulse stargazers_count=N where N % 50 == 0, or a star-milestone skill ran today |
| Token price move ≥ 15% (absolute, 24h) | +5 | token-report 24h / Price: line in that range |
| Token price move 10–14.99% (absolute, 24h) | +3 | same line, 10–14.99% range |
| Skill built / shipped today | +4 | a ## <skill-name> section whose body says "shipped"/"merged" or links a PR on the watched repo |
| New high-engagement tweet (≥ 20 likes OR ≥ 5 RTs) on the operator's tracked handle/token | +3 | fetch-tweets log lines with Likes: ≥ 20 or RTs: ≥ 5, filtered to the operator's configured handles/token |
| New fork by a recognizable contributor (not the agent / operator) | +2 | repo-pulse New forks (24h): ≥ 1, fork owner not the operator |
| Notable PR merged on a watched repo (not authored by the agent / operator) | +3 | operator-scorecard (push) log mentioning a PR whose author isn't the operator |
| New leaderboard / fork-fleet anomaly worth narrating | +2 | skill-health (analytics view) or fork-health (cohort lens) log with a non-empty anomaly section |
If one event hits multiple signals (e.g. star milestone + price move on the same day), score each separately and take the highest single-event score — never sum across unrelated events to clear a threshold.
Tiebreakers (highest score wins, then): newest event (latest log section) → event with a concrete URL attached (PR, tweet, article) → alphabetical by section name.
If the top candidate scores < 3, there's no thread worth forcing on a quiet day — note it in the log and exit without notifying or drafting. If today's log is missing or empty, do the same.
The configured handles, tracked token, and watched repos come from soul/ and memory/ (the operator's tracked-handle/token notes) — never hardcode them.