Product Launch Announcement Writer

Turn product evidence into a coherent message system, then adapt it to each channel without changing the underlying facts. This skill owns messaging and copy; use launch-guide for readiness, assets, scheduling, operations, and analytics.

Operating Rules

• Inspect the conversation, repository, README, homepage, docs, pricing, changelog, screenshots, and existing copy before asking questions.
• Ask only for facts that cannot be inferred and that materially affect the copy.
• Create a claim ledger before drafting. Every number, comparison, customer quote, logo, superlative, security statement, and availability claim needs a source or must be removed/qualified.
• Never invent users, revenue, testimonials, rankings, urgency, scarcity, integrations, performance, or roadmap commitments.
• Do not copy competitor phrasing or customer quotes without permission and accurate attribution.
• Verify current platform fields, character limits, link rules, and promotional policies on the execution date.
• Use one primary action per asset. “Try, share, buy, star, comment, and book a call” is not one CTA.

Inputs and Defaults

Infer, then establish:

• product name and canonical URL;
• launch type: first release, beta, major version, feature, open source, or relaunch;
• audience, user, and buyer;
• painful current workflow and trigger;
• core outcome and differentiated mechanism;
• two or three supporting capabilities;
• proof, limitations, pricing, and availability;
• selected channels and primary CTA;
• founder voice and prohibited claims.

When proof is limited, use a concrete product demonstration and honest scope rather than inflated adjectives.

Workflow

1. Build the Source Brief

Extract facts into:

Field	Evidence
Audience and problem	User research, docs, or positioning
Outcome	What the product demonstrably enables
Mechanism	How it produces the outcome
Differentiator	Specific contrast with current alternatives
Proof	Metrics, demo, examples, or permissioned quote
Boundaries	Beta status, missing features, supported platforms
Offer	Price, trial, promo, or open-source license
Action	Exact next step and destination

Resolve conflicts between README, website, pricing, and app behavior before publishing.

2. Create the Claim Ledger

Label claims:

• Verified: supported by a current source;
• Qualified: directionally true but needs careful wording;
• Unsupported: remove or research;
• Prohibited: legal, platform, confidentiality, or brand restriction.

For quantitative claims record the baseline, time period, sample, method, and source. “10× faster” without a reproducible comparison is not a usable claim.

3. Choose the Message Spine

Write one sentence for each:

1. Audience: who immediately recognizes the problem?
2. Problem: what frustrating or costly situation occurs?
3. Outcome: what becomes easier, faster, safer, or possible?
4. Mechanism: how does the product create that outcome?
5. Difference: why use this instead of the current approach?
6. Proof: what makes the claim believable?
7. Action: what should the reader do now?

Then produce three angles—usually problem-led, outcome-led, and founder/story-led—and recommend one per channel.

4. Draft the Core Copy Deck

Create:

• positioning statement;
• one-sentence description;
• tagline variants;
• short, medium, and long descriptions;
• benefit-led feature bullets;
• founder/maker story;
• proof block;
• honest limitations/eligibility note;
• CTA variants;
• FAQ/objection answers.

Prioritize specificity over hype. Describe the user’s changed workflow, not a pile of features.

5. Adapt to the Channel

Do not merely truncate the same paragraph.

Product Hunt

Provide tagline, short description, maker/first comment, feature bullets, and discussion prompts. Verify the live form. Current official guidance describes a 260-character description, personal maker accounts, and authentic discussion; never ask directly for upvotes or coordinate manipulation.

GitHub Release

Lead with user-visible changes. Include compatibility, installation/update steps, migration or breaking changes, fixes, known issues, contributors, and links. Keep marketing claims secondary to operational clarity.

Hacker News / Reddit / Indie Hackers

Write a self-contained, candid post that explains what was built, why, what is unusual, and what feedback is useful. Disclose affiliation and follow each community’s current rules.

LinkedIn / X / Threads

Create native posts, not hashtag stuffing. The first unit must stand alone; threads should add evidence, examples, or story rather than restating the hook. Use social thread templates as structure only.

Email

Use one clear subject, preview text, audience-specific opening, core value, proof/demo, one CTA, and truthful conditions. Include required sender identification and unsubscribe mechanics through the sending system.

Use platform templates for complete scaffolds.

6. Review as a Skeptical Reader

Check:

• Can the target user explain the product after one pass?
• Does the opening communicate value before backstory?
• Is every feature connected to an outcome?
• Are comparisons fair and substantiated?
• Are beta status, pricing, eligibility, and limitations clear?
• Does each channel sound native?
• Is the CTA singular and measurable?
• Could any line be mistaken for a fabricated endorsement or guarantee?

Output Contract

Return:

1. source brief and unresolved fact conflicts;
2. claim ledger;
3. recommended message spine and alternatives;
4. core copy deck;
5. channel-native final drafts;
6. three to five headline/tagline variants;
7. visual/copy pairing notes;
8. pre-publish fact and platform checklist.

Sources

• How to Post a Product | Product Hunt Help Center
• Product Hunt Launch Guide
• Managing Releases in a Repository | GitHub Docs
• Hacker News Guidelines
• Reddit Content Policy
• FTC Advertising and Marketing Basics