Oss launch posts

OSS Launch Posts

Generate platform-tailored launch posts for the open-source project in the current working directory. Output a single LAUNCH_POSTS.md at the repo root containing title + body for each target community, ready to copy-paste.

The output is always a markdown file. Never auto-post to any platform — posting is share-visible and the user must review first.

Workflow

Six phases. Stop for user confirmation only at the community-list step.

1. Analyze the repo

You're in the project root. Build a digest covering:

• What it does — one sentence, no jargon. Read the README's first paragraph and verify it matches the actual code.
• How it does it — top-level architecture in 2-4 bullets. Skim the entrypoint plus key files. Don't go deep.
• Distinguishing features — what makes this different from existing tools in the same space? (If you can't name one, the post will be weak — call this out to the user.)
• Target audience — who actually uses this? (CLI users, web devs, gamedevs, ML researchers, etc.)
• Project type tags — pick from: cli, terminal, macos-app, browser-extension, web-framework, library, ai-tooling, game, mobile-app, devtool, data-tool, etc. Multiple tags fine.
• Public URL — derive from git remote get-url origin, normalize to https://. Confirm the repo is public; if it's private, stop and tell the user.
• License — read the LICENSE file.
• Stage — fresh launch, post-1.0, mature?
• Recent shipping — git log --oneline -20 to spot anything launch-worthy that just landed.

This digest informs every later step. Skipping or skimping here yields generic posts that will be ignored or downvoted.

2. Discover communities

Start with the always-relevant set (include these for every project):

• Hacker News (Show HN)
• Lobsters
• r/opensource
• Twitter/X — short hook tweet
• Bluesky — same tweet, retargeted at the dev-on-Bluesky audience (some overlap with Mastodon crowd)
• Dev.to — longer-form post that becomes the canonical launch write-up. The short posts on HN/Reddit/social can all link back to it for technical depth, so it pulls weight even if Dev.to isn't where the user normally writes.

Add by project type:

Type	Communities
cli, terminal	r/commandline, r/programming, plus shell-specific (r/zsh, r/bash, r/fish) and platform-specific (r/iterm2 if macOS-only, r/linux if Linux-friendly)
macos-app	r/macapps, r/MacOS
ai-tooling	r/ClaudeAI, r/LocalLLaMA, r/MachineLearning (only if research-grade), Anthropic Discord (#claude-code if relevant)
web-framework	r/webdev, language-specific (r/javascript or r/typescript), r/programming
browser-extension	r/chrome, r/firefox, r/browsers
library	language-specific subreddit (r/Python, r/golang, r/rust, r/elixir, …), r/programming
game	r/gamedev, r/IndieDev, r/IndieGaming
devtool	r/programming, r/devops if infra-flavored, r/SideProject
data-tool	r/dataengineering, r/datascience, r/Python (often)

Then web-search to find any niche fit not in the table. Useful queries:

• "<project keyword>" subreddit
• "<project keyword>" community forum OR discord
• "Show HN" "<adjacent keyword>" — confirms prior art exists in this space and shows you what worked

If a Discord exists for the closest related tool/framework, add it (e.g., Anthropic Discord for Claude Code plugins, Tailwind Discord for Tailwind plugins).

Also consider (don't auto-include — only add if signal warrants):

• LinkedIn — only if the project is professional/B2B. Skip for hobbyist or developer-tool work.
• Mastodon (fosstodon.org / hachyderm.io) — increasingly relevant for OSS launches; add if the user mentions a public Mastodon presence.

Present the candidate list to the user with one line of rationale per community. Wait for confirmation or edits before drafting bodies — they know their audience better than you do, and this is where their judgment matters most.

3. Draft posts (one per platform)

Each platform has its own conventions. Match them — recycled bodies get downvoted or ignored, and worse, get the user flagged as a spammer.

Title craft (applies to every platform)

The title is the only thing 95% of viewers see. A weak title tanks an otherwise good post. Apply these patterns; they consistently outperform "Built a plugin that does X" / "Released vX.Y.Z" titles.

Patterns that earn the click:

• Lead with stakes or pain. "I had 6 Claude Code tabs open and couldn't tell which one was waiting" beats "A zsh plugin for Claude Code". The reader feels the problem before they read past the first comma.
• Concrete numbers when truthful. "Took two evenings", "6 tabs", "saves me ~20 context switches a day". Vague claims ("supercharge your workflow") read as marketing; specific numbers read as honesty.
• Visible result, not internals. "My iTerm2 tabs now turn amber when Claude is waiting" beats "zsh plugin that hooks into Claude Code lifecycle events". The reader can picture the outcome.
• Curiosity gap, not clickbait. "Why my iTerm2 tabs change color based on what Claude Code is doing" creates a question the reader wants resolved. "You won't believe this iTerm2 hack" is clickbait — readers downvote it.
• First-person on Reddit and Dev.to. First-person signals a real builder behind the post. "I built X because Y" beats "Plugin to do X".
• Negative framing works on tool-pain titles. "Stop guessing which Claude Code tab needs you" / "Tired of X? Here's Y". Use sparingly — once or twice across the launch, not in every title.

Anti-patterns to avoid:

• Generic verbs: "Built a plugin that...", "A new zsh plugin for...", "Introducing X". These are the AI-default and read as a press release.
• Hype adjectives in titles: amazing, awesome, revolutionary, must-have, supercharged, ultimate, the best. They flatten claims and trigger marketing-detector reflexes.
• Title-cased every word ("Plugin That Drives ITerm2 Tab Color From Claude Code State"). Use sentence case unless the platform uses title case (rare).
• Restating the project name: "claude-tab-watcher: a plugin that watches claude tabs" — the colon-and-tagline pattern works on Lobsters but feels redundant elsewhere.
• Vague "thoughts on", "lessons from", "deep dive into" — promises content the body usually doesn't deliver.

Platform-specific tone for titles:

• HN / Lobsters — earn the click through concreteness, not editorializing. The audience is hostile to marketing language. "Show HN: Color iTerm2 tabs amber when Claude Code is waiting on you" works because the visible result is specific. Don't use stakes-led titles here unless they're factual ("Show HN: I lost two hours hunting for which Claude tab needed me, so I built this").
• Reddit — stakes-led, first-person, problem-shaped titles win. "Stop guessing which iTerm2 tab Claude is waiting on" / "I had 6 Claude Code tabs open and built this to keep them straight" / "Made my iTerm2 tab flash amber when Claude needs input — never miss a prompt".
• Twitter/X / Bluesky — the hook tweet is the title. Lead with stakes or a result: "I had 6 Claude Code tabs open and couldn't tell which one was waiting on me. Built this." Pulls the reader into the body.
• Discord — no title, but the first sentence is the title. Same patterns apply.
• Dev.to / Medium / blog — clear value prop or how-to framing. "How I made my iTerm2 tabs tell me which Claude Code session is waiting" / "Coloring my terminal tabs based on what an AI assistant is doing".

For each title, run a quick A/B in your head: which would you click on if it scrolled past — your draft, or the generic "Built a plugin for X" version? If they're a wash, your draft isn't sharp enough.

Hacker News (Show HN)

• Title: Show HN: <one-line description>. Include the project name only if it's also the description ("Show HN: Postgres for browsers"). Hard limit 80 chars; aim for ~60.
• Body: 2-4 short paragraphs.
  • Para 1: what it does, plus link if not in URL field.
  • Para 2: why you built it / what problem it solves.
  • Para 3 (optional): something technically interesting. A non-obvious design decision, a constraint that shaped it.
  • Para 4 (optional): what feedback you'd find useful.
• Forbidden: emoji, "Hi HN!", "I'm excited to announce", any marketing language, hype adjectives. Modesty wins on HN.
• The repo URL goes in the URL field. Only put it in the body if the body needs it for context.

Lobsters

• Title: descriptive, not promotional. ~60 chars.
• Tags: pick 1-3 from the project type (e.g., unix, release, programming, practices).
• Body: one short paragraph. Context for why this is on Lobsters specifically — usually some technically interesting angle.
• Tick "authored by submitter" (assume the user is the author).

Reddit (per subreddit)

Each subreddit has its own tone. Read the rules and recent top posts before drafting.

• Common pattern: first-person, problem→solution narrative. "I kept losing track of which terminal tab Claude was running in, so I built a zsh plugin that…"
• Length: 100-300 words. Long enough for context, short enough for mobile readers.
• Link: include the GitHub URL inline.
• Tone tuning by subreddit:
  • Tool-specific (r/iterm2, r/zsh, r/neovim) — focus on user benefit. Less architecture talk.
  • r/programming — more technical depth. Mention notable design decisions or trade-offs.
  • r/opensource — emphasize the OSS angle (license, contribution welcome, why open).
  • r/SideProject — narrative + numbers if you have any (download counts, stars, etc.).
  • Niche communities — read 5+ recent posts and match the register.
• Forbidden: "Hey guys!", "What do you think?" filler, "Hope this is allowed!" Just state the thing and leave room for questions.
• Flair: if the subreddit has flair, suggest a fitting one in the output.

Twitter/X and Bluesky

• 280-char hook tweet, with optional 2-3 tweet thread for technical detail.
• Lead with the user-visible benefit, not implementation. "Color iTerm2 tabs amber when Claude Code is waiting on you" beats "I wrote a zsh plugin that uses OSC 6 escapes…"
• Link in the first or last tweet, not the middle.
• If a demo GIF/image would carry the post, note it as media-suggestion: <description> — you can't generate the image, but flag what would help. A demo GIF is the single biggest conversion factor for terminal/UI tools.

Discord (relevant server)

• Casual. 2-3 sentences. "Hey folks — built [thing] that does [user benefit], [link]. Happy to answer questions."
• No title field; the message is the post.
• Match the channel: more polish in #showcase / #projects, more casual in #general.

Dev.to / Medium / personal blog (longer-form)

• Title: clear, not clickbait.
• Body: ~600-1200 words with subheadings.
• Structure: hook → problem → what you built → how it works → install → what's next.
• This is where technical depth lives. Cross-link from the HN/Reddit posts as a "longer write-up here" pointer.

4. Humanize each body

After drafting each platform's body, invoke the humanizer skill on it via the Skill tool to remove AI tells (em-dash overuse, rule-of-three, inflated symbolism, "delve", "robust", "leverage", etc.).

• Pass each body separately so the humanizer has clean context per platform.
• Don't humanize titles. They're too short for humanizer to improve, and the platform-specific conventions (Show HN: prefix, character limits) shouldn't be touched.
• If the humanizer skill is not installed, do a manual pass: scan for the AI-tell patterns above and rewrite. Note in the output file that the manual pass was used so the user knows to re-read more carefully.

5. Write LAUNCH_POSTS.md

Single file at the repo root (or wherever the user is working — match pwd). Use this exact template, in this order: HN, Lobsters, Reddit (one section per subreddit), social, Discord, long-form. Order matters because users typically post HN/Lobsters first, then subreddits over a few days.

# Launch posts for <project name>

> Generated <YYYY-MM-DD>. Review before posting — tone, claims, links.
> Posting all of these on the same day looks like a spam blast; space
> them out over a week and engage with replies on each one.

## Posting checklist

- [ ] Repo is public and the README has install instructions above the fold
- [ ] A `v0.1.0+` tag and GitHub Release exist
- [ ] Demo image/GIF is in the README (biggest single conversion lift)
- [ ] Logged into each platform with a `>0`-karma account — HN/Reddit
      shadowban brand-new accounts

---

## Hacker News (Show HN)

**URL field:** <repo URL>

**Title (80 char max):**

<title> ```

Body:

<humanized body>

---

Lobsters

URL: <repo URL> Tags: <tag1>, <tag2>

Title:

<title>

Body:

<humanized body>

---

r/<subreddit>

Suggested flair: <flair, or "none">

Title:

<title>

Body:

<humanized body>

---

Twitter/X

Tweet 1 (hook, ≤280 char):

<tweet 1>

Tweet 2 (link + spec):

<tweet 2>

Tweet 3 (optional, technical):

<tweet 3>

---

Bluesky

Post 1 (hook, ≤300 char):

<post 1>

Post 2 (link):

<post 2>

---

Dev.to (long-form)

Tags: <tag1>, <tag2>, <tag3>, <tag4>

Title:

<title>

Body:

<humanized long-form body, ~600-1200 words>

---

Notes

• Communities considered but skipped: <list, one-line reason each>
• Suggested media: <e.g., "5s GIF: tab flipping amber when Claude prompts">
• Suggested posting order: <e.g., "HN Tue 8am ET, Lobsters same day, subreddits Wed-Fri">
• Humanizer pass: <"applied via humanizer skill" or "manual fallback — re-read carefully">

### 6. Hand off

Tell the user the file is written. Suggest:

- Open it, skim, adjust anything that feels off in their voice
- Post one platform at a time and engage with replies — early engagement determines whether posts gain traction
- The humanizer pass tries to remove AI fingerprints, but voice is personal. A 30-second user-edit to make each post sound like *them specifically* beats anything automated.

## Principles

- **Authenticity > reach.** AI-generated posts get sniffed out and downvoted aggressively, especially on HN and Lobsters. The humanizer pass is necessary but not sufficient.
- **Different audience, different post.** A r/programming reader cares about design trade-offs; a r/iterm2 reader cares about whether it solves their problem today. Don't recycle bodies across platforms.
- **Modesty wins.** State the thing, share what's interesting, invite feedback. Don't sell. This is especially true on HN and Lobsters but applies broadly.
- **Confirm the community list, not the bodies.** The user knows their audience better than you do — the community list is where their judgment matters most. After they approve, draft the bodies in one pass and let them edit the final markdown.
- **Never auto-post.** Output is always a file for human review. Posting is share-visible and effectively irreversible.

## Out of scope

- Auto-posting to any platform.
- Generating images, GIFs, or screenshots (suggest what would help, but the user produces the media).
- Account management, scheduling, or analytics.
- Multi-week marketing campaigns. Each post stands alone; the user owns sequencing.