Drafting tweets from sessions

Drafts short, shareable tweets from a Skillsync session or trace that highlight tension, contradiction, or surprising moments. Use when the user asks for tweet ideas, social posts, share-worthy moments, "a fun tweet," "a punchy take," or any framing that names tension / contradiction / surprise / "didn't see that coming" from a specific session or trace.

Overview

Visibility
public
Updated
17h ago
Built from
0 sessions

Install

An Agent Skill is a SKILL.md plus its files, zipped as .skill. Pick an agent — it activates when its description matches your request.

Download drafting-tweets-from-sessions.skilldrafting-tweets-from-sessions/SKILL.md

User-level (~/.claude/skills/)

unzip ~/Downloads/drafting-tweets-from-sessions.skill -d ~/.claude/skills/

Project-level (.claude/skills/, run from repo root)

unzip ~/Downloads/drafting-tweets-from-sessions.skill -d .claude/skills/
SKILL.md

Drafting tweets from sessions

Turn a session into a 1-3 tweet draft that earns attention with tension, not bombast.

What tension means here

Tension is when two true things shouldn't coexist but do. The reader feels the gap and clicks to close it. Patterns that work:

  • Expectation → actual. "I thought the hard part was X. The actual hard part was Y."
  • Effort vs outcome. "Spent 3 hours debugging. The fix was one line."
  • Hero → villain. The library that solved the problem and then became the problem.
  • Ambition → reality. "Wanted to build X. Ended up building Y."
  • Bug → feature (or the reverse). The thing that looked broken was actually working as designed.

If the session has nothing surprising — just smooth progress — say so and stop. Forcing tension where there isn't any reads as fake.

What to read from the session

If the user is viewing the session and it's the active artifact, use the inlined content directly. Don't go searching for it via tools. Same for a trace — the moments and resolution are right there.

What to look for:

  1. First user message — what were they trying to do? That's your "expected."
  2. Pivots — places where the conversation changed direction. Words to look for: "actually," "wait," "but," "turns out," "oh," "never mind."
  3. Errors that got fixed — what was wrong, what did the fix turn out to be? The bigger the gap between the symptom and the fix, the better the tension.
  4. Things the user complained about, then loved (or the reverse).
  5. Last few messages — what did they actually ship? Compare to step 1.

For traces specifically: the gap between question and resolution is often the whole story.

Writing the drafts

Produce 3 alternative drafts by default — three separate single tweets, each using a different pattern from the list above. The user picks one. Do not collapse to a single draft because one tension feels strongest; the point is to give them options.

If the user explicitly asks for a thread (a sequence of tweets that build on each other), then write a 2-3 tweet thread instead of 3 variants. Otherwise: variants, not a thread.

Length: ≤ 280 chars per tweet. Tight is the whole point.

Voice:

  • Specific over abstract: "the migration timed out at 47s" beats "had a slow migration."
  • Past tense, first person — this is the developer's voice.
  • Code, errors, file names, command flags — let the specifics carry the surprise.
  • No emojis, no hashtags, no @mentions.
  • No "fellow devs," "shipping," "vibes," "let's just say."
  • Avoid em-dashes used as suspense beats — they're an overused tell.

Structure for tension:

[setup that sounds normal]. [twist that breaks the setup].

The setup must be plausible enough to make the twist land. The twist must be concrete — name the thing.

Examples

Setup → twist (one tweet):

Spent 3 hours convinced the auth bug was in our middleware. It was in our middleware. Just the wrong middleware.

Effort vs outcome:

Rewrote the migration twice. The fix was setting statement_timeout to a number that wasn't zero.

Hero → villain (two tweets):

Started using Drizzle to escape Prisma's slow startup. Two weeks in: the slow part is our schema, not the ORM.

Lesson: profile before you migrate, or you'll just rebuild the same problem in a different DSL.

Ambition → reality:

Wanted to add real-time multiplayer to the side project. Shipped a "Refresh" button.

Bug → feature:

Spent the morning convinced the rate limiter was double-counting. It wasn't. The duplicate hits were from my own debugging script.

Output (strict)

Output exactly 3 numbered drafts. Nothing else. No headers. No preamble like "Here are some tweets" or "Based on the session". No analysis paragraph before the drafts. No explanation of which pattern each draft uses. No character counts. No emoji. No post-hoc justification.

Format:

1. <first tweet>
2. <second tweet>
3. <third tweet>

If the session genuinely has no tension worth tweeting, output exactly this one sentence and nothing else: "No tension worth tweeting in this session."

Failure modes to avoid:

  • Writing "The tension is..." or "The sharpest tension is..." before the drafts — never explain, just demonstrate
  • Producing 1 or 2 when 3 fit — produce all 3
  • Producing 3 variants of the same setup — each must use a different pattern from the list
  • Adding commentary after the third tweet — stop at 3

When the user wants iteration

If they ask for "more" or "a different angle," pick a different pattern from the list above and try that one. Don't retread the same setup with new words — pick a fundamentally different shape.

If they ask for "shorter" — aim for under 180 chars. If they ask for "longer" — they don't actually want longer, they want a thread; offer 2 tweets, not 1 long one.