dev-announce
dev-announce
Generate developer tool feature announcement tweets that are understated, proof-driven, and technically credible. Inspired by the style used in Bun's feature announcements.
Workflow
Copy this checklist and check off each step:
- [ ] Step 1: Understand the feature (read code/PR/commits if available)
- [ ] Step 2: Classify the feature type
- [ ] Step 3: Gather input details
- [ ] Step 4: Draft main tweet
- [ ] Step 5: Draft thread replies (optional)
- [ ] Step 6: Suggest visual proof
- [ ] Step 7: Verify against anti-patterns
Step 1: Understand the Feature
Before writing anything, build a real understanding of the feature. If the user provides a PR, commit, branch, issue, or file path:
- Read the relevant code changes, PR description, or commit messages
- Understand what the feature actually does at a technical level
- Identify the key insight, what makes this interesting or useful
- Look for benchmark data, test results, or before/after comparisons in the codebase
If the user only provides a brief description, ask clarifying questions to fill gaps in understanding. A good tweet requires genuinely understanding the feature. Surface-level descriptions produce surface-level tweets.
Step 2: Classify the Feature Type
Determine which category the feature falls into:
| Type | Signal |
|---|---|
| New API | New function, class, or module being introduced |
| Performance | Speed, memory, or size improvement with measurable data |
| CLI feature | New command, flag, or workflow |
| Compatibility | Standards support, new format, ecosystem integration |
| Bundled feature | Multiple things combined into one simple experience |
Step 3: Gather Input Details
Ask the user for (if not already provided):
- Product name (e.g., "Rolldown")
- Feature description, what it does
- Numbers/benchmarks if performance-related
- Contributors to credit (optional)
- Upstream projects to credit (optional)
- Known limitations or future plans (optional)
Step 4: Draft the Main Tweet
Opening: Always use "In the next version of [Product]"
Body (pick the format matching the feature type):
| Feature type | Body format |
|---|---|
| New API | Function signature in backticks + one-sentence plain-English description |
| Performance | Short description of what area improved + the key number. Details go in replies |
| CLI feature | "You can:" + 2-3 escalating CLI examples in backticks |
| Compatibility | Simple statement: "[Product] gets [X] support" |
| Bundled feature | Description + punchy tagline ("One file, zero dependencies.") |
Rules:
- Plain English, minimal jargon
- If there is a number, include it -- "2x faster", "reduce objects by 10%"
- For performance tweets, explain what improved in terms any web dev would understand. Avoid implementation details like type names, data structures, or internal APIs.
- Use "up to X%" instead of ranges like "3-9%". Lead with the peak number.
- Don't mention dependency version bumps. Frame improvements as your own work.
- Keep it scannable. Use short paragraphs (1-2 sentences) with line breaks between them. A dense block of text is unreadable in tweet form. Put the key number or punchline on its own line.
- For performance tweets, lead with the number/result in the main tweet. Move detailed explanation of what changed into an optional reply.
- Keep under 280 characters when possible (exclude image placeholders)
- End with either a punchy tagline, inline benchmark, or note that an image is attached
Step 5: Draft Thread Replies (Optional)
Thread replies are optional. Only add a reply if it provides genuinely useful context that doesn't fit in the main tweet. A standalone tweet is often better than a forced thread.
If adding replies, each should provide a different useful angle. Pick what fits:
- Practical impact or use cases
- Context on how it works or why it matters
- Proof (benchmarks, test results, before/after data)
- Credit to contributors or upstream projects
- Roadmap tease or scoping ("This was unrelated to X")
Replies can be longer and more conversational than the main tweet. They're where you explain the "why" and "how" in a natural, human tone. Don't compress them into robotic bullet points.
Rules for replies:
- Each reply should stand on its own, a reader might see it without the main tweet
- 3 replies max, never more
- Credit contributors with @mentions, credit upstream projects by name
Step 6: Suggest Visual Proof
For each tweet/reply that would benefit from an image, add a bracketed suggestion:
| Scenario | Suggested visual |
|---|---|
| New API | Polished code screenshot with syntax highlighting and comments explaining usage |
| Performance claim | Benchmark table or terminal output with before/after/delta |
| Feature works | Terminal showing command + output |
| Test rigor | Wall of green checkmarks (pass/fail count) |
| Comparison | A/B bar charts (red=old, green=new) |
| CLI feature | Video demo or cheat sheet with usage variations |
Principle: the image should be self-contained proof. Someone seeing only the image should understand the claim.
Step 7: Verify Against Anti-Patterns
Check the draft against these, if any match, revise:
- No "we're excited to announce..." preamble
- No "check out our blog post for more", the tweet IS the content
- No vague claims without data, every performance claim has numbers
- No superlatives ("blazingly fast", "revolutionary"), the numbers speak
- No engagement bait ("what do you think?", "RT if you agree")
- No thread longer than 3 replies
- No overselling, use understated language ("very slightly faster", "a little")
- Numbers are specific and reproducible (test scenario described, hardware noted if relevant)
- No em dashes. Use commas, periods, or conjunctions instead.
- No "no X, no Y, just Z" constructions (e.g., "No config changes, no API changes. Just faster.")
- Don't start sentences with bare past participles ("Optimized...", "Reduced...", "Improved..."). Use "We optimized..." or rephrase.
- No awkward specificity ("all 8 benchmarks"). Use natural phrasing ("across our benchmarks").
- Don't mention internal dependency names/versions. Frame as your own work.
- Be genuine. If the draft reads like an ad or press release, rewrite it.
- No walls of text. Use short paragraphs (1-2 sentences) with line breaks. Put the key number on its own line.
Voice Guide
-> See voice-guide for tone rules and examples
Examples
-> See examples for 13 full tweet threads to reference
Output Format
Present the final output as:
**Main tweet:**
[tweet text]
**Visual:** [describe what image/video to create, be specific about content, layout, and what to highlight]
Replies are optional. Only include them if they add genuinely useful context. If including replies, add them after the main tweet:
---
**Reply 1:**
[reply text]
**Visual:** [describe what image/video to create, or "None" if text-only reply]
Visual Description Rules
Every visual suggestion must be actionable. Describe it so the user can go create it:
- What to capture: terminal output, code in editor, benchmark run, etc.
- What to highlight: which numbers to emphasize, what to annotate (red underlines, "winner" labels, Before/After labels)
- Layout: single screenshot, side-by-side comparison, table format, etc.
- Style: plain terminal screenshot vs polished code screenshot (gradient background, syntax highlighting)
- Format: image (screenshot) vs video (for interactive/workflow demos)
Example visual descriptions:
- "Screenshot of terminal running
rolldown buildshowing output. Highlight the bundle size and time in the output." - "Side-by-side polished code screenshot: left shows the config input, right shows the optimized output. Use gradient background with syntax highlighting."
- "Before/after benchmark table comparing Rolldown vs esbuild vs webpack. Columns: Bundler, Time, Bundle Size. Bold the Rolldown row."
- "Short video demo: run
rolldown --watch, edit a file, show the rebuild time in terminal."