| name | product-launch-announcement-writer |
| description | Create fact-checked launch messaging and channel-native copy for Product Hunt, GitHub releases, Hacker News, Indie Hackers, Reddit, LinkedIn, X, Threads, blogs, and email. Use whenever the user needs a tagline, launch post, first comment, release notes, social thread, email, message map, headline variants, or launch copy adapted from a repository or website. |
| category | business |
| license | MIT |
| compatibility | Live web access is required to verify current platform limits and rules when copy must fit a specific submission form. |
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:
- Audience: who immediately recognizes the problem?
- Problem: what frustrating or costly situation occurs?
- Outcome: what becomes easier, faster, safer, or possible?
- Mechanism: how does the product create that outcome?
- Difference: why use this instead of the current approach?
- Proof: what makes the claim believable?
- 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:
- source brief and unresolved fact conflicts;
- claim ledger;
- recommended message spine and alternatives;
- core copy deck;
- channel-native final drafts;
- three to five headline/tagline variants;
- visual/copy pairing notes;
- pre-publish fact and platform checklist.
Sources
