/show-hn-writer

name: show-hn-writer
description: 'Draft a Show HN post backed by real HN performance data. Uses observed patterns from 250 top HN posts to maximise score.'
compatibility: [claude-code, gemini-cli, github-copilot]
author: Varnan / Paras Madan
version: 2.0.0
data-source: 250 top HN posts scraped April 18 2026

Show HN Writer — Data-Backed Edition

This skill drafts HN posts using patterns extracted from 250 real top-ranking posts. Every rule below comes from observed data, not convention.

---

What the data says (internalize this before writing anything)

These are the findings from 250 top HN posts scraped April 18 2026. They override any received wisdom about HN writing.

**Title length is the single strongest predictor of score.**

• Under 40 chars: avg 248 pts (n=82)
• 40–59 chars: avg 192 pts (n=68)
• 60–79 chars: avg 150 pts (n=91)
• 80+ chars: avg 131 pts (n=9)

Default target: under 40 characters. Hard ceiling: 60.

**Body text does not affect score.** 90% of posts had no body. With-body avg: 189. Without-body avg: 193. Statistically identical. A body is only worth writing if you have genuinely interesting technical detail that won't fit in a title. Never write a body to pad credibility.

**Show HN prefix suppresses score.** Show HN posts averaged 94 pts vs 186+ for plain statements. The label signals "I want feedback on my thing" which triggers a more skeptical read. Only use "Show HN:" when the project is genuinely novel. Always offer a plain-title alternative.

**First-person titles outperform anonymous statements.** First-person ("I…", "My…", "We…"): avg 291 pts (n=9). Plain statement: avg 186 pts (n=126). If the builder's perspective is part of the story, lead with it.

**Questions generate comments more than upvotes.** Question titles avg ratio of comments-to-score above 1.0×. Best for discussions, not for raw score. Ask the user which they're optimising for before writing.

**Themes that consistently outperform:**

• Security / backdoor / breach stories: avg 308 pts
• Privacy / surveillance / data stories: avg 282 pts
• AI / LLM releases: avg 266 pts (42 posts — largest category)
• Open source releases: avg 485 pts (small n, but strong signal)

**The highest-scoring titles share one trait: they are stories, not topics.** "Someone bought 30 WordPress plugins and planted a backdoor in all of them" — 1192 pts. "Google broke its promise to me – now ICE has my data" — 1688 pts. A topic is "WordPress plugin security". A story has an actor, an action, and stakes.

---

Step 1: Ask the user one question before anything else

Before drafting, ask:

"Two quick questions: 1. Are you optimising for **score** (reach) or **comments** (discussion)? 2. What does the project do — one sentence, technical, no adjectives?"

Do not proceed until you have both answers.

---

Step 2: Determine the right post type

Based on the project and goal, decide which format to use:

**Plain title (recommended default)** No prefix. Just what it is or what happened. Highest avg score. Use when: sharing a release, article, tool, or event.

**Show HN: prefix (use sparingly)** Use only when: the project is a working demo, the builder is present to answer questions, and the technical implementation is the interesting part. Avg score is low (94), but it signals authenticity when the project is genuinely novel. Always also draft a plain-title alternative for comparison.

**Ask HN: prefix** Use when: the goal is discussion, not promotion. Avg engagement ratio > 1.0×. Best for "who is using X?" or "should I do Y?" posts.

**Tell HN: prefix** Whistleblowing, accountability, or disclosure. One data point at 819 pts. Only use if the post is factual, verifiable, and the builder is named.

---

Step 3: Draft the title

**The title is the entire post.** Treat the body as optional.

Rules derived from data:

• Target under 40 characters. Every 20 chars over that costs roughly 30 avg points.
• Write a story, not a category. Actor + action + stakes beats noun phrases.
• First person ("I…") adds ~100 pts avg vs plain statement when builder perspective matters.
• No marketing adjectives. Not "fast", "simple", "powerful", "lightweight" unless

it is a literal spec (e.g. "35B-A3B" is a spec, "powerful" is not).

• Specificity beats generality. "30 WordPress plugins" beats "popular CMS plugins".
• Year in brackets signals classic worth reading: (2008), (1956). Use when linking

older content that has aged well.

• En dash (–) for subtitle format: "Product Name – what it does". Not a hyphen (-).

Draft three variants: 1. Shortest possible (aim for under 35 chars) — strip everything non-essential 2. Story angle — actor + action + stakes 3. Technical angle — lead with the interesting engineering decision

Then apply the length test: count chars on each. Flag any over 60.

---

Step 4: Decide whether to write a body

Ask yourself: does the technical implementation have a detail that cannot fit in the title and that HN engineers would find genuinely interesting?

If yes: write a body (see Step 5). If no: stop at the title. No body is better than a padded body.

The data shows bodies do not increase score. The only reason to write one is if the implementation is interesting enough that engineers will ask "how does this work?" and you want to pre-answer that.

---

Step 5: Write the body (only if Step 4 said yes)

Structure — keep it tight:

**Line 1:** One sentence. What you built and why. First person. Not "Introducing X." Not "X is a tool that." Just: "I built X because Y."

**Lines 2–4:** The real reason. Honest. Specific. Was it a problem you hit yourself? Something frustrating at work? A curiosity? "I was annoyed that..." is better than "Developers often struggle with...". The builder's voice is the point.

**Lines 5–8:** How it actually works. This is what HN reads for. Name the specific technology choices. State the tradeoffs you made and why. One interesting engineering decision is worth more