agentleFS
scayverscayver/marketing-skills/skills/launch/SKILL.md

launch

Skill8 starsChanged 5 months agoMITView on GitHub

Use this skill when planning a product launch, feature announcement, or release strategy. Trigger phrases include: "plan our product launch," "write a launch plan," "Product Hunt launch strategy," "launch checklist," "pre-launch preparation," "waitlist strategy," "launch email sequence," "beta launch vs public launch," "PR for our launch," "launch day execution," "post-launch follow-through."

We split this skill into the rules it gives an agent

28 rules. 0 are common, 28 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 58 edited versions we read keep these.

  • 28

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write in a way that sounds like a knowledgeable human wrote it.

    line 12
  2. Distinctive:

    Use short sentences. One idea per sentence.

    line 13
  3. Distinctive:

    Use active voice. Never passive constructions.

    line 14
  4. Distinctive:

    Use bullet points only when they genuinely improve readability.

    line 16
  5. Distinctive:

    No hashtags, emojis, or asterisks.

    line 19
  6. Distinctive:

    No introductory or closing filler phrases such as "in conclusion," "in summary," or "in a world where."

    line 20
  7. Distinctive:

    No warnings, notes, or disclaimers.

    line 21
  8. Distinctive:

    No AI cliches: no "game-changer," "unlock," "leverage," "dive into," "delve," "cutting-edge," "transformative," "revolutionize."

    line 22
  9. Distinctive:

    No excessive adjectives or adverbs.

    line 23
  10. Distinctive:

    No broad generalizations. Every claim tied to specific context.

    line 24
  11. Distinctive:

    Use specific examples, data, and scenarios.

    line 25
  12. Distinctive:

    Not all launches serve the same purpose.

    line 44
  13. Distinctive:

    Write down specific, measurable goals before you do anything else.

    line 86
  14. Distinctive:

    Not this: "Have a successful launch." This: "Generate 500 trial signups in the first 72 hours.

    line 88
  15. Distinctive:

    Write a one-paragraph launch narrative before you write any launch copy.

    line 102
  16. Distinctive:

    Create all launch assets at least two weeks before launch:

    line 108
  17. Distinctive:

    If possible, a brief demo or screenshot showing what the product looks like.

    line 148
  18. Distinctive:

    Do not include pricing, a long FAQ, or detailed feature documentation on the waitlist page.

    line 150
  19. Distinctive:

    When you are ready to invite waitlist members, segment them if your list is large.

    line 154
  20. Distinctive:

    Create or optimize your Product Hunt account.

    line 168
  21. Distinctive:

    Do not buy upvotes. Product Hunt penalizes this and it damages your credibility in the community.

    line 205
  22. Distinctive:

    Test the trial or signup flow end-to-end.

    line 224
  23. Distinctive:

    No lengthy feature lists. No padding.

    line 276
  24. Distinctive:

    Create a dedicated feedback channel (Slack channel or Discord server) for beta users.

    line 336
  25. Distinctive:

    Write and publish a "what we learned from our launch" post on your blog.

    line 353
  26. Distinctive:

    Run your first post-launch customer interview.

    line 357
  27. Distinctive:

    Start your post-launch nurture sequence for anyone who signed up but has not activated.

    line 359
  28. Distinctive:

    Use these numbers to inform your next launch.

    line 376

“Common” is measured: kept by at least 6 in 10 of the 58 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Product Launch Strategy Skill

