write-tweet

> **${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: 1. Trim whitespace. Take the **first token** (everything up to the first space **or** the first `:`), lowercased. 2. 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. 3. 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: 1. **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`. 2. **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**. 3. **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). 4. **Re-save.** Overwrite `memory/drafts/write-tweet-latest.md` with the revised draft, so a further `revise:` refines the newest version. 5. **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>`.) 6. **Re-offer** a further revision (the operator is actively iterating, so this is expected, not a nag — skip the daily dedup guard here): ```bash ./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" ``` 7. **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: 1. A take from today's article (already researched and opinionated) 2. A surprising connection between two of today's findings 3. 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): ```bash 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: 1. `soul/SOUL.md` — identity, worldview, opinions 2. `soul/STYLE.md` — writing style, sentence structure, anti-patterns 3. `soul/examples/tweets.md` — rhythm and tone calibration. Match this exactly. 4. `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.