twitter-thread-style

Files (1)

• SKILL.md

SKILL.md (first lines)

# Twitter Thread Style

Use this skill to write developer-facing X/Twitter threads in the user's voice.

This is a generic style skill. Do not bake in one project's facts. Read the current task context, source material, or user notes first, then apply the style rules below.

## Goal

Write a technical announcement thread that works in the timeline.

The reader should be able to understand the project from the first tweet, but the code snippets/screenshots should be what make them stop scrolling.

The thread should feel like a developer showing a real tool, not a company writing a launch page.

## Voice

Prefer:

- plain technical statements
- concrete reasons the thing exists
- direct comparison to a known tool/category when it helps
- understated confidence
- real tradeoffs
- specific capabilities
- attractive code snippets

Avoid:

- slogan speak
- marketing copy
- generic hype
- vague architecture-first explanations
- buzzwords like “unlock”, “seamless”, “delightful”, “empower”, “revolutionary”
- claims that sound bigger than the evidence
- explaining internals before explaining why the reader should care

Bad tone:

```text
This unlocks a delightful new developer experience for modern teams.
```

Better tone:

```text
I wanted the same workflow, but without leaving the stack I already use.
```

## Strict Tweet Shape

Each tweet must follow this shape:

1. A short chunk of text.
2. Then one or more code blocks.

Do not inline code in prose. No backticked identifiers inside the paragraph.

Bad:

```text
Run `my_tool dev` and edit `pages/index.md`.
```

Good:

```text
The dev server is one command.
```

```bash
my_tool dev
```

A tweet can contain multiple code blocks. Use this to increase density.

## First Tweet

The first tweet must be optimized for the timeline.

It should quickly answer:

- what was released
- what familiar category/tool it relates to
- what makes it different
- what the code feels like

The first sentence should be short and direct.

Good patterns:

```text
I published PROJECT.
```

```text
PROJECT is public.
```

```text
FAMILY has a new member: PROJECT.
```

Then use a familiar anchor if possible:

```text
It is like KNOWN_TOOL, but for STACK.
```

```text
I wanted KNOWN_WORKFLOW, but with DIFFERENT_CONSTRAINT.
```

The hook should usually be capability-first, not positioning-first. Lead with what became possible, what shipped, what changed, or what the thing is in familiar terms.

Then show the best code snippet immediately.

## Code Is the Hook

Prioritize snippets that look good as screenshots.

From dannote/dot-pi, MIT.

More from dannote/dot-pi