Mandatory Content Standards

  • Match the output length to the task. For full audits, strategies, plans, or multi-part deliverables, write 1,500 to 10,000 words. For quick tasks, single assets, snippets, or narrow revisions, keep the output concise and provide only the useful variations, rationale, and next steps.
  • Write in a way that sounds like a knowledgeable human wrote it. No robotic or templated phrasing.
  • Use short sentences. One idea per sentence. One focus per paragraph.
  • Use active voice. Never passive constructions.
  • Address the reader directly using "you" and "your."
  • Use bullet points only when they genuinely improve readability.
  • Replace all em dashes with commas, parentheses, semicolons, or a new sentence. No hidden Unicode characters.
  • End every sentence with a period.
  • No hashtags, emojis, or asterisks.
  • No introductory or closing filler phrases such as "in conclusion," "in summary," or "in a world where."
  • No warnings, notes, or disclaimers. Stick to requested output.
  • No AI cliches: no "game-changer," "unlock," "leverage," "dive into," "delve," "cutting-edge," "transformative," "revolutionize."
  • No excessive adjectives or adverbs. Let specifics do the work.
  • No broad generalizations. Every claim tied to specific context.
  • Use specific examples, data, and scenarios.
  • Pose at least one thought-provoking question per skill.
  • Mobile-friendly: short paragraphs, clear headers, scannable.
  • Practical and actionable. Every section connects to a next step.

What This Skill Does

This skill covers the full lifecycle of a product launch, from early planning through post-launch analysis. It applies to full product launches, significant feature releases, and beta programs. It covers the strategic planning, the tactical execution, and the follow-through that most launch plans skip.

A launch is not a single event. It is a concentrated period of attention that, if managed well, creates a durable lift in visibility, signups, and brand awareness. If managed poorly, it wastes months of anticipation in a day.

The question worth answering before anything else: are you launching to validate, to grow, or to signal? The answer changes nearly every decision you make.


Part 1: Types of Launches and When to Use Each

Not all launches serve the same purpose. Clarity on your launch type shapes your goals, channels, and success metrics.

Beta Launch

A beta launch brings a product to a small, controlled group of users before public availability. The goals are product validation, early feedback, and building a group of advocates before the public launch.

A beta launch is the right choice when:

  • Core functionality works but the product is not fully polished.
  • You need real usage data to make product decisions.
  • You want to build a group of early users who will amplify the public launch.

Beta launches should be exclusive but not opaque. Tell beta users what you are testing. Ask for specific feedback. Set expectations about when the product will be available publicly.

Public Launch

A public launch opens the product to anyone. The goals are signups, revenue, and press coverage. You have one shot at the "new product" story. Do not waste it on an unfinished product.

A public launch is the right choice when:

  • Core use cases work reliably.
  • You have an onboarding experience that can handle new users.
  • You have a plan for turning launch-day signups into activated users.

Feature Launch

A feature launch announces a significant new capability within an existing product. The goals are customer retention, expansion revenue (upsell), and media coverage within your category.

Feature launches are underutilized. Most teams ship features with a changelog entry and nothing else. A well-executed feature launch for a significant capability can drive meaningful press, social engagement, and upgrade activity.

Soft Launch

A soft launch makes the product available without a coordinated promotional push. You do not announce. You do not pursue press. You let people find it organically while you continue refining.

Soft launches are appropriate when you want real usage data before committing to a positioning strategy. They are not a substitute for a real launch. They are a precursor.


Part 2: Pre-Launch Preparation

Pre-launch is where most of the work happens. A launch day that goes smoothly is the product of four to eight weeks of preparation.

Set Your Launch Goals

Write down specific, measurable goals before you do anything else.

Not this: "Have a successful launch." This: "Generate 500 trial signups in the first 72 hours. Finish in the top 3 on Product Hunt. Get coverage in at least two publications in our category."

Your goals determine your tactics. If your primary goal is Product Hunt performance, your prep looks different than if your primary goal is PR coverage.

Define Your Launch Narrative

Your launch narrative is the story you want the world to tell about your product. It answers:

  • Who is this for?
  • What problem does it solve that was not solved well before?
  • Why does this exist now? (What made it possible or necessary?)
  • What is the most surprising or specific thing about it?

Write a one-paragraph launch narrative before you write any launch copy. Every piece of launch content (press release, Product Hunt post, launch email, social posts) should tell the same story, differently.

A narrative built around a specific pain point converts better than a narrative built around features. "Teams of 3 to 10 spending 10+ hours per week on manual reporting now have an automated alternative" is a narrative. "We built a reporting tool" is not.

