# Launch / announcement

Apply [`core.md`](./core.md) first. This file is the genre overlay for
shipping posts: product launches, rebrands, "we built this" reports.

Pair with [`essays.md`](./essays.md) if the piece is a build report on a
blog, and with [`landing.md`](./landing.md) if it is a marketing page.
This file is the extra tells that cluster on announcement copy.

---

## Open on something specific, not the announcement formula

Skip "I'm excited to announce" and "Today, we're launching." Those are
the most generic openers in the genre.

Open on a specific moment or on the artifact. A first-ship story can
open on the decision that made the project real. A v1.2, a patch, or a
Show HN should open on the artifact. **Hacker News: artifact first,
always.**

If what building taught you is the interesting part, write a build
report (see [`essays.md`](./essays.md)). The product page can carry the
catalog.

---

## Tells to avoid (launch-post specific)

Beyond `core.md` and `audit.md`:

- **"I'm excited to announce" / "Today, we're launching."** Also "we're
  excited to share," "I'm humbled to announce."
- **The feature dump.** Three capabilities a reader can picture, not a
  catalog. Everything else lives on the product page, behind one link.
  A builder-audience overlay may raise the cap.
- **Fake humility.** "It's still early days and we have so much to
  learn" is a tic, not modesty. A closer that asks permission to have
  shipped the link is core's permission-slip offer, not this bullet.
- **Manufactured urgency.** No countdowns, no launch-week pricing
  theater.
- **Stacked CTAs.** One primary outbound link in the body. A second is
  fine (docs, repo). Do not end every section with a button. On HN the
  artifact is the link.
- **Retelling the origin story** when it belongs on another surface.
  One or two sentences of setup, then a link.
- **False-momentum closers.** "This is just the beginning." Say the
  honest status: live, paid, still being hardened, whatever is true.
- **Working-name history and tech stack** unless the audience is
  builders who asked. Spec-sheet memory is not a story.

**What you chose not to build** is often the strongest section. Turning
down an obvious feature is a better story than shipping one, and it is a
claim a competitor cannot copy by rewriting their copy. Do not invent a
"we didn't build X" section so the post has one.

---

## Pronouns

Use "we" when the build was a collaboration. Use "I" for observations
and lessons if the byline is one person. Do not erase the other hands,
and do not pretend a company wrote the scars. Overlay wins if it
already chose.

---

## Channel extras

- **Personal surfaces:** first person "I."
- **Product / company surfaces:** "we" if the overlay says so.
- **Hacker News:** artifact first, story second. Disclose commercial
  status up front. Engage in comments; never post-and-ghost. No upvote
  asks (see [`outreach.md`](./outreach.md)).
- **LinkedIn / Facebook / X:** no feature dumps, no manufactured
  urgency, no "Agree?", no "a thread 🧵", no "I'm humbled."

Run `audit.md` on every piece of publishable copy before it goes out.
Run `claims.md` if the post asserts facts, numbers, or "the industry
does X."

---

## Acceptance criteria (starting set)

1. Opens on a specific moment or on the artifact, not an announcement
   formula. HN: artifact first.
2. Three product capabilities maximum in the body, unless the overlay
   says the audience is builders who asked for more.
3. Honest status in the close; no "just the beginning."
4. One primary outbound link; a second is fine. Don't stack CTAs.
5. No feature table, no working-name history, unless the overlay
   permits it for a builder audience.
6. Read-aloud test: every sentence is one you would say to a peer.