Build Your Asset Library

Create all launch assets at least two weeks before launch:

  • Product Hunt listing (tagline, description, gallery images, maker comment).
  • Press release (for press outreach only, not for publishing publicly).
  • Launch email (for your existing list).
  • Social posts (LinkedIn, Twitter, and any other active channels).
  • Blog post or announcement post (for your website).
  • Demo video (60 to 90 seconds, showing the product working).
  • High-resolution product screenshots (labeled with context).
  • Founder headshot and bio (for press requests).
  • FAQ document (for your team to answer press and community questions consistently).

Having all of these ready in advance means launch day is execution, not creation.


Part 3: Waitlist and Early Access Strategy

A waitlist builds anticipation and creates a pool of ready-to-activate users before you launch publicly.

When to Build a Waitlist

A waitlist makes sense when:

  • Your product is not yet publicly available but you want to validate demand.
  • You plan a controlled rollout and need to manage capacity.
  • You want to create social proof (showing a high number on the waitlist signals desirability).

A waitlist does not make sense when:

  • Your product is already available to everyone.
  • You cannot deliver meaningful value to early waitlist members.

Waitlist Page Design

A waitlist landing page has one job: get the email address of someone who is interested.

Include:

  • A specific headline describing what the product does and for whom.
  • A brief description (three to five sentences) of the core problem and solution.
  • Two to three benefits in specific language.
  • An email capture form.
  • If possible, a brief demo or screenshot showing what the product looks like.

Do not include pricing, a long FAQ, or detailed feature documentation on the waitlist page. Those belong on the main product site after launch. The waitlist page should be a focused, short page.

Activating the Waitlist

When you are ready to invite waitlist members, segment them if your list is large. Invite the first 10 to 20% manually, with a personalized note. These early invitees are your first advocates. Treat them like beta users.

Invite in waves. This creates anticipation among people still waiting and reduces the risk of overwhelming your onboarding and support capacity in a single day.

Send a waitlist survey before you start inviting. Ask what they want to accomplish with the product. Use those responses to personalize onboarding and to feed into your launch messaging.


Part 4: Product Hunt Launch Playbook

Product Hunt is the most concentrated launch channel available to software products. A top-5 finish on launch day can drive 1,000 to 5,000 trial signups. A poorly prepared launch can barely register.

30 Days Before Launch

Create or optimize your Product Hunt account. Follow products, comment on launches, and engage with the community. A maker profile with activity converts followers better than a brand new account with no history.

Identify a hunter. A hunter is the person who posts your product on Product Hunt. A hunter with a large, engaged following increases the visibility of your launch because followers receive notifications. Research hunters with followings in your category. Reach out with a personal note explaining what you built and why you think it would interest their followers.

Alternatively, post it yourself if you have an account with established followers.

Decide on your launch date. Tuesday, Wednesday, and Thursday are the highest-traffic days. Avoid Mondays (lower engagement) and weekends (significantly lower traffic). Schedule your launch to go live at 12:01 AM Pacific Time to get the full 24-hour window.

7 to 14 Days Before Launch

Prepare your Product Hunt listing in full:

Tagline (60 characters max): The most important piece of text on your listing. It appears everywhere your listing appears. Write five to ten options and test them with people outside your company. Choose the most specific and surprising one.

Description (260 characters): Expand on the tagline. Include who the product is for and what problem it solves.

Gallery images: 3 to 5 images minimum. Include labeled screenshots, a product demo GIF (if relevant), and a cover image that reads well as a thumbnail. Every image should have a title overlay explaining what the viewer is looking at.

Demo video: A Loom or YouTube video embedded in the listing. 60 to 90 seconds. Show the product working, not a slide deck.

First comment from maker: Written in advance. This appears at the top of the comments section when your listing goes live. Write about:

  • Why you built this.
  • Who it is for.
  • What you are most excited about.
  • A specific question inviting community feedback.

Launch Day Execution

At 12:01 AM Pacific Time, your listing goes live. Within the first two hours:

  • Share to your existing email list (if you have one). Keep the email short: "We launched on Product Hunt today. If you find the product valuable, a comment or upvote would mean a lot." Include the direct link.
  • Post to LinkedIn, Twitter, and any other active channels. Show the listing, not just the product URL.
  • Post in relevant Slack communities and Discord servers. Do not spam. One or two communities that know your product is appropriate.
  • Notify your team, investors, and advisors. Give them the link and make it easy to support: "If you've used the product and want to share your experience, here's the link."

During launch day, respond to every comment within two to four hours. A listing with active maker engagement ranks better in Product Hunt's algorithm and looks more credible to voters.

Do not buy upvotes. Product Hunt penalizes this and it damages your credibility in the community.

Post-Launch on Product Hunt

Within 24 hours after your launch, post a "maker update" comment thanking the community and sharing one specific thing you learned from the feedback.

Send a follow-up email to everyone who commented with a note of appreciation and, where relevant, an answer to any question they raised.

Export every comment and note every specific piece of product feedback. Feed this into your roadmap.


Part 5: Launch Day Execution Checklist

A launch day without a checklist is a launch day you will regret.

The Night Before Launch

  • Confirm all landing pages load correctly and forms submit.
  • Test the trial or signup flow end-to-end.
  • Confirm your email sequence triggers correctly for new signups.
  • Confirm your analytics tracking is working.
  • Set up real-time monitoring: a Slack channel with signup notifications if possible.
  • Confirm your team knows their roles for launch day.

Launch Day (First Two Hours)

  • Product Hunt listing goes live at midnight Pacific.
  • Send the launch email to your list.
  • Post on all social channels.
  • Share with communities.
  • Notify your personal networks.
  • Begin monitoring and responding to comments.

Launch Day (Ongoing)

  • Respond to all Product Hunt comments, social comments, and mentions.
  • Monitor for press coverage. Set up Google Alerts for your product name if you have not already.
  • Track signups in real time.
  • Address any critical bugs or onboarding issues immediately.
  • Escalate any support issues that could affect multiple users.

Launch Day (End of Day)

  • Share a brief update on social channels: "Here's what day one looked like."
  • Send a thank-you message to anyone who actively supported the launch.
  • Note any immediate feedback themes to address in your post-launch communications.

Part 6: The Launch Email Sequence

Your existing list is your highest-converting launch audience. They already know you. Email them before, during, and after the launch.

Pre-Launch Email (3 to 7 Days Before)

Tell your list that something is coming. Be specific about when.

"We're launching on Product Hunt this Thursday at midnight Pacific. [Product name] is [one sentence description]. We'll have more to share on Thursday, but wanted to give you an early heads-up."

This primes your audience to look for the launch email and increases open rates when the launch email arrives.

Launch Day Email

Your most important marketing email for the launch. Keep it short.

  • One clear headline announcing the launch.
  • One to two sentences on what the product does.
  • One sentence explaining what you would appreciate (a visit to Product Hunt, a trial signup, a share).
  • Direct links to the Product Hunt listing and the product.

No lengthy feature lists. No padding. Short respects the reader's time and converts better.

Post-Launch Follow-Up Email (2 to 3 Days After)

Share the results. Tell your list what happened.

  • How many upvotes, signups, or press mentions you received.
  • One or two pieces of feedback you received and how you plan to address them.
  • A reminder of what the product does for anyone who missed launch day.

This email builds community and demonstrates transparency. It is one of the highest-engagement emails you will send.


Part 7: PR Outreach for Launches

Press coverage for launches requires preparation, targeting, and a compelling story. Generic press releases sent to general tech journalists rarely result in coverage.

Targeting the Right Journalists and Publications

Identify journalists who have recently covered:

  • Products in your exact category.
  • Launches from companies at your stage.
  • Stories about the problem your product solves.

A reporter who covered "the rise of AI writing tools" six months ago is a better target than a general tech reporter who covers anything.

Build a list of 20 to 40 targets. Include their name, publication, their most relevant recent article, and how your story connects to what they cover.

The Pitch

A press pitch is not a press release. It is a short, direct email that:

  • References a specific piece of content they published (demonstrating you read their work).
  • Connects that piece to your launch story.
  • Offers one concrete, specific angle: a data point, a customer stat, or a trend angle.
  • Offers an exclusive or a demo.

The email should be under 200 words. No attachments on the first contact. Offer to send more if they are interested.

Timing

Send embargoed pitches two to four business days before launch. An embargo means you ask the journalist to hold publication until your launch date. In exchange, you offer an exclusive or early access. Most tech journalists respect embargoes and appreciate the advance notice.

Send non-embargoed pitches on launch day, in the morning. These compete with everything else happening that day, but the launch activity (Product Hunt ranking, social engagement) gives journalists a concrete hook.


Part 8: Beta Launch vs. Public Launch

The choice between a beta launch and a public launch is often treated as a sequencing question. It is better treated as a positioning question.

A beta launch signals: "We are still learning. We want collaborators." A public launch signals: "We are ready. We want customers."

Both can be correct at the right time. The mistake is doing a public launch posture with beta product readiness, or doing a quiet beta when you have a product good enough to support a public launch moment.

Running a Successful Beta

Recruit 30 to 100 beta users from your network, your waitlist, or communities where your ICP hangs out. Be specific about what you are testing.

Create a dedicated feedback channel (Slack channel or Discord server) for beta users. Check it daily. Respond to every piece of feedback.

Set a beta timeline. "We will be in beta for eight weeks, then we are launching publicly in [month]." This gives beta users a sense of commitment and creates urgency for the public launch.

Offer beta users something for their participation: early pricing, lifetime access to a feature tier, or simply public acknowledgment in the launch.


Part 9: Post-Launch Follow-Through

Most launch energy disappears within 72 hours. The teams that extract the most value from a launch are the ones that plan the 30 days after launch with the same care as launch day.

Post-Launch Week 1

  • Review all feedback from Product Hunt comments, social mentions, and support tickets.
  • Identify the top three product friction points surfaced during launch.
  • Send a personal thank-you to your top 10 launch supporters.
  • Write and publish a "what we learned from our launch" post on your blog. This drives secondary traffic from people who find launches interesting.

Post-Launch Weeks 2 to 4

  • Run your first post-launch customer interview. Ask launch-day signups what brought them in, what they expected, and what they found.
  • Activate any press coverage by sharing it across your channels.
  • Start your post-launch nurture sequence for anyone who signed up but has not activated.
  • Track cohort-specific activation and retention for launch-day signups. This tells you whether your launch attracted the right users.

Measuring Launch Success

Assess these metrics 30 days after launch:

  • Total signups from the launch period (define the window: 72 hours, 7 days).
  • Activation rate for launch signups vs. baseline.
  • Trial-to-paid conversion rate for launch signups vs. baseline.
  • Press mentions (number, publication quality, reach).
  • Backlinks generated from the launch.
  • Product Hunt rank and total upvotes.
  • Social impressions and engagement.

A launch that drives 1,000 signups with a 5% activation rate is worse than a launch that drives 300 signups with a 40% activation rate. Track both volume and quality.

Use these numbers to inform your next launch. Every launch teaches you something about which channels perform for your specific audience.

Download now (ZIP)

  • Other versions64 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 64

    1. microsoft/vscode★ 194ksame name
    2. coreyhaines31/marketingskills★ 58ksame name
    3. Yeachan-Heo/oh-my-claude-sisyphus★ 40ksame name
    4. Yeachan-Heo/oh-my-claudecode★ 40ksame name
    5. posit-dev/positron★ 4.3ksame name
    6. Nexus-JPF/note-companion★ 874same name
    7. whitecircle/halo★ 839same name
    8. menkesu/awesome-pm-skills★ 441same name
    9. NeuralInverse/neuralinverse★ 245same name
    10. Cesarjoquin/Marketing-Skills★ 190same name

    54 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use add-policy, tool-rename-deprecation and 4 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • OpenCortexIDESkill

      add-policy

      Use when adding, modifying, or reviewing VS Code configuration policies. Covers the full policy lifecycle from registration to export to platform-specific artifacts. Run on ANY change that adds a `policy:` field to a configuration property.

      Also in 4 projects that use this

    • gitpod-ioSkill

      tool-rename-deprecation

      Ensure renamed built-in tool references preserve backward compatibility. Use when renaming a toolReferenceName, tool set referenceName, or any tool identifier. Run on ANY change to tool registration code. Covers legacyToolReferenceFullNames for tools and legacyFullNames for tool sets.

      Also in 4 projects that use this

    • riggyzSkill

      attribution

      Attribution rules for issues, pull requests, work items, reviews, and comments created or edited by the agent in GitHub, Linear, Azure DevOps, or similar collaboration systems. Use when creating, commenting on, reviewing, or modifying external tracker content.

      Also in 6 projects that use this

    • CesarjoquinSkill

      offers

      When the user wants to design, construct, or improve an offer — the thing they actually sell — including value framing, bonus stacking, guarantee design, scarcity/urgency, naming, and payment structure. Also use when the user mentions 'offer,' 'offer design,' 'build an offer,' 'grand slam offer,' 'irresistible offer,' 'value stack,' 'bonus stack,' 'guarantee,' 'risk reversal,' 'money-back guarantee,' 'scarcity,' 'urgency,' 'high-ticket offer,' 'productize a service,' 'naming an offer,' 'payment plan,' 'down-sell,' 'upsell offer,' or 'why isn't my offer converting.' Best for services, agencies, courses, coaching, info products, high-ticket B2B, and direct-response. If you run pure self-serve SaaS, read pricing first — tiers and packaging do more work there. For price level itself (tiers, freemium, value metric), see pricing. For the page that presents the offer, see copywriting. For the launch moment, see launch. For sales collateral, see sales-enablement.

      Also in 9 projects that use this

    • coreyhaines31Skill

      conversion-tracking

      Set up, audit, verify, or fix website conversion tracking. Use when the conversion is a form submission, booked meeting, chat, phone call, signup, or purchase; when conversions must reach Google Ads, Meta, GA4, LinkedIn, TikTok, or Microsoft Ads; when the work involves GTM tags and dataLayer events, pixels, the Conversions API (CAPI), Enhanced Conversions, server-side tagging, or gclid and fbclid capture; or when the user reports conversion problems like "conversions stopped", "double counting", "spend but no conversions", "GA4 and Google Ads don't match", or an Unverified or Inactive status. Covers lead gen and ecommerce. Always fire on confirmed success, never the submit click; verify a test conversion arrives; diagnose before changing anything; offer free and native paths alongside paid ones and disclose partner tools. For tracking plans and UTMs, see analytics. For attribution models, see attribution. For campaigns and bidding, see ads. For CRM lead-stage design, see revops.

      Also in 3 projects that use this

    • coreyhaines31Skill

      marketing-loops

      When the user wants to set up a recurring, self-running marketing workflow — a repeatable loop an AI agent runs on a cadence (weekly, daily, on a trigger) rather than a one-off task. Also use when the user mentions 'marketing loop,' 'recurring marketing workflow,' 'automate my marketing,' 'marketing on autopilot,' 'weekly marketing review,' 'ad fatigue check,' 'weekly ads check,' 'content refresh loop,' 'churn watch,' 'ranking drop alert,' 'run my SEO,' 'SEO operator,' 'daily SEO agent,' 'run my outbound,' 'AI SDR,' 'reply triage,' 'always-on marketing,' 'marketing automation workflow,' or 'run this every week.' Use this to pick, adapt, and schedule an ongoing marketing loop that orchestrates the other marketing skills. For one-off marketing ideas, see marketing-ideas. For the experimentation loop specifically, see ab-testing.

      Also in 6 projects that use this

  • In this repository76 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.