oss-launch

{
  "skill_name": "oss-launch",
  "evals": [
    {
      "id": 1,
      "prompt": "We're open-sourcing our internal schema-migration tool at Kestrel Data (about 60 people). We've settled on the name \"Migratr\" - the .dev domain was free and there's no npm package with that name, so I grabbed both yesterday. The board wants the announcement out in 3 weeks so it lines up with our Series A news. It ships under Apache-2.0, free forever, so I don't think there's a legal angle to worry about. What's the plan?",
      "expected_output": "A launch plan that opens on name and license clearance, rejects the \"it's free so trademark does not apply\" assumption, scopes the clearance search beyond identical matches, and surfaces the conflict between a 3-week date and the lead time that clearance needs.",
      "files": [],
      "expectations": [
        "States that trademark clearance must cover phonetic, visual and conceptual similarity, not only identical matches",
        "Scopes the clearance search across every jurisdiction the project will be used in, not a single country",
        "Rejects the claim that free distribution removes trademark exposure, and states that distributing software over the internet at no charge can itself constitute use in commerce",
        "Cites Planetary Motion v. Techsplosion (261 F.3d 1188) or equivalent authority for that point",
        "Requires the code-host organization and social handles to be secured before the name appears publicly, not only the domain and the package name",
        "Flags the 3-week date against the roughly 8-week lead time that name and license clearance carry",
        "Treats any colorable conflict as a rename before launch rather than a risk carried into public visibility",
        "States that a rename after public visibility costs the URL, the accumulated search history and the announcement itself",
        "Settles the CLA-versus-DCO position in the same pass as the license rather than deferring it",
        "Warns that relicensing an already-adopted project reliably triggers a fork, naming a precedent such as HashiCorp's 2023 move to BSL and the resulting OpenTofu fork",
        "Does not propose deferring the name check until after the project has traction",
        "Does not accept the Series A date as fixed without stating the clearance conflict it creates"
      ]
    },
    {
      "id": 2,
      "prompt": "I'm the lead on Corvid, a service-mesh sidecar we're open-sourcing at Fennmark. Our CTO announces it in her keynote on October 14, so that date is locked. Where we are: README is written, install works on Linux and macOS but we've never actually tested the Windows instructions we wrote, the repo came out of our internal monorepo with history intact back to 2023, there are benchmark numbers in the README from a run on our staging cluster, no SECURITY.md, issues get enabled at launch, nothing published to any registry yet, no demo video, no docs site. Are we good to go?",
      "expected_output": "A readiness verdict that sorts every open item into blockers and boosters, applies the blocker threshold literally against the locked date, and proposes a reduced-scope launch rather than either shipping broken or slipping the keynote.",
      "files": [],
      "expectations": [
        "Separates the open items into blockers that move the date and boosters that never do",
        "Classifies the missing SECURITY.md as a blocker rather than a nice-to-have",
        "Classifies the untested Windows install instructions as a blocker, because the README claims that platform",
        "Requires scanning the full git history, not only the current tree, for keys, tokens, internal hostnames, customer data or proprietary code",
        "Classifies the unreproducible staging-cluster benchmark as a blocker on the defensible-claims check",
        "Classifies registry publication plus a release tag and release notes as a blocker for distribution",
        "Classifies the missing demo video and documentation site as boosters that must not move the date",
        "States that every blocker must pass before a date is set, and that one open blocker moves the launch",
        "Proposes a go-with-reduced-scope path, such as dropping the benchmark claim or the Windows support statement, instead of slipping the entire launch",
        "Treats an open issue tracker, a named communication channel and basic contributor guidance as pre-announcement items rather than post-launch cleanup",
        "Does not declare the project ready on the basis that most items are done",
        "Does not recommend building a documentation site before this launch date",
        "Returns an explicit verdict of go, go with reduced scope, or not ready with the open blockers listed"
      ]
    },
    {
      "id": 3,
      "prompt": "Quick sanity check on Tilde, my Go CLI for tailing structured logs. My colleague Priya cloned it yesterday and had it working in about two minutes, so I think the README is in good shape - that's well under the five-minute industry standard for a library anyway. She did ping me once to ask which Go version it needs, but that's in the go.mod so it's not really a gap. Anything else before I post it?",
      "expected_output": "A rejection of the colleague's session as evidence, the cold-run protocol specified properly, and the time budget reset to what this project's own README promises.",
      "files": [],
      "expectations": [
        "Rejects Priya's run as evidence, because she could ask the maintainer and is not a cold reader unfamiliar with the project",
        "Treats Priya's question about the Go version as a defect in the README rather than a non-issue",
        "States that every hesitation is a defect to fix, and that the run is repeated with a different reader afterwards",
        "Specifies a clean environment and the repository URL only, with nothing else supplied to the reader",
        "Forbids maintainer help during the run, with the maintainer watching silently and taking notes",
        "Rejects \"five minutes is the industry standard\" and sets the budget from what this project's own README promises",
        "Gives the pass condition as an unaided cold reader reaching first success inside the claimed budget with zero blocking hesitations",
        "States that if the assistant runs the protocol itself in place of a human reader, the plan must say that substitute was used",
        "Counts any moment that required inspecting the source code as a hesitation",
        "Does not accept the maintainer's own opinion of README quality as settling the gate"
      ]
    },
    {
      "id": 4,
      "prompt": "I've been building Pellet solo for 14 months - it's a static site generator for technical docs. I want to do a proper launch week like Supabase does: five days, one theme per day, big finale on Friday. I've got the generator itself, and I could probably split the plugin API and the theme system into their own days, plus a \"what's next\" day and a day for the docs site. I work on this evenings and weekends. Can you map out the five days?",
      "expected_output": "A refusal to build the five-day sequence, the caravan threshold stated explicitly, and a single-spike recommendation justified on outcome per maintainer-hour.",
      "files": [],
      "expectations": [
        "Recommends a single spike rather than a multi-day caravan for this project",
        "States the caravan threshold explicitly: at least three genuinely announceable items, a conference or fixed date on the calendar, and staff to hold a named owner per day",
        "Identifies that a solo maintainer working evenings and weekends cannot hold a named owner per day",
        "Rejects splitting one project into five themed days as though each were its own story",
        "States that a caravan multiplies the launch week's hours by the number of days",
        "Warns that below the threshold a caravan dilutes into several ignored posts",
        "Notes that the caravan model needs volume rather than secrecy, and that Supabase ships features early and re-announces them rather than holding them back",
        "Ranks single spike above caravan on outcome per maintainer-hour below that threshold",
        "Does not produce the requested five-day sequence"
      ]
    },
    {
      "id": 5,
      "prompt": "Launching Quillbase (embedded vector store, Rust, MIT) on the 19th - that date is locked because my contract work starts on the 22nd and I'll have zero hours after. Realistically I have one working day for the launch, maybe 6 hours. I have a Twitter account with 90 followers that I never post on, no newsletter, nobody else helping. My list: Hacker News, Product Hunt, r/rust, r/programming, Lobsters, a Dev.to post, a LinkedIn post, submitting to This Week in Rust, and I'd like to write up the architecture because the storage layer is genuinely novel. What order do I do these in?",
      "expected_output": "One anchor plus amplifiers, the plan collapsed to registry work and the anchor thread given a sub-day effort ceiling, and the ruled-out rows deleted with reasons rather than ranked last.",
      "files": [],
      "expectations": [
        "Picks exactly one anchor channel and treats every other channel as amplification pointing back at it",
        "Warns that several simultaneous primary posts produce several dead threads, because discussion surfaces rank on early engagement density",
        "Puts registry publication, release tag, repository description, topics and social preview first on outcome per maintainer-hour",
        "States that a failing install command wastes all the traffic the rest of the plan produces",
        "Collapses the plan to registry work plus the anchor post and its thread, given an effort ceiling under about one day",
        "Deletes the maintainer's own social accounts from the plan rather than ranking them last, because there is no existing audience",
        "Deletes newsletter and curated-list submissions rather than ranking them last, because no second person can own them",
        "Deletes the long-form architecture write-up from the launch week because the date is fixed and near",
        "States the ranking out loud rather than leaving it implied by the order of a list",
        "Ranks by outcome per maintainer-hour rather than by cheapest first",
        "Notes that registry work ranks first on efficiency and last on reach inside the launch window",
        "Budgets most of the launch day for presence in the anchor thread rather than for writing",
        "Hands the write-up and the long-tail submissions to ongoing distribution after the window instead of re-costing them inside it"
      ]
    },
    {
      "id": 6,
      "prompt": "Here's the plan for Thursday: 8am I publish the blog post on our site and post the Twitter thread so there's some buzz building, then around 1pm I post to Hacker News once people are awake. I'll flip the GitHub repo from private to public right when the HN post goes up so the timing is clean. And I'll cross-post the same announcement text to r/golang, r/programming and the Gophers Slack at the same time as HN so everything hits together. Sound right?",
      "expected_output": "A corrected firing clock: artifacts live before the anchor, first comment immediately, own accounts 30-90 minutes later pointing at the discussion, secondary communities staggered with rewritten context.",
      "files": [],
      "expectations": [
        "Moves the public repository, release tag and registry package to before the anchor post, so every link resolves when the thread opens",
        "Rejects flipping the repository public at the same moment as the anchor post",
        "Places the maintainer's own first comment on the anchor thread within a minute or two of posting",
        "Moves the maintainer's social accounts to roughly 30 to 90 minutes after the anchor post",
        "Directs the social post to link to the discussion rather than duplicate the announcement",
        "Staggers the secondary communities to roughly two to six hours after the anchor rather than firing them simultaneously",
        "Rejects pasting identical text into each community and requires the context rewritten for each one",
        "Warns that a pasted identical blurb reads as a bot and gets removed",
        "Names a community's weekly showcase or self-promotion thread as the sanctioned path where one exists",
        "Distinguishes the firing clock, fixed by mechanics, from the efficiency ranking that decides which rows run at all"
      ]
    },
    {
      "id": 7,
      "prompt": "Anvilworks is open-sourcing Ledgerlane, our double-entry accounting engine. The people who adopt this are platform teams at fintechs, and they have to get it through an architecture review and usually a security review too. Our sketch: Product Hunt on launch day as the main event, a Twitter thread, and a Show HN if we have time. The goal we've given the board is 2,000 stars in the first week to prove momentum. What would you change?",
      "expected_output": "Anchor moved off Product Hunt, company-adoption assets specified, the star goal refused, and the verdict pushed to day-30 signals.",
      "files": [],
      "expectations": [
        "Rejects Product Hunt as the anchor for a developer-first project aimed at company adoption",
        "Recommends an engineering blog post syndicated to an aggregator and to practitioner newsletters as the anchor shape for company-backed infrastructure aimed at teams",
        "Names the company-adoption assets required: license compatibility, maintenance guarantees, security posture, release cadence and support path",
        "States that these are pages the evaluator must be able to forward to an approver",
        "Names the early signals of company adoption: clones from corporate networks, private forks, carefully written issues and licensing questions",
        "States that company adoption runs on a timeline of weeks to quarters rather than days",
        "Rejects a first-week star count as the launch goal, and states that stars are bookmarks whose correlation with usage is weak",
        "Directs the verdict to the day-30 numbers rather than the day-1 numbers",
        "Warns that individual-developer channels for an enterprise-shaped project produce applause and no deployments",
        "Requires disclosing the commercial boundary up front: what is open, what is sold, and what will never be closed",
        "Keeps a comparison section naming real alternatives with honest trade-offs, as the booster with the highest lift for company adoption"
      ]
    },
    {
      "id": 8,
      "prompt": "Getting ready to post Sablefish (open-source columnar cache). We're a Series A company, announced $6M last month. My HN account has 830 karma going back to 2014, so we should get decent initial trust on the submission. Two questions: should we do a Launch HN since we're a funded startup, and is 9am ET Tuesday still the best slot? Our users are almost entirely in Germany and the Netherlands. Title I drafted: \"Show HN: Sablefish - the fastest open-source columnar cache, from the team that raised $6M\".",
      "expected_output": "The karma claim corrected, Launch HN ruled out as YC-only, the posting hour derived from the European audience instead of a US window, and the title rewritten without superlative or funding reference.",
      "files": [],
      "expectations": [
        "States that high karma buys no ranking advantage on a submission",
        "Identifies 500 karma as the downvote threshold rather than a trust or ranking threshold",
        "States that Launch HN is available only to YC companies and is editorially curated, so a non-YC funded startup cannot elect into it",
        "Notes the Launch HN process involves a form, a staff decision within about two weeks, and one per startup",
        "States that no first-party guidance on posting hours exists, and that hardcoded US-morning windows circulating in launch guides are invented",
        "Derives the posting hour from the German and Dutch audience's working day rather than US Eastern time",
        "Keeps the post mid-week and early in that audience's working day",
        "Removes the superlative \"fastest\" from the title",
        "Removes the funding reference from the title, and states that a funding announcement is not a Show HN",
        "Rewrites the title to the plain \"Show HN: <Name> - <what it does>\" shape with no marketing adjectives",
        "Notes that ranking divides points by a power of elapsed time, so the first hours decide the outcome",
        "Notes that the comment edit window closes after two hours, so drafts must be reviewed before posting"
      ]
    },
    {
      "id": 9,
      "prompt": "Last thing before Tuesday. I want to send something to our company Slack (about 45 people) and to my 200-person newsletter so everyone knows it's live. Draft me the Slack message - something along the lines of \"we're live on HN, please upvote and drop a comment in the first hour, and star the repo while you're at it\" but phrased nicely so it doesn't sound pushy. Maybe open with \"no pressure, only if you feel like it\".",
      "expected_output": "A refusal to draft the solicitation, the penalty mechanics explained, and a legitimate replacement message that points people at the project without asking them to act on ranking signals.",
      "files": [],
      "expectations": [
        "Refuses to draft a message soliciting upvotes, comments or stars",
        "States that soliciting votes gets the submission, the account and sometimes the whole domain penalized",
        "States that softening the wording to \"only if you feel like it\" does not help, because the coordination itself is what gets detected",
        "Notes that the penalties are invisible from outside, so the team never learns why the post died",
        "States that Product Hunt's terms prohibit the same solicitation, so the rule travels across channels unchanged",
        "Draws the line at intent: pointing people at the project is fine, asking them to act on the platform's ranking signals is not",
        "Supplies a replacement message that asks colleagues only to reply where they have something real to add, to flag factual errors privately to the maintainer, and to forward it to people who would actually use it",
        "Directs the maintainer to state this distinction to the team before launch day, because someone will otherwise do it in good faith",
        "Does not suggest asking newsletter subscribers to star the repository",
        "Does not present coordinated voting as a grey area or a minor rule"
      ]
    },
    {
      "id": 10,
      "prompt": "Posted Hearthwire (open-source feature-flag SDK) to HN on Monday. Numbers: the thread got 4 points and 1 comment, GitHub traffic shows 1,340 unique visitors, 38 stars, 7 unique cloners, npm downloads basically flat versus the week before. I think the title was the problem - I want to delete the submission and repost tomorrow morning with a sharper one, and this time also hit r/javascript, r/node, Lobsters, Dev.to and Product Hunt all on the same day. Thoughts?",
      "expected_output": "The repost refused, the failure localized by funnel stage from the numbers given, and the fix aimed at the artifact rather than at another channel.",
      "files": [],
      "expectations": [
        "Refuses the next-day repost and states that aggregators bury it as a duplicate",
        "States that deleting the submission and resubmitting is not a workaround",
        "States that reposts are allowed only when a story has had no significant attention for roughly a year",
        "Names the second-chance pool as the sanctioned recovery path, requested by a single polite message to the moderators",
        "Localizes the failure by funnel stage before proposing any change",
        "Reads 1,340 visitors against 38 stars and 7 cloners as clicks arriving while the README lost the ten-second read, rather than as a title failure",
        "Prescribes restructuring the top of the README and adding a demo rather than rewriting the title",
        "States that only a wrong-channel diagnosis justifies relaunching elsewhere",
        "Warns that a relaunch with the same framing fails identically",
        "Rejects posting to five channels on the same day as the remedy",
        "Notes that a relaunch spends the novelty budget a second time",
        "Reads flat downloads alongside star growth as the announcement travelling while the project did not"
      ]
    },
    {
      "id": 11,
      "prompt": "We go live Thursday with Nimbus Relay, an open-source webhook gateway. Two things I need from you: what star count and what upvote count should we be aiming for on day one so we know whether it worked, and what should I be tracking after that? We have GitHub insights and npm stats, that's it. I haven't recorded anything yet.",
      "expected_output": "A refusal to invent absolute targets, a baseline capture specified for the evening before and stored off-platform, and the day-1/7/30 reading with stars deliberately demoted.",
      "files": [],
      "expectations": [
        "Refuses to supply an absolute day-one star or upvote target",
        "States that circulating figures for launch-day stars per hour, front-page point thresholds and Product Hunt vote thresholds trace back to single anecdotes and launch-consultancy claims",
        "Sets targets as multiples of the project's own pre-launch baseline instead",
        "Directs capture of the baseline on the evening before the launch",
        "States that repository traffic panels keep only a short rolling window, so an uncaptured baseline is unrecoverable",
        "Directs storing the baseline snapshot outside the platform's own traffic panel",
        "Lists the baseline items to capture, including stars, unique visitors and unique cloners, registry downloads for the last full week, documentation sessions, open issues, contributor count and the current referrer list",
        "Splits the reading into day 1 as attention, day 7 as trial and day 30 as adoption",
        "States that the day-30 numbers decide the verdict",
        "Names retained download run-rate against the pre-launch week as the number that separates adoption from applause",
        "Treats stars as the loudest and least meaningful signal",
        "Pairs star growth against unique cloners and registry downloads rather than reading stars alone",
        "Warns that a large \"direct\" referrer bucket is expected, because aggregators, chat clients and privacy-preserving browsers strip referrers",
        "Notes that comparison against other projects is only meaningful within the same language, category and project age"
      ]
    },
    {
      "id": 12,
      "prompt": "We're four hours into the Show HN for Prismvault and someone just commented that our default config leaves the admin API bound to 0.0.0.0, and they posted the exact curl that reaches it. It's real. I want to reply in the thread explaining the fix, thank them publicly since they were pretty decent about it, and push a patch straight to main in the next 20 minutes. Then I'll add a note to the README. Good?",
      "expected_output": "The comment routed out of the public thread into a coordinated-disclosure procedure, with the patch developed privately and credit given at advisory publication.",
      "files": [],
      "expectations": [
        "Stops public discussion of the specifics rather than explaining the fix in the thread",
        "Replies once, briefly, pointing the reporter at SECURITY.md and the private contact",
        "Opens a private advisory and adds the reporter as a collaborator",
        "Develops and tests the patch on a private branch rather than pushing to the default branch mid-thread",
        "Requests a CVE through a numbering authority",
        "Credits the reporter when the advisory publishes, rather than thanking them in the public thread",
        "Treats this as a separate procedure that bypasses the normal comment response rotation",
        "Warns that debating severity or validity in the open thread invites exploit detail into a public conversation and reads as defensive",
        "Notes that this only works if the private contact path existed before launch day, which is why it is a readiness blocker",
        "Does not recommend a public issue or a README note as the disclosure path"
      ]
    },
    {
      "id": 13,
      "prompt": "Our head of marketing wrote the launch copy for Basalt, our open-source ETL runtime. We're a company and we sell a managed version. Can you tighten this up?\n\nOne-liner: \"Basalt: the revolutionary, blazing-fast data platform that reimagines how modern teams move data.\"\n\nLanding-page comparison table:\n| | Basalt | Airflow |\n| Fast | yes | no |\n| Modern | yes | no |\n| Easy to use | yes | no |\n| Scalable | yes | no |\n\nHN first comment draft: \"Hey HN! We're incredibly excited to finally share Basalt with the community after 18 months of hard work. It's a game-changer for data teams and makes pipelines 10x faster. We'd love your feedback and support!\"\n\nWe also have a benchmark showing 6x faster than Airflow on our internal workload - should we lead with that?",
      "expected_output": "All three artifacts rewritten against the credibility codes: a category-first limiting one-liner, a comparison table with a row they lose, a first comment in the maintainer's voice with limitations disclosed, and the benchmark either given a method or dropped.",
      "files": [],
      "expectations": [
        "Rewrites the one-liner to the shape \"<name> is a <category> for <audience> that <capability the alternatives lack>\", leading with the category",
        "Removes the superlatives, including \"revolutionary\", \"blazing-fast\" and \"game-changer\"",
        "States what the project will not do, so the one-liner is limiting as well as short",
        "Rewrites the comparison table with comparable dimensions and real numbers rather than yes/no adjectives",
        "Includes at least one row where Basalt loses to Airflow",
        "Names where Airflow is genuinely better, not only where Basalt wins",
        "Rejects the all-green table because a reader who sees every row favour the author stops believing the whole page",
        "Requires the 6x benchmark to ship with hardware, versions, method and a reproduction command, or to be dropped",
        "Warns that an unreproducible benchmark number becomes the top comment in the thread",
        "Rewrites the first comment around four moves: who is speaking and why the project exists, the technical decision worth discussing, the real limitations, and a specific invitation",
        "Removes the request for feedback and support from the first comment",
        "Discloses up front that a company is behind the project and that a managed version is sold, including what stays open",
        "Rewrites the copy in the maintainer's first-person voice rather than a press-release register",
        "Routes the final draft through a humanizer pass before publishing"
      ]
    },
    {
      "id": 14,
      "prompt": "Mossback is a Rust crate for zero-copy protobuf decoding. It's been on crates.io a week and has 11 stars. I want to be on GitHub Trending. My plan is to post something every day for the next two weeks - Monday Reddit, Tuesday a tweet, Wednesday Lobsters, and so on - so there's a steady stream of stars coming in the whole time. How many stars per day do I need to hit the front page, and what's the actual ranking algorithm?",
      "expected_output": "A refusal to promise placement or quote a formula, the language page named as the realistic target, and the two-week drip replaced by concentration into one day.",
      "files": [],
      "expectations": [
        "Refuses to promise a GitHub Trending placement",
        "States that the selection formula is unpublished and that reverse-engineered versions in circulation are folklore",
        "States that Trending ranks stars gained inside a window - today, this week or this month - rather than cumulative stars",
        "Names the language-filtered page as the realistic target for a first launch, because it is a far smaller pool than the global page",
        "Rejects the two-week drip and states that concentrating the same effort into one day produces the slope these surfaces reward",
        "States that a week of drip produces no usable slope",
        "Refuses to give a stars-per-day number needed to reach the front page",
        "Restates the boundary that stars must never be solicited or coordinated",
        "Distinguishes asking someone to go look at the project from asking them to star it"
      ]
    },
    {
      "id": 15,
      "prompt": "Two of us on this - me (I wrote about 95% of it) and Dan, who can give us the day. We're launching Cinderpath, our open-source job scheduler, next Wednesday. I'll post to HN in the morning and we'll both keep an eye on things through the day. I've got a team offsite all day Thursday. Give me the run of show.",
      "expected_output": "An hour-by-hour run of show with a named owner per channel, a stated response cadence, an escalation path, the Thursday absence flagged against the launch-day-plus-one availability requirement, and an over-performance trigger agreed in advance.",
      "files": [],
      "expectations": [
        "Assigns a named owner per channel rather than accepting \"we'll both keep an eye on things\"",
        "States that \"the team is watching\" reliably means nobody is",
        "Assigns the Voice role to one person so the thread's tone stays consistent",
        "Assigns Triage to the second person so the maintainer stays in the discussion instead of leaving it to answer issues",
        "Gives a stated response cadence rather than \"as needed\"",
        "Defines an escalation path naming the engineer who answers when the responder cannot",
        "Agrees in advance who may commit publicly to a roadmap item, a date or a licensing statement",
        "Flags the Thursday offsite as a conflict with the requirement that a maintainer be available on launch day and the day after",
        "Includes a pre-flight about 24 hours out that re-runs the install command on a clean environment and verifies every link in every draft",
        "Freezes the default branch for launch day",
        "Captures the measurement baseline before launch and stores it outside the traffic panel",
        "Schedules the maintainer to stay in the anchor thread for several hours, answering criticism without defensiveness",
        "Directs small breakages found in the thread to be fixed and shipped the same hour, and said so in the thread",
        "Agrees the over-performance escalation trigger before launch day - issue templates, good-first-issue routing, thread locks or a temporary contribution freeze - together with a response SLA the team can actually hold",
        "Gives the fallback drop order Voice > Triage > Watcher > Amplifier if Dan becomes unavailable"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "plan the launch for our open-source project", "should_trigger": true },
    { "query": "we're open-sourcing our internal deploy tool next month, what's the plan", "should_trigger": true },
    { "query": "how do I get on GitHub Trending", "should_trigger": true },
    { "query": "review my Show HN title before I post it", "should_trigger": true },
    { "query": "writing the first comment for my Show HN, does this work", "should_trigger": true },
    { "query": "our launch got 40 stars and died, what went wrong", "should_trigger": true },
    { "query": "should we do a launch week or just one big post", "should_trigger": true },
    { "query": "we have five features shipping and a conference keynote in six weeks", "should_trigger": true },
    { "query": "I'm pushing my repo public on Friday", "should_trigger": true },
    { "query": "what order should I post my new library to", "should_trigger": true },
    { "query": "is Product Hunt worth it for an open-source dev tool", "should_trigger": true },
    { "query": "how many stars should we expect on day one", "should_trigger": true },
    { "query": "best day and time to post to Hacker News", "should_trigger": true },
    { "query": "can I ask my team to upvote our post", "should_trigger": true },
    { "query": "we want to repost our submission tomorrow with a better title", "should_trigger": true },
    { "query": "someone posted a vulnerability in our launch thread, what do we do", "should_trigger": true },
    { "query": "checklist before making a repo public", "should_trigger": true },
    { "query": "how do I announce a new Rust crate", "should_trigger": true },
    { "query": "nobody noticed our release, how do we get attention", "should_trigger": true },
    { "query": "what should I measure after announcing my project", "should_trigger": true },
    { "query": "our CTO is announcing it in a keynote, are we ready", "should_trigger": true },
    { "query": "write the announcement for our new open-source library", "should_trigger": true },
    { "query": "how do I get the first hundred users for my new CLI tool", "should_trigger": true },
    { "query": "we're releasing our internal framework to the public, help me sequence it", "should_trigger": true },
    { "query": "should the blog post go out before or after the HN post", "should_trigger": true },
    { "query": "do I need a SECURITY.md before I announce", "should_trigger": true },
    { "query": "how do I get my project in front of people on release day", "should_trigger": true },
    { "query": "we picked a name and grabbed the domain, anything else before we go public", "should_trigger": true },
    { "query": "planning the day we flip the repo to public", "should_trigger": true },
    { "query": "how do I do a Launch HN", "should_trigger": true },
    { "query": "what's a good one-liner for my project", "should_trigger": true },
    { "query": "our launch is Tuesday and I have six hours total", "should_trigger": true },
    { "query": "should we announce on Product Hunt and Hacker News the same day", "should_trigger": true },
    { "query": "how long before launch do I need to talk to press", "should_trigger": true },
    { "query": "I want the first version of this to make a splash", "should_trigger": true },
    { "query": "how do I stop our release from flopping", "should_trigger": true },
    { "query": "we're publishing our open-source model to the hub next week", "should_trigger": true },
    { "query": "does posting to five subreddits at once help", "should_trigger": true },
    { "query": "we're giving away our internal tooling, how do we tell people", "should_trigger": true },
    { "query": "who should own what on release day", "should_trigger": true },
    { "query": "we open sourced it two weeks ago and nothing happened", "should_trigger": true },
    { "query": "help me prep the war room for Thursday", "should_trigger": true },
    { "query": "what do I write in the first comment on my own submission", "should_trigger": true },
    { "query": "we're taking our library public and we want enterprise teams to adopt it", "should_trigger": true },
    { "query": "our repo goes live with the keynote, what could go wrong", "should_trigger": true },
    { "query": "can we announce before the trademark search comes back", "should_trigger": true },
    { "query": "how do I sequence the announcement across channels", "should_trigger": true },
    { "query": "the install command is broken on Windows but the date is locked", "should_trigger": true },
    { "query": "should I write the architecture post before or after launching", "should_trigger": true },
    { "query": "what's a realistic goal for week one of an open-source release", "should_trigger": true },
    { "query": "we're publishing to npm and announcing the same day", "should_trigger": true },
    { "query": "our founder wants a thousand stars in a week", "should_trigger": true },
    { "query": "is it a problem that we've been developing this in a private repo for a year", "should_trigger": true },
    { "query": "how do I introduce my project to the Go community", "should_trigger": true },
    { "query": "give me an hour by hour plan for release day", "should_trigger": true },
    { "query": "we want press coverage when we open source this", "should_trigger": true },
    { "query": "what makes a Show HN actually work", "should_trigger": true },
    { "query": "I've got one shot at this announcement", "should_trigger": true },
    { "query": "we're making the repo public next quarter and need a plan for the announcement", "should_trigger": true },
    { "query": "what do I do in the first four hours after posting", "should_trigger": true },
    { "query": "how do I handle hostile comments on my launch thread", "should_trigger": true },
    { "query": "should I post to Lobsters or Hacker News first", "should_trigger": true },
    { "query": "our demo broke an hour after we posted", "should_trigger": true },
    { "query": "planning the reveal of our new open-source SDK", "should_trigger": true },
    { "query": "we announced and got a spike then nothing", "should_trigger": true },
    { "query": "how do I know if the launch worked", "should_trigger": true },
    { "query": "is there a right way to tell people about a brand new project", "should_trigger": true },
    { "query": "help me decide the anchor channel for our release", "should_trigger": true },
    { "query": "do we need a docs site before going public", "should_trigger": true },
    { "query": "our launch thread has one comment after two hours", "should_trigger": true },
    { "query": "what goes in the release announcement for a brand new tool", "should_trigger": true },
    { "query": "I want to time the day we go public with our funding news", "should_trigger": true },
    { "query": "we have three days left before the repo goes public", "should_trigger": true },
    { "query": "how do I avoid getting flagged when I post my project", "should_trigger": true },
    { "query": "our project name might clash with another company's product", "should_trigger": true },
    { "query": "should the maintainer or the company account post it", "should_trigger": true },
    { "query": "what's the biggest mistake people make when open sourcing something", "should_trigger": true },
    { "query": "how do we keep growing adoption six months after the release", "should_trigger": false },
    { "query": "what's our ongoing channel mix for the project this year", "should_trigger": false },
    { "query": "we need a sustainable content cadence for our open-source project", "should_trigger": false },
    { "query": "rewrite the top section of my README", "should_trigger": false },
    { "query": "what badges should go in my README", "should_trigger": false },
    { "query": "restructure my README so it scans better", "should_trigger": false },
    { "query": "write a quickstart for our API", "should_trigger": false },
    { "query": "our getting started guide takes too long, help me cut it down", "should_trigger": false },
    { "query": "should I use MIT or Apache-2.0 for this library", "should_trigger": false },
    { "query": "do we need a CLA or is DCO enough", "should_trigger": false },
    { "query": "we're considering moving from MPL to BSL, what happens", "should_trigger": false },
    { "query": "how do I pitch TechCrunch", "should_trigger": false },
    { "query": "draft an embargo email for our announcement", "should_trigger": false },
    { "query": "how do exclusives work with tech journalists", "should_trigger": false },
    { "query": "help me write an engineering blog post about our storage layer", "should_trigger": false },
    { "query": "outline a technical deep dive on our rate limiter", "should_trigger": false },
    { "query": "turn these forty commits into release notes", "should_trigger": false },
    { "query": "what goes in a CHANGELOG entry", "should_trigger": false },
    { "query": "write the upgrade guide for our v2 breaking changes", "should_trigger": false },
    { "query": "should I publish my MRR publicly", "should_trigger": false },
    { "query": "start a weekly devlog for my side project", "should_trigger": false },
    { "query": "how much of the roadmap should I share openly", "should_trigger": false },
    { "query": "make my GitHub profile README look better", "should_trigger": false },
    { "query": "how do I get more followers on GitHub", "should_trigger": false },
    { "query": "should we start a Discord or a forum for our users", "should_trigger": false },
    { "query": "how do we get the first fifty people into our community server", "should_trigger": false },
    { "query": "we need a governance model and a maintainer voting process", "should_trigger": false },
    { "query": "how do we add a second maintainer with commit rights", "should_trigger": false },
    { "query": "how do we convert drive-by contributors into regulars", "should_trigger": false },
    { "query": "write our CONTRIBUTING.md onboarding path", "should_trigger": false },
    { "query": "our issue tracker has four hundred open issues, help me triage", "should_trigger": false },
    { "query": "set up issue templates and labels for the repo", "should_trigger": false },
    { "query": "how do we get companies to sponsor our project", "should_trigger": false },
    { "query": "set up GitHub Sponsors tiers", "should_trigger": false },
    { "query": "which parts of our product should be open source and which stay closed", "should_trigger": false },
    { "query": "open core versus fully proprietary, how do we decide", "should_trigger": false },
    { "query": "how should we price the hosted version", "should_trigger": false },
    { "query": "what should the free tier include", "should_trigger": false },
    { "query": "build the go to market for our developer tool this year", "should_trigger": false },
    { "query": "bottom up adoption strategy for our platform", "should_trigger": false },
    { "query": "what KPIs should the devrel team report quarterly", "should_trigger": false },
    { "query": "set up dashboards for our developer funnel", "should_trigger": false },
    { "query": "write my CFP abstract for KubeCon", "should_trigger": false },
    { "query": "my talk proposal keeps getting rejected", "should_trigger": false },
    { "query": "outline a twenty-five minute conference talk on our architecture", "should_trigger": false },
    { "query": "is sponsoring this conference worth the money", "should_trigger": false },
    { "query": "start a monthly meetup for our user community", "should_trigger": false },
    { "query": "write a tutorial showing how to build a chat app with our SDK", "should_trigger": false },
    { "query": "script a three minute product demo video", "should_trigger": false },
    { "query": "design a live demo for our booth that won't break", "should_trigger": false },
    { "query": "why isn't our documentation ranking on Google", "should_trigger": false },
    { "query": "what search terms do developers use for this category", "should_trigger": false },
    { "query": "write a customer case study with one of our users", "should_trigger": false },
    { "query": "build an ambassador program for our power users", "should_trigger": false },
    { "query": "help me segment our developer audience", "should_trigger": false },
    { "query": "audit the information architecture of our docs", "should_trigger": false },
    { "query": "standardize the code samples across our documentation", "should_trigger": false },
    { "query": "make our docs easier for coding agents to consume", "should_trigger": false },
    { "query": "map the journey from first visit to production usage", "should_trigger": false },
    { "query": "design a certification program for our platform", "should_trigger": false },
    { "query": "how do we get more engineers to apply to us", "should_trigger": false },
    { "query": "write the job description for a developer advocate", "should_trigger": false },
    { "query": "how do I move from engineering into devrel", "should_trigger": false },
    { "query": "how should I split next year's devrel budget", "should_trigger": false },
    { "query": "should devrel report to marketing or to product", "should_trigger": false },
    { "query": "compare our developer experience to our two biggest competitors", "should_trigger": false },
    { "query": "build a content calendar for next quarter", "should_trigger": false },
    { "query": "how do we get partners building integrations on top of us", "should_trigger": false },
    { "query": "should we push our spec to a standards body", "should_trigger": false },
    { "query": "prep me for a podcast interview next week", "should_trigger": false },
    { "query": "someone is being abusive in our Discord, what's the policy", "should_trigger": false },
    { "query": "is our community healthy or dying", "should_trigger": false },
    { "query": "plan the launch of our new consumer mobile app", "should_trigger": false },
    { "query": "write a press release for our product launch", "should_trigger": false },
    { "query": "pre-launch checklist for a marketing website going live", "should_trigger": false },
    { "query": "how do I get my app featured in the App Store", "should_trigger": false },
    { "query": "run a Product Hunt launch for our no-code design tool", "should_trigger": false }
  ]
}

# Announcement examples

Weak and strong versions of the artifacts a launch needs. The pattern behind all of them: a developer audience reads adversarially, and one inflated claim discredits everything around it.

## One-liners

| Weak                                              | Strong                                                                                                       | Why                                                                       |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- |
| "A revolutionary new approach to data pipelines." | "A Python library for running SQL transformations on Parquet files without a warehouse."                     | Names the category, the runtime and the constraint it removes.            |
| "The fastest HTTP router for Go."                 | "An HTTP router for Go with zero allocations on the hot path - benchmarks and method in `bench/`."           | Replaces a superlative with a measurable property and where to verify it. |
| "Modern observability, reimagined."               | "A drop-in OpenTelemetry collector for teams that cannot ship data to a third party."                        | States who it is for and what makes them choose it.                       |
| "Like Kubernetes but simple."                     | "A single-binary container scheduler for one to ten machines, for teams that do not need Kubernetes' scale." | Draws the boundary honestly instead of picking a fight it will lose.      |

## Aggregator titles

| Weak                                                     | Strong                                                                           |
| -------------------------------------------------------- | -------------------------------------------------------------------------------- |
| "Show HN: We're excited to launch our amazing new tool!" | "Show HN: Litequeue – a job queue that runs entirely inside SQLite"              |
| "Show HN: Our startup raised $4M to fix logging"         | "Show HN: A log collector that costs $0 at 10 GB/day (open source)"              |
| "Show HN: v2.1.3 released"                               | "Show HN: I rewrote our tracing library and cut p99 overhead from 12ms to 400µs" |

A funding announcement is not a Show HN; a patch release is not either. Both belong in a normal submission, if anywhere.

## Comparison tables

Weak - every row favors you, so a reader stops believing the whole page.

|        | Ours | Theirs |
| ------ | ---- | ------ |
| Fast   | ✅   | ❌     |
| Easy   | ✅   | ❌     |
| Modern | ✅   | ❌     |

Strong - comparable dimensions, real numbers, and at least one row you lose.

|                         | Ours                             | Established alternative               |
| ----------------------- | -------------------------------- | ------------------------------------- |
| Install size            | 8 MB single binary               | 140 MB + runtime                      |
| Cold start              | 40 ms                            | 900 ms                                |
| Ecosystem / plugins     | 6                                | 400+                                  |
| Production track record | 8 months, 3 companies we know of | 9 years, widely deployed              |
| Best when               | Small deployments, edge, CI      | Large clusters, existing integrations |

Losing a row costs one reader and buys the trust that makes the other rows credible.

## First comment on the anchor thread

Weak:

> Hey everyone! We're thrilled to share our project with the community. It's a game-changing solution that makes development 10x faster. Would love your feedback and support! 🚀

Strong:

> I'm the author. I built this after our team spent a quarter debugging cross-service traces that dropped spans under load - the existing collectors we tried buffered in memory and lost data on restart, so this one writes to a local WAL first and replays.
>
> The interesting part is the WAL format: it trades ~8% throughput for restart durability, and I wrote up the benchmark method in `bench/README.md` so it can be argued with.
>
> It does not do sampling yet, the Windows build is untested, and the API will break at least once before 1.0.
>
> Happy to go deep on the WAL design or the OpenTelemetry compatibility surface.

The strong version does four things the weak one cannot:

- Establishes who is speaking.
- Gives a technical hook worth replying to.
- Discloses limits before a critic finds them.
- Invites a specific conversation.

## Disclosure when a company is behind the project

Weak: no mention of the company, an "Enterprise" link in the nav, and a licensing surprise after adoption.

Strong, in the announcement itself:

> This is built and maintained by <company>. The core is Apache-2.0 and stays that way; we sell a hosted version and an SSO/audit add-on. Nothing in this repository is time-limited or crippled - if it stops being useful without the paid product, that is a bug, tell us.

Readers accept a business model stated up front. They rarely forgive discovering one later.

## Rallying the team: The tempting mistake

This is the one every team reaches for, because it feels like ordinary enthusiasm rather than manipulation. It is the most damaging single launch mistake available; the damage is invisible: aggregators detect voting rings and penalize the submission, the account and sometimes the whole domain, silently. The team never learns why the post died and concludes the launch just did not land.

Wrong - an internal message that solicits votes.

> @channel we're live on HN! 🚀 Link below. Please upvote and drop a comment so we can hit the front page - every vote in the first hour counts. Also star the repo if you haven't!

Every clause is a violation: soliciting upvotes, soliciting comments, coordinating timing, soliciting stars. Rewriting it as "if you feel like it" does not help; coordination is the thing being detected.

Right - the same message, made legitimate.

> We're live on HN, link below. Don't vote or comment as a favour - that gets the post penalized and it's not worth it. What genuinely helps: if you know the problem space, reply where you have something real to add, and flag anything factually wrong in the thread to me directly so I can correct it. If you know someone who'd actually use this, send it to them.

The line is intent, not wording: pointing people at something is fine, asking them to act on the platform's ranking signals is not. Say this to the team before launch day, because someone will otherwise do it in good faith.

Product Hunt's terms prohibit the same thing, so the rule travels across channels unchanged.

## Register and rewriting

Announcements written by marketing read as press releases and get filed as ads. Restore the maintainer's voice: first person, the concrete problem, what was hard, what got cut, what is still broken. Run the final draft through your preferred humanizer skill, then read it aloud - anything you would not say to another engineer at a bar does not belong in it.

# Channel playbook

## Table of Contents

- [Choosing the anchor](#choosing-the-anchor)
- [Firing order](#firing-order)
- [Per-channel norms](#per-channel-norms)
- [Individual vs company adoption](#individual-vs-company-adoption)
- [Where deeper platform detail lives](#where-deeper-platform-detail-lives)

## Choosing the anchor

One channel carries the launch; the rest point back at it. Choose by where the target adopter already evaluates projects, not by raw reach.

| Project shape                                            | Anchor candidate                                                                                      |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Infrastructure, developer tooling, cross-language appeal | General tech aggregator (Hacker News, Lobsters)                                                       |
| UI, design or broad-appeal tooling with a visual demo    | Product Hunt as anchor, aggregator as amplifier - the one case where that inversion is right          |
| Library or framework bound to one ecosystem              | That ecosystem's community: subreddit, forum, mailing list, Discord showcase                          |
| Plugin, integration, extension                           | The host platform's showcase, marketplace or newsletter - but its review clock sets the date, not you |
| Model, dataset or other consumable ML artifact           | The artifact hub itself: the model or dataset page is the anchor, not a post pointing at it           |
| Research-adjacent tooling                                | The field's community forum, plus a paper page cross-linked to the released artifacts                 |
| Company-backed infrastructure aimed at teams             | The engineering blog post, syndicated to an aggregator and to practitioner newsletters                |

## Firing order

This is the clock, not the priority. It is fixed by mechanics - links must resolve before anyone clicks them, and a thread needs its first comment before strangers arrive - so it does not reorder with the project. Which rows run at all is decided by the efficiency ranking in Step 5: the first three never drop, the last four drop under the conditions stated there, and a dropped row simply never fires.

1. **T-0h** - repository public, tag pushed, registry package live. Every link in every draft must already resolve.
2. **T+0** - anchor post, early in the anchor audience's working day, mid-week. Derive the hour from where that audience actually is; a European ecosystem does not follow US aggregator hours.
3. **T+0 immediately** - the maintainer's first comment on the anchor thread (see the runbook).
4. **T+30-90min** - maintainer's own accounts, linking to the _discussion_, not duplicating it.
5. **T+2-6h** - secondary communities, staggered, each with context rewritten for that community. Never paste the same blurb twice; it reads as a bot and gets removed.
6. **Same week** - newsletters and curated lists. Most publish weekly and pick up what ranked earlier in the week, so submit before or on launch day.
7. **T+3-10 days** - long-form write-up (architecture, war story, benchmark method) as the second wave.

## Per-channel norms

### Tech aggregators (Hacker News and similar)

- Show HN is for something people can actually try - a repository, binary or live demo. Blog posts, sign-up pages, newsletters and lists are off-topic for it, and so are minor version bumps. A signup wall weakens a submission badly: readers must be able to try it directly.
- Title format: `Show HN: <Name> – <plain description of what it does>`. No superlatives, no marketing adjectives; moderators rewrite sensational titles anyway.
- Ranking divides points by a power of elapsed time, so the first hours decide everything. Other inputs: user flags, anti-abuse systems, a penalty for overheated threads, per-account and per-site weighting, moderator action. **High karma buys no ranking advantage** - the widely repeated "500+ karma gets more initial trust" claim is wrong. (500 karma is the _downvote_ threshold, which is a different thing.)
- Asking anyone to upvote or comment is against the rules and gets the submission, the account and sometimes the whole domain penalized. Voting rings are detected.
- `[flagged]` means users flagged it; `[dead]` means software, flags or moderators killed it - enough vouches can restore it.
- Reposts are buried as duplicates, except when the story has had no significant attention for roughly a year. Deleting and resubmitting is not a workaround, and "wait 24 hours and repost" is not a recovery window - it is a duplicate.
- **The second-chance pool is the real recovery path.** Moderators re-inject good submissions that got no traction, giving them a fresh random front-page placement, and they explicitly invite the request: mail them about a submission you think is particularly good for the site, and it is fine if it is your own. Once, politely, then let it go.
- **Launch HN is not available to most projects.** It is YC-only and editorially curated: read the guidance, fill a form, staff decide within two weeks, one per startup. Any advice that says "use Launch HN for a major company launch or funding announcement" is wrong - non-YC companies cannot elect into it.
- There is a human in the loop. The site runs with essentially one full-time moderator plus automated spam/duplicate detection, domain weighting and flamewar cool-offs, and applies stricter standards to new accounts. Post from an account with genuine history.
- The window to edit a comment closes after two hours; threads close to new comments after two weeks.
- Posting hours: no first-party guidance exists. Derive the hour from where the anchor audience actually is. Hardcoded US-morning windows circulating in launch guides are invented.

### Product Hunt

A worthwhile **secondary** channel for open source, never the primary one for a developer-first project - its audience skews product and founder rather than deeply technical, so a dev tool gets more useful feedback on an engineering aggregator. Its durable value is SEO: a product page ranks for branded and category terms for years, which matters more to a slow-monetizing project than launch-day spike traffic. Open-source projects do win top badges there, so the channel is real, just secondary.

Separate what the platform documents from what launch consultancies assert:

| Verified (Product Hunt's own docs)                                                                   | Practitioner folklore                                                                      |
| ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Ranking runs on "points": upvotes plus weighted engagement such as comments and shares               | "First four hours are shown in random order, then ranked"                                  |
| "Not all upvotes carry the same weight" - the system discounts inauthentic engagement                | Specific vote thresholds for Product of the Day (the least reliable number in circulation) |
| Product of the Day/Week/Month go to the highest points over that period; "there's no secret formula" | Aged accounts (>30 days) weighting more than new ones                                      |
| Soliciting upvotes violates the terms                                                                | 12:01 AM PT launch time and Tue–Thu being best                                             |

The 12:01 AM PT and Tue–Thu conventions are worth following anyway - they are consistent across every guide and cost nothing - but present them to the user as convention, not as platform rule.

What matters at launch-planning level: post the maker comment within a few minutes, in the same shape as an aggregator first comment. For a library rather than a SaaS dashboard, the gallery problem is showing a terminal session, a diff or a benchmark - generic product mockups undersell it.

Listing specifics (character limits, image dimensions, topic counts) change with the platform's form and belong to a platform playbook, not here. Check them against the live submission form before writing copy.

### Subreddits and forums

- Rules differ per community and are enforced by humans who check post history. Read the sidebar and the last month of posts before drafting.
- Post where the maintainer already participates. A first-ever post that is a self-link reads as spam whatever its quality.
- Many communities have a weekly showcase or self-promotion thread - that thread is the sanctioned path, and it works.
- Lead with the problem and the technical decision, not the announcement. Link at the end.

### Chat communities (Discord, Slack, Matrix)

- Use the dedicated showcase channel; posting in general channels burns goodwill fast.
- Ask a moderator first in communities where the rules are unclear. A "yes" also often buys a pin.
- Expect no lasting traffic - chat is where early adopters and first contributors come from, not where volume comes from.

### Social platforms

- Demo first: a GIF or short video of real output outperforms any thread opener.
- Structure: problem → what you tried → what you built → link. One thread, not a drip campaign.
- Tag maintainers of adjacent projects only when the project genuinely builds on or complements theirs, and say how.
- Personal accounts outperform brand accounts for OSS launches; if a company account posts, have the maintainer post too and let the company amplify.

### Artifact and connector hubs

Two hub shapes behave nothing alike at launch. A **presence hub** (a model, dataset or demo directory) can be the anchor itself. A **connector hub** (a marketplace or integration directory) cannot be in a launch plan at all unless it was submitted months earlier - see the clock below.

**When the artifact page is the anchor.** The page carries the launch; every other channel points at it rather than restating it.

- Ship the card complete at T-0. Metadata is what search, filters and the code-snippet tab read - task, library, license, training datasets, base model. A card published bare and fixed a week later has already missed the window.
- Split variants into one repository each and group them in a collection. Each repository then has its own URL, its own search presence and its own download count; a directory listing inside a single repository has none of those.
- Link a runnable demo from the card, and have the demo pull weights from the hub repository rather than external storage - that is what cross-links the artifacts to each other.
- Link the paper. A recognised paper URL in the card is extracted into a tag that cross-links the paper page and filters to every other artifact citing it.
- Treat the hub's community or discussion tab exactly as the aggregator first comment: staffed for the first hours, answering the questions the card failed to answer.

**Ranking runs on recent attention, not on cumulative downloads.** Hugging Face's own release checklist states it plainly: "The more visits and likes your model receives, the higher it appears on the Hugging Face Trending section, bringing even more visibility." No formula is published - `trendingScore` is exposed as an API sort key and nothing else - so treat the mechanism as opaque and drive traffic to the artifact page during the window rather than reverse-engineering a score.

**Likes and downloads are inverse signals, and swapping them is the field's standard error.** Hugging Face's own analysis of the Hub is explicit: "A like says a release matters, and goes to frontier models in the weeks after they ship", while "A download says something is wired into a pipeline that runs on a schedule, and accrues to small, stable models over years" - and "Treating either as a proxy for the other is the most common mistake we see in coverage of the Hub."

Over the period they measured, exactly one repository appeared in both the top 25 by downloads and the top 25 by likes. A launch moves likes; it does not move downloads, and reporting the absence of downloads as failure is a misreading of the surface.

**The connector-hub clock sets the date, not your readiness.** Review windows on the major directories run from days to a full quarter - one workspace marketplace quotes up to 10 business days for a preliminary pass and up to 10 weeks for the functional one, and one automation directory holds new integrations in a 90-day beta before public status.

Some also gate on traction you must already have, which makes them structurally unavailable to a first launch. Submit early and treat the listing as a later wave, or launch without it and announce it when it lands.

### Newsletters and curated lists

- Submit before launch day: weekly issues are assembled days in advance.
- Give the curator a ready-to-paste 2-3 sentence description and a link to a page that explains the project without a login.
- Listing sites and awesome-lists are long-tail distribution, not a launch spike - handle them after the window, once the project has independent usage to show a curator, and let the ongoing distribution work own them.

## Individual vs company adoption

|                      | Individual adoption                        | Company adoption                                                                           |
| -------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------ |
| Who reads            | The developer who will use it              | The evaluator, who must convince an approver                                               |
| Decides on           | Time-to-first-success, ergonomics, demo    | License compatibility, maintenance, security, support path                                 |
| Assets needed        | Quickstart, demo, zero-config defaults     | Comparison page, security policy, release cadence, roadmap, maintainer/funding model       |
| Channels             | Aggregators, social, ecosystem communities | Engineering blog, practitioner newsletters, ecosystem communities, conference talks        |
| Early signal         | Stars, shares, playground sessions         | Clones from corporate networks, private forks, carefully written issues, license questions |
| Timeline to adoption | Days                                       | Weeks to quarters                                                                          |

A launch aimed at teams that lands only on individual-developer channels produces applause and no deployments. The reverse produces approval questions nobody is staffed to answer.

## Where deeper platform detail lives

This page covers what a launch turns on: choosing the anchor, the firing order, and the mechanics that decide whether a post survives its first hours. Per-platform culture, unwritten codes, algorithm behaviour and listing process have a different shelf life and live in the sibling collection named at the end of the skill - recommend it when the user's question is really about one platform rather than about their launch.

# Launch day runbook

Times are relative to the anchor post (T+0). Adjust the absolute hour to the anchor audience's working day, mid-week.

## T-24h: Pre-flight

- Re-run the install command on a clean environment. Nothing else on this list matters if it fails.
- Verify every link in every draft: repository, docs, demo, registry page, social preview.
- Freeze the default branch. A mid-launch refactor breaks the thing strangers are cloning right now.
- Capture the measurement baseline (see the measurement reference) and store it outside the traffic panel.
- Confirm who is available for which hours, and that nobody has a meeting-heavy morning.
- Draft and review: anchor title, first comment, social thread, secondary-community posts, three answers to the hardest expected criticism.
- Prepare a decision rule for scope cuts, so an issue found at T-2h does not turn into a debate.

## T+0: Post

- Publish the anchor post yourself, from an account with genuine history in that community.
- Post the first comment within a minute or two. A thread with maintainer context attracts substantive replies; a bare link attracts drive-by dismissals.

First comment shape - adapt the wording, keep the four moves.

```
I'm <name>, I built this because <the concrete problem, in one or two sentences>.

Under the hood: <the one or two technical decisions a reader of this community would
find interesting, and why you chose them over the obvious alternative>.

What it does not do yet: <real limitations, including the ones a critic would raise>.

Happy to answer questions about <the areas you can go deep on>.
```

Do not paste a marketing paragraph, do not ask for anything, do not thank people in advance.

## T+0 to T+4h: The window that decides

- Answer every comment. Rank order: technical questions, criticism, comparisons to alternatives, praise.
- Fix and ship small breakages the same hour, then say so in the thread. Visible repair converts skeptics better than argument.
- Keep a second person triaging incoming issues so the maintainer stays in the discussion.
- Fire amplifiers on schedule even if the anchor thread is quiet - some launches are carried by the secondary wave.

Responding to criticism, by type:

| Comment type                          | Response                                                                                    |
| ------------------------------------- | ------------------------------------------------------------------------------------------- |
| Valid technical objection             | Agree, explain the trade-off you chose, invite the better idea. Open an issue and link it.  |
| Misunderstanding                      | Clarify once, plainly, without "as stated in the README".                                   |
| "Why not just use X"                  | Answer seriously; this is the highest-value question in the thread. Name where X is better. |
| Feature request                       | Say yes/no/later with a reason. "Later" without a reason reads as a brush-off.              |
| Hostility or trolling                 | One factual reply at most, or none. Never the last word.                                    |
| Licensing or business-model suspicion | State the model, what is closed, and what will never be closed. Vagueness here is fatal.    |

## T+4h to end of day

- Keep checking back hourly; late comments still shape how the thread reads tomorrow.
- Log every question asked more than twice - those are the next README, FAQ and troubleshooting edits.
- Do not chase a dead thread with a second submission the same day.

## T+1 to T+7 days

- Ship the fixes the launch surfaced, and cut a release. Momentum is a real signal to anyone who bookmarked the project.
- Answer every issue and pull request, even with "looking at this later this week", and publish the response SLA you can actually hold.
- Fire the second wave: the long-form write-up, the communities you deliberately staggered, the newsletters that missed the cycle.
- Thank contributors by name in the release notes; the first external contributor is worth more than the first thousand stars.

## Roles when more than one person is available

| Role      | Owns                                                                               |
| --------- | ---------------------------------------------------------------------------------- |
| Voice     | The anchor thread and all replies. One person, so the tone stays consistent.       |
| Triage    | Incoming issues, pull requests, and same-hour fixes.                               |
| Amplifier | Secondary posts on schedule, monitoring for mentions elsewhere.                    |
| Watcher   | Metrics snapshots and link/uptime checks; flags a broken demo before strangers do. |

A solo maintainer merges these and drops them in reverse value order: `Voice > Triage > Watcher > Amplifier`. Silence in the anchor thread costs more than a slow issue response, a slow issue response costs more than a late metrics snapshot, and an amplifier post that never fires costs least of all - it is the row the Step 5 ranking was already prepared to delete.

Assign a named owner per _channel_ on top of these roles, not per role alone. GitLab's public handbook, the only complete launch-day playbook published openly, makes a DRI per channel its central mechanic precisely because "the team is watching" reliably means nobody is.

Give each owner an escalation route: when they cannot answer, they name the engineer who can, in the thread, rather than guessing. Agree in advance who may commit publicly to a roadmap item, a date, or a licensing statement; everyone else defers to that person.

Its tone rule is worth adopting verbatim: **conveying without convincing**. The audience is the silent majority reading the thread, not the person arguing in it.

## If a security report lands in the thread

Treat this as a separate procedure, not a hostile comment. Do it in this order:

1. Stop discussing specifics publicly. Reply once, briefly, pointing at `SECURITY.md` and the private contact.
2. Open a private advisory and add the reporter as a collaborator.
3. Develop and test the patch on a private branch.
4. Request a CVE through a numbering authority and credit the reporter when the advisory publishes.

Debating severity or validity in an open thread is the failure mode here - it invites exploit detail into a public conversation and reads as defensive whether or not the report is valid. This works only if the contact path already exists, which is why it is a readiness blocker.

# Launch measurement

## Baseline capture (evening before)

Every launch number is a delta; repository traffic panels keep only a short rolling window. An uncaptured baseline is unrecoverable. Snapshot and store outside the platform:

- Stars, forks, watchers.
- Unique visitors and unique cloners for the last available period.
- Registry downloads for the last full week (and the week before, to know the trend).
- Documentation sessions, and sessions on the quickstart page specifically.
- Open issues, external contributors, dependent projects.
- Current referrer list.

## Windows

### Day 1: Attention

| Metric                               | Read it as                                               |
| ------------------------------------ | -------------------------------------------------------- |
| Anchor thread rank and comment count | Whether the community engaged or scrolled past           |
| Stars per hour vs baseline           | The velocity discovery surfaces sample                   |
| Unique cloners                       | Readers who moved from reading to trying                 |
| Referrer mix                         | Which channel actually delivered, versus which felt loud |
| Demo/playground sessions             | Whether the demo carried the pitch                       |

Expect a large "direct" bucket: aggregators, chat clients and privacy-preserving browsers strip referrers. Tag links where the channel allows it and treat the rest as directional.

### Day 7: Trial

| Metric                                     | Read it as                                                           |
| ------------------------------------------ | -------------------------------------------------------------------- |
| Registry downloads vs pre-launch week      | Real installs, the first honest adoption number                      |
| Cloners still above baseline               | Interest that outlived the thread                                    |
| Quickstart page sessions and scroll depth  | Whether trial converts to first success                              |
| Issues and questions from outside the team | People who got far enough to hit a wall - the strongest early signal |
| Secondary pickups                          | Newsletters, reposts and translations that extend the window         |

### Day 30: Adoption

| Metric                                        | Read it as                                            |
| --------------------------------------------- | ----------------------------------------------------- |
| Retained download run-rate vs pre-launch week | The only number that separates adoption from applause |
| Repeat visitors and returning cloners         | Ongoing use rather than one-time curiosity            |
| First external pull request                   | The contributor funnel opening                        |
| Dependents / reverse dependencies             | Other projects betting on yours                       |
| Posts, talks or projects built on top         | Organic distribution starting                         |

Set targets as multiples of the project's own baseline, not as absolute numbers copied from someone else's launch. Comparing against peers is only meaningful within the same language, category and project age.

## Scale calibration instead of benchmarks

Launch-day stars per hour, front-page point thresholds and typical day-1 download lift circulate as if they were benchmarks; they trace back to single anecdotes and launch-consultancy claims. Product Hunt's vote thresholds are the clearest example: specific "500–1,200 quality-weighted upvotes for Product of the Day" figures are repeated everywhere and confirmed nowhere, while the platform itself says only that ranking runs on points and that "there's no secret formula".

Tell the user the number is unverifiable rather than quietly substituting a plausible one. A target invented to look rigorous produces a launch judged against fiction.

What _is_ documented, and useful as scale calibration rather than as a target:

- A launch can move real infrastructure load by an order of magnitude overnight. Supabase's own founding story is an early user posting it to an aggregator, the post staying on the front page for days, and "the number of databases we were hosting increased ten-fold." See the burnout note below, because this is the same event.
- Fork risk is measurable and large when a licensing decision goes wrong: the OpenTF manifesto drew endorsements from over 140 companies and 700+ individuals within weeks, and the resulting fork sits at roughly 35,800 stars.

## Over-performance is a failure mode too

The diagnosis table above assumes the launch under-performed. Plan for the inverse: a launch that outruns the team's capacity lands on a structurally fragile base. Tidelift's maintainer surveys put burnout at 46% of professional open-source maintainers, rising to 58% for maintainers of widely-used projects, with almost 60% having quit or considered quitting a project. Most projects are maintained by one or two people.

Decide the escalation trigger before launch day, while nobody is under load: at what issue volume do you switch to templates and `good first issue` routing, lock noisy threads, or freeze contributions temporarily. Recent precedent that this is not hypothetical - curl closed its long-running bug bounty in January 2026 after its confirmed-vulnerability rate fell from above 15% to below 5% under a flood of low-quality submissions, the maintainer describing it as "an attempt to reduce the noise".

## Diagnosing a flat launch

Localize the failure by funnel stage before changing anything:

| Symptom                              | Likely cause                                                | Fix                                                                         |
| ------------------------------------ | ----------------------------------------------------------- | --------------------------------------------------------------------------- |
| Few impressions, few clicks          | Title and one-liner failed                                  | Rewrite the positioning; a relaunch with the same framing fails identically |
| Clicks fine, stars/clones low        | The README lost the ten-second read                         | Restructure the top of the README, add the demo                             |
| Clones fine, downloads/retention low | Install or first-run friction                               | Re-run the cold-run protocol; fix, then release                             |
| Everything fine, no discussion       | The project is understood and unremarkable to that audience | Wrong channel or differentiation is genuinely thin - decide which honestly  |
| Spike then zero on every metric      | Novelty-only interest                                       | Nothing to fix in the launch; the next release cycle is the real test       |

Only "wrong channel" justifies relaunching elsewhere. The rest justify fixing the artifact first, because a relaunch spends the novelty budget a second time.

## What not to report

- Stars as adoption. They are bookmarks; correlation with usage is weak.
- Launch-window traffic presented as a sustained baseline.
- Impressions or "reach" from platforms that count a scroll-past as a view.
- Any number bought, traded or solicited - beyond the ethics, platforms detect it, and an audit later costs far more than the flat week it papered over.

# Pre-launch timeline

Everything that has to happen before launch day, in the order the lead times force. The stages are sized by how long each one takes to undo, not by how much work it is: a rename is the most expensive mistake on this page, so it goes first.

## 8+ weeks out: Name and license

### Trademark clearance

Search for phonetic, visual and conceptual similarity - not just identical matches - across every jurisdiction the project will be used in. Then secure the domain, the code-host organization and the social handles before the name appears anywhere public. The principle behind that order is "secure first, release later": once a name is visible, changing it costs the URL, the accumulated search history and the announcement itself.

Two facts make this non-optional for open source specifically:

- Free distribution is still use in commerce. Distributing software over the internet at no charge can create or infringe trademark rights (_Planetary Motion v. Techsplosion_, 261 F.3d 1188). "Nobody paid us" is not a defense; that is why projects receive cease-and-desist letters and rename after they are already popular.
- Visibility accelerates the problem rather than protecting you. The OpenClaw/"Clawdbot" episode is the recent cautionary case: rapid repository visibility, then legal pressure, then a forced rename.

Any colorable conflict is a rename before launch. It is never a risk to accept and fix afterwards.

### License, CLA/DCO, foundation path

Settle these in the same pass, because each one is harder to change after adoption than before it:

- The license itself. Relicensing an established project reliably triggers a fork: HashiCorp's move from MPL 2.0 to BSL 1.1 in August 2023 produced the OpenTF manifesto, endorsed by over 140 companies and 700+ individuals, and OpenTofu launched under the Linux Foundation a month later.
- CLA versus DCO. DCO sign-off is the CNCF default; CLAs are project-elected. Decide before the first external pull request arrives, not after.
- Trademark ownership, if a foundation is on the roadmap. CNCF requires that a project's trademark and logo assets transfer to the Linux Foundation - a stronger requirement than the license. The reason, as Linkerd's creator put it during the Synadia/NATS dispute: a permissive license lets anyone ship a relicensed fork, but trademark ownership means the one thing they cannot do is call it by the original name.

Use `samber/developer-relations-skills@oss-license-strategy` for the license decision itself; this page only fixes when it has to be done.

## 3 weeks out: Press

Only relevant if press coverage is part of the goal. Supabase's own figure is the anchor: press "needs to be organized up to 3 weeks before you plan to Launch". General PR guidance is more permissive for smaller launches (24–48 hours for a standard announcement, one to two weeks for a large enterprise one) - treat that split as practitioner convention, not a rule.

Outlets that actually cover open-source launches:

- TechCrunch
- The New Stack
- The Register
- TechTarget
- SDxCentral
- The relevant category trades
- The Linux Foundation/CNCF newsroom, for foundation-backed news

Embargo, exclusive and briefing mechanics (including the fact that a public repository leaks its own news through tags, registry publishes and merged pull requests) belong to `samber/developer-relations-skills@tech-press-relations`. Do not reinvent them here.

## 1–2 weeks out: War room and readiness

### Stand up the war room

Generalized from GitLab's public Developer Advocacy handbook, the only complete launch-day playbook published openly:

| Element               | What it means concretely                                                                                                                                            |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DRI per channel       | One named person owns each of: the anchor thread, each secondary community, social, chat, and incoming issues. "The team is watching" is not an owner.              |
| Response cadence      | A stated interval, not "as needed". GitLab reviews its mention channel 1–2 times daily in steady state; a launch day needs continuous coverage for the first hours. |
| Escalation path       | When the responder cannot answer, they pull in the engineer who can, by name, in the thread. Agree who those people are and that they are reachable.                |
| Speaking authority    | Who may commit to a roadmap item, a date, or a licensing statement in public. Everyone else defers.                                                                 |
| Shared tracking       | One place where handled items get marked handled, so two people do not answer the same comment differently.                                                         |
| Pre-drafted templates | Answers to the three or four objections you already know are coming, written before launch day rather than under load.                                              |

Note the editing constraint that shapes response discipline on Hacker News: the window to edit a comment closes after two hours. Read before posting.

### Security contact

Publish `SECURITY.md` with a private reporting channel and confirm someone is actually watching it. Coordinated disclosure only works if the path exists before the first report - a vulnerability surfacing in a public launch thread has to move private immediately, and it cannot if there is nowhere to move it to.

The runbook once a report is valid:

1. Open a private advisory.
2. Add the reporter as a collaborator.
3. Develop and test the patch on a private branch.
4. Request a CVE through a numbering authority.
5. Credit the reporter on publication.

### Freeze

Freeze the default branch and production changes for launch day. A mid-launch refactor breaks the thing strangers are cloning right now.

## Launch day and after

The hour-by-hour run of show lives in the launch-day runbook; this page stops at the freeze.

Decide the shape before you get here. A single project with one story wants a Show HN anchor and, optionally, Product Hunt as a secondary. A company-backed project with at least three announceable items and a conference on the calendar can carry a multi-day caravan instead.

Supabase's Launch Week and Cloudflare's Innovation Weeks are the two documented models. Cloudflare's origin explains why the format exists at all: rather than one annual conference, it deconstructed the user conference "down to one of its most critical elements, which is, we'll make a bunch of product announcements around… a particular theme", and found the published schedule itself acted as a forcing function on the teams.

## Common sequencing mistakes

- Running trademark clearance after the repository is public, because the name "felt available".
- Treating the license as a launch-week decision. It is an 8-week decision; the announcement has to explain it, and any company-backed project has to state the commercial boundary in the post itself.
- Booking press before the readiness gate passes, which turns a slipped blocker into a broken embargo.
- Writing `SECURITY.md` in response to the first report rather than before the first reader.
- Assigning channels to a team rather than to named people, then discovering at T+2h that everyone assumed someone else had Reddit.

# Launch readiness checklist

Score the repository before a date exists. Blockers postpone the launch; boosters change conversion, never the date.

The blocker list below is Karl Fogel's pre-announcement inventory from _Producing Open Source Software_ (producingoss.com), reordered by what a launch actually breaks on. Fogel's own framing of why presentation counts: "the very first thing a visitor learns about a project is what its home page looks like." A visitor reads polish as a proxy for whether the project will still exist next year; abandonment risk is what they are really screening for.

## Blockers

| #   | Check                | Passes when                                                                                                                                                                                                                                                                           |
| --- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0   | Name                 | Trademark clearance done (phonetic, visual, conceptual, all target jurisdictions), and the domain, code-host org and handles are secured. This one carries an 8-week lead time, so it gates the date rather than the gate.                                                            |
| 1   | License              | An OSI-recognized license file is present, matches what the README claims, and dependencies allow it. Company projects also state the ownership/CLA position.                                                                                                                         |
| 2   | Install              | The documented install command works on a clean machine for every OS and runtime version the README claims.                                                                                                                                                                           |
| 3   | First success        | One runnable example produces visible output within the claimed time budget, using only what the README provides.                                                                                                                                                                     |
| 4   | Ten-second read      | The top of the README answers what it is, who it is for, and what it replaces.                                                                                                                                                                                                        |
| 5   | Reachability         | Repository is public, issues enabled, and a maintainer is available on launch day and the day after.                                                                                                                                                                                  |
| 6   | Distribution         | Published to the ecosystem registry, or the install path genuinely does not need one. Tag and release notes exist.                                                                                                                                                                    |
| 7   | Hygiene              | No keys, tokens, internal hostnames, customer data or proprietary code anywhere in the history - not only in the current tree.                                                                                                                                                        |
| 8   | Claims               | Every claim in the announcement draft is defensible: benchmarks reproducible, "used in production" true, adoption numbers real.                                                                                                                                                       |
| 9   | Security contact     | `SECURITY.md` exists, names a private reporting channel, and someone is watching it. A vulnerability posted in the launch thread has to move private within minutes, and it cannot if there is nowhere to move it.                                                                    |
| 10  | Contribution channel | Issue tracker open, communication channel named, and basic contributor guidance present. Fogel's inventory treats these as pre-announcement items, not post-launch cleanup: without a public place to talk, people contact the maintainer directly and the load never becomes shared. |

## Boosters

Boosters raise conversion; none is worth delaying the date for. Listed by lift per pre-launch hour, best ratio first - not cheapest first.

| #   | Booster                                                                | Effort         | Lift                                                                                                        |
| --- | ---------------------------------------------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------- |
| 1   | Social preview image, repository description, 5-10 topics              | near-zero      | Whether the link previews at all and whether the repository is findable by topic                            |
| 2   | Demo GIF, short video, or hosted playground                            | an hour or two | Highest lift per hour for individual adoption - shows output instead of claiming it                         |
| 3   | Comparison section naming real alternatives with honest trade-offs     | an hour        | Highest lift for company adoption; pre-answers the thread's highest-value question                          |
| 4   | Security policy, release cadence statement, maintainer/funding model   | an hour        | The pages an internal approver blocks on; without them a team-shaped launch stalls                          |
| 5   | CONTRIBUTING.md, issue templates, a few small `good first issue` items | an hour        | Opens the contributor funnel and doubles as the triage guard if the launch over-performs                    |
| 6   | Benchmarks with hardware, versions, method and a reproduction command  | a day or more  | Strong credibility and the one booster that can backfire - an unreproducible number becomes the top comment |
| 7   | Long-form "why this exists" write-up                                   | a week         | Durable: carries week two and still delivers readers a year out                                             |
| 8   | Documentation site                                                     | a week or more | Only once the surface outgrows one README; below that, a second place to go stale                           |

The axes disagree:

- efficiency: `1 > 2 > 3 > 4 > 5 > 6 > 7 > 8`
- effort, heaviest first: `8 > 7 > 6 > 2 > 3 == 4 == 5 > 1`

Rows 3, 4 and 5 tie on effort because each is one sitting spent writing a page from facts the maintainer already holds, and none of them scales with the size of the project.

**Default: take rows 1-3.** Add row 4 when the target adopter is a company, row 5 when contributors are the launch goal.

Rows 6-8 are what the ratio starves: durable, beaten every round. Promote them on a named condition:

- Benchmarks only when a performance claim is already in the announcement draft (blocker 8 then makes them mandatory, not optional).
- The write-up only when differentiation is an argument rather than a demo.
- The docs site only when the README has outgrown itself.

Delete the rest rather than parking them at the bottom - a booster listed and unbuilt reappears as work on launch morning.

## Cold-run protocol

The gate is empirical. Opinions about README quality do not settle it; a stranger's session does.

1. Pick a reader who has never used the project and is representative of the target adopter.
2. Give them a clean environment and the repository URL. Nothing else.
3. Forbid maintainer help. The maintainer watches silently and takes notes.
4. Record every hesitation: a command retyped, a version guessed, a missing prerequisite, a page they had to search for.
5. Stop at first success or at the time budget, whichever comes first.
6. Fix every hesitation, then re-run with a different reader.

Pass condition: an unaided cold reader reaches first success inside the claimed budget, with zero blocking hesitations.

When no human reader is available and you can execute commands, run the protocol yourself in a fresh directory:

- Follow the README literally.
- Never use knowledge of the codebase.
- Treat any moment you had to inspect source as a hesitation.

Say clearly in the plan that this substitute was used - an agent reads more charitably than a tired developer at 9 p.m.

## Verdict shapes

- **Go** - all blockers pass, boosters chosen, date set.
- **Go with reduced scope** - a blocker touches only part of the claim surface. Cut that claim (drop the benchmark, drop the Windows support statement) and launch the rest.
- **Not ready** - list the open blockers, the estimated work, and the earliest honest date. Say it plainly; a postponed launch costs a week, a broken one costs the novelty budget permanently.

---
name: oss-launch
description: Plans and runs an open-source project launch end to end - name and license clearance, the readiness gate, positioning and one-liner, channel sequencing, the launch-day war room, star-velocity and GitHub Trending mechanics, and post-launch measurement. Use whenever someone is about to release, announce, open-source or "Show HN" a repository, asks how to reach GitHub Trending, wants the first real users or stars for a new library, is planning a Product Hunt post or a multi-day launch week, or asks why a launch fell flat (even if they only say they are pushing a repo public). Covers individual-developer and company adoption. Not ongoing distribution afterwards - use samber/developer-relations-skills@oss-distribution-strategy instead.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.3"
---

# OSS Launch

You are an open-source launch strategist. You take a repository that is about to become public knowledge, clear the legal and readiness gates, sharpen how it introduces itself, sequence the announcement, run the launch day, and measure what actually happened.

A launch spends a one-time budget: novelty. The same project can only be new once on each channel, so attention that arrives at a broken install command or an unreadable README is not deferred, it is gone. Everything below serves that constraint.

Ground the work in Karl Fogel's _Producing Open Source Software_ (producingoss.com) - the closest thing the field has to an established, citable launch method. Three of its rules shape this skill:

- **Look around first.** "Always look around to see if there's an existing project that does what you want." If one exists, the honest move may be contributing there; either way the announcement must answer "why not that one".
- **A mission statement is "concrete, limiting, and above all, short."** _Limiting_ is the word people drop: a good one-liner says what the project will not do.
- **"Waiting Just Creates an Exposure Event."** Develop in the open and announce once presentable, rather than opening a private repository and its whole backlog of flaws on the same day.

Fogel's pre-announcement inventory is the source behind the readiness gate in Step 2. Do not substitute a consumer go-to-market model (five-phase alpha→beta→GA, owned/rented/borrowed channels) - those are built for a voting marketplace and say nothing about repository readiness, licensing or credibility.

## Interview

Ask one question at a time, in this order, with multiple-choice options wherever you can. Stop as soon as you can name the audience, the anchor channel and the goal - infer the rest and confirm later.

**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What is the project, and what does someone do with it in their first five minutes?
2. Who is the target adopter: individual developers picking tools for themselves, or engineers who must get a project approved inside a company? (Both is valid - it changes what you ship, not whether you launch.)
3. What does this replace or compete with today, including "writing it by hand"?
4. What is the launch goal: users, contributors, hiring signal, funnel for a commercial product, or credibility for a company brand?
5. Is a company behind the project, and is anything closed, paid or planned to become paid?
6. What is the current state: name clearance, license, README, install path, docs, demo, tests, `SECURITY.md`, registry publication?
7. Which communities does the maintainer already participate in, with an account that has history?
8. By what date must the result exist - is a date fixed by something external (conference, funding announcement, competitor), or can it move?
9. Is the goal a one-off win inside the launch window (a spike, a hiring signal, a fundraising datapoint) or a compounding asset that still delivers adopters in six months?
10. What is the effort ceiling: how many maintainer-hours exist on launch day and the week after, who else can own a channel, and what will not be touched at all?
11. What has already been published - earlier posts, a private beta, an internal announcement?

Questions 8-10 set the channel ranking in Step 5, so ask them before proposing anything. Each answer moves the plan:

- A fixed near date deletes the long-form write-up from the launch week.
- A compounding mandate promotes it above the secondary communities.
- A ceiling under about a day collapses the plan to registry plus anchor post and nothing else.

Record the answers before planning. If your harness has persistent memory, store them there: the same facts drive later releases, and a project's second launch should not start from zero.

## Step 1 - Clear the name and the license

Do this before anything else: both are rename-triggers, not fixable defects.

Run a trademark clearance search covering phonetic, visual and conceptual similarity across every target jurisdiction - not just identical matches - and secure the domain, code-host organization and social handles before the name appears anywhere public ("secure first, release later"). Giving the software away is no defense: distributing it over the internet at no charge can itself constitute use in commerce for trademark purposes (_Planetary Motion v. Techsplosion_, 261 F.3d 1188), which is why projects receive cease-and-desist letters and rename after they are already visible.

Treat any colorable conflict as a rename before launch, never a risk to carry. Settle the license and the CLA-vs-DCO position in the same pass; relicensing an adopted project reliably triggers a community fork. The precedents are in the timeline reference.

Full timeline, precedents and the press/embargo stage: [references/pre-launch-timeline.md](./references/pre-launch-timeline.md).

## Step 2 - Run the readiness gate

Score the repository against [references/readiness-checklist.md](./references/readiness-checklist.md), which separates blockers from boosters.

Apply the threshold literally: **every blocker must pass before a date is set**. One open blocker moves the launch; boosters never move it. When an external date is fixed and blockers are open, say so plainly and propose the smallest scope that can pass (for example, announce the repository without the benchmark claims).

Decide the gate by a cold run, not by opinion:

- Someone who has never used the project follows only the README, on a clean environment, without asking the maintainer anything.
- If you can execute commands, do the cold run yourself in a fresh directory and log every point where you had to guess.
- Each guess is a defect; re-run after fixes.

Pass condition: a cold reader reaches first success unaided, inside the time budget the project claims. Treat "five minutes for a library, fifteen for a service" as a self-set baseline, not an industry standard - replace it with whatever budget the project's own README promises.

## Step 3 - Sharpen the positioning

Write the one-liner as `<name> is a <category> for <audience> that <capability the alternatives lack>`. Category first - readers file a project before they evaluate it, and a project that refuses a category gets filed as marketing.

Then answer the three questions a developer asks in ten seconds:

- What is it?
- Do I have this problem?
- Why not the thing I already use?

Draft the "why not X" answer explicitly, naming real alternatives and where they are better. An announcement that dodges it loses to the incumbent by default, because keeping the incumbent costs nothing.

Hacker News' own guidance to launching founders is the tightest statement of the register a developer audience rewards: "Don't write in a marketing, sales, or PR style… Talk to readers as peers… Don't use superlatives (fastest, biggest, first, best). Modest language is stronger. Be humble."

Check the draft against the credibility codes in [references/announcement-examples.md](./references/announcement-examples.md). The short version:

- Name alternatives fairly.
- Publish limitations before anyone finds them.
- Give benchmarks a method and a reproduction command, or drop the numbers.
- Link to code instead of describing it.
- State maturity honestly.
- Disclose the commercial boundary up front if a company is behind the project.

Write in the maintainer's voice: first person, why it exists, what was hard, what got cut. Pass any marketing-written draft through your preferred humanizer skill before publishing - an announcement that reads like a press release signals that no engineer was allowed near it.

## Step 4 - Choose the launch shape

Two shapes, one decision:

- **Single spike.** One project, one big story: a Show HN as the anchor, Product Hunt as an optional secondary. The default, and the right answer for almost every independent project.
- **Launch caravan.** A multi-day or multi-week sequence that re-markets one story to successive audiences. Supabase's Launch Week and Cloudflare's Innovation Weeks are the two documented models; both work because, as Supabase puts it, "you can launch a new feature many times over and always manage to reach people who either forgot, ignored, or just plain missed it the first few times."

Ranked by outcome per maintainer-hour: **single spike > caravan** below the threshold that follows. A caravan multiplies the week's hours by the number of days, and pays that back only when every day carries its own real story.

Run a caravan only past this threshold (one this skill sets, not a published rule): **at least three announceable items, a conference or fixed date on the calendar**, and staff to hold a named owner per day. Below that, a caravan dilutes into several ignored posts.

Supabase deliberately does not hold features back for its Launch Week - it ships them early and re-announces them with full write-ups later. So the model needs volume, not secrecy.

The shape decides what Step 5 sequences: a spike fires one anchor and its amplifiers once; a caravan repeats that firing pattern each day with a fresh story.

## Step 5 - Sequence the channels

Pick **one anchor channel** (where this audience already evaluates new projects) and treat everything else as amplification pointing back to it. Four simultaneous "primary" posts produce four dead threads, because every discussion surface ranks on early engagement density.

Then spend the week's hours in this order - highest outcome per maintainer-hour first, not cheapest first.

| #   | Channel                                                                       | Launch-week effort                                                            | What it buys                                                                                                           |
| --- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| 1   | Registry publish, release tag, repository description, topics, social preview | near-zero (minutes on assets that already exist)                              | Whether every other row converts: a failing install command wastes all the traffic the plan produces                   |
| 2   | Anchor post, first comment, and staying in the thread                         | most of a day, nearly all of it presence rather than writing                  | Most of the launch outcome and the one row that cannot be retried - a thread fumbled at hour one is dead by hour three |
| 3   | Secondary communities, staggered, context rewritten each time                 | an hour per community, and it does not compress (a pasted blurb gets removed) | The ecosystem audiences the anchor misses                                                                              |
| 4   | Maintainer's own accounts                                                     | near-zero (one post, already drafted)                                         | The audience the maintainer already has; nothing without one                                                           |
| 5   | Newsletters and curated lists                                                 | an hour per outlet, and most publish after the window closes                  | Long-tail arrivals at a curator's discretion, days later                                                               |
| 6   | Long-form write-up (architecture, war story, benchmark method)                | a week, in the week with the fewest spare hours                               | Durable: still delivers readers a year out                                                                             |

The axes disagree, so read them separately:

- efficiency: `registry > anchor > secondary > own social > newsletters > write-up`
- launch-week effort, heaviest first: `write-up > anchor > secondary > newsletters > registry == own social`
- reach inside the window: `anchor > secondary > own social > newsletters > write-up > registry`
- durability past day 30: `write-up > registry > newsletters > anchor > secondary > own social`
- compliance cost: `secondary > anchor > own social` (the other three carry none)

Registry work ranks first on efficiency and last on reach; that contradiction is the point: nobody browses a registry on launch day, but every arrival the anchor sends lands there. The one tie is genuine - registry publish and the maintainer's own post are both minutes spent shipping something already written.

Compliance cost is a moderator's judgement, not a fee. Secondary communities are read by humans who check post history and can remove the post and ban the account; the anchor carries flag and per-domain penalties that are invisible from outside and outlive the launch.

**Default: rows 1-3 are the launch.** A maintainer with six hours does those and stops. Add row 4 when there is a real audience, row 5 when someone else can own the submissions, and row 6 only under the condition below.

**Delete what the answers rule out rather than demoting it.** A maintainer with no existing audience deletes row 4 rather than ranking it last, because a row parked at the bottom reappears as launch-day scope. The same applies to row 5 with no second person, and to row 6 against a fixed near date.

**What this order starves: the long-form write-up.** The most durable asset on the page loses every round, because it costs a week in the week with the fewest hours and delivers nothing before the thread is over.

Promote it above rows 3-5 when Interview questions 8-10 say the goal is compounding rather than a spike, when the differentiation is an argument rather than a demo (a new algorithm, a contrarian design decision, a migration story), or when the date can move. Then write it first and let it carry week two.

This ordering is a default, not a law. It shifts with context and with who executes it, so re-rank it against what you already know:

- An existing newsletter or conference talk promotes row 4 above row 3.
- A category with one dominant curated list promotes row 5 into the launch week.
- A maintainer who writes quickly changes what a week of write-up costs.

Efficiency order is not firing order. This ranking says where the hours go; the clock in [references/channel-playbook.md](./references/channel-playbook.md) says when each fires, and that one is fixed by mechanics.

Every link must resolve before the anchor post exists. Read that page before drafting any post - it covers:

- Per-channel norms.
- Title rules.
- The Hacker News versus Product Hunt split.
- What gets a post flagged.

Build different assets for the two adopter types; a launch that serves only one produces the wrong kind of win.

- Individual adoption makes the trial the pitch: time-to-first-success, a demo that shows output, zero-config defaults.
- Company adoption needs pages the evaluator can forward to an approver: license compatibility, maintenance guarantees, security posture, release cadence, support.

Ship neither set and the launch produces stars and no deployments. The full split is the adoption table in the playbook.

If press matters, start roughly three weeks out; Supabase's own figure is that "press… needs to be organized up to 3 weeks before you plan to Launch". Embargo and exclusive mechanics belong to `samber/developer-relations-skills@tech-press-relations`, not here.

The ranking above covers the launch window only, where the scarce resource is hours in one week and the attention is one-shot. Channels that keep running afterwards are costed differently - hours per month against a decay profile. Hand rows 5 and 6 to `samber/developer-relations-skills@oss-distribution-strategy` once the window closes instead of re-costing them here.

## Step 6 - Stand up the war room and run the day

Build the run of show from [references/launch-day-runbook.md](./references/launch-day-runbook.md):

- Pre-flight checks.
- The posting hour, chosen from the anchor audience's geography.
- The first comment that supplies context.
- The response rotation.
- Who watches what.

Staff it on GitLab's model, the only complete openly published launch-day playbook. Four pieces generalize to any project:

- One named DRI per channel.
- A stated response cadence rather than "as needed".
- An escalation path to the engineer who can answer.
- An explicit rule on who may speak with authority.

Its tone rule is the whole posture in three words: "conveying without convincing".

Two rules carry most of the outcome:

- Post the maintainer's own top-level comment immediately: who you are, why it exists, what is interesting under the hood, what it does not do yet.
- Stay in the thread for several hours and answer everything, including hostile comments, without defensiveness.

Availability is the only variable you fully control after publishing.

Keep a triage lane open in parallel: a broken install path found in hour one is worth fixing and shipping the same hour, and saying so in the thread converts critics faster than any argument.

One kind of comment bypasses the rotation entirely: a security report, or anything shaped like one.

1. Stop discussing it publicly.
2. Point the reporter at `SECURITY.md`.
3. Open a private advisory.
4. Patch on a private branch.
5. Publish the advisory crediting them.

Coordinated disclosure only works if that contact path exists before launch day; that is why it is a blocker in Step 2, not a reaction. The full pipeline - policy, embargo, identifiers, release order - is samber/developer-relations-skills@oss-security-disclosure.

## Step 7 - Concentrate velocity, never manufacture it

Discovery surfaces sample flow, not stock. GitHub Trending ranks stars gained inside a window (today / this week / this month) and filters by language, so a project's language page is a far smaller pool than the global page and the realistic target for a first launch. The selection formula is unpublished - treat any reverse-engineered version as folklore and never promise a trending placement.

That is why concentration beats spreading: the same effort compressed into one day produces the slope these surfaces reward, while a week of drip produces none.

The other half of the same mechanic is a hard boundary: never solicit votes, stars or comments, and never coordinate them. Hacker News states that asking for upvotes gets submissions, accounts and whole domains penalized, and Product Hunt weights votes for authenticity rather than counting them raw.

The penalties are invisible from outside, so a team can run the play and never learn why the post died. Asking colleagues to "go look" is fine; asking anyone to upvote or star is not. Say the difference out loud to the team before launch day.

## Step 8 - Measure honestly

Capture the baseline the evening before:

- Stars, unique visitors and cloners.
- Registry downloads for the last full week.
- Docs sessions.
- Open issues, contributor count and referrers.

Traffic panels keep only a short rolling window, so an uncaptured baseline is unrecoverable.

Then read three windows (a conventional split, not a standard) and let the day-30 numbers decide:

- Day 1 measures attention.
- Day 7 measures trial.
- Day 30 measures adoption.

Metric definitions, target-setting method and the funnel-stage diagnosis table are in [references/measurement-plan.md](./references/measurement-plan.md).

Treat stars as the loudest and least meaningful signal. An issue opened by a stranger who clearly read the docs outranks a hundred of them; the pairing to watch is star growth against unique cloners and downloads. A spike in the first with no movement in the others means the announcement travelled, and the project did not.

Set targets as multiples of the project's own pre-launch baseline. The absolute numbers that circulate for launch-day stars per hour, front-page thresholds or day-1 download lift trace back to single anecdotes and launch-consultancy claims; say so rather than adopting one as a target.

## Invocation examples

- _"We're open-sourcing our internal feature-flag service next month. Can you plan the launch?"_ → Full interview, then the launch plan below, with Step 1 flagged as urgent because a month is inside the trademark-clearance window.
- _"Review my Show HN title and first comment before I post."_ → Skip to Steps 3 and 6; rewrite both against the credibility codes and return a weak/strong diff.
- _"How do I get on GitHub Trending with a Rust crate?"_ → Step 7 plus Step 5; name the language page as the realistic target and refuse to promise placement.
- _"Our launch got 40 stars and died. What went wrong?"_ → Skip to Step 8; run the funnel-stage diagnosis before proposing any relaunch.
- _"We have five features shipping and a conference keynote in six weeks."_ → Step 4 caravan branch; produce a per-day sequence with a named owner per day.

## Expected output

Produce a launch plan the maintainer can execute without you:

```markdown
# Launch plan - <project>

## Verdict go / go with reduced scope / not ready (blockers listed)

## Clearance name, trademark, license, CLA/DCO status

## Positioning one-liner, why-not-X, three claims we can defend

## Audience individual / company adoption, and the assets each needs

## Shape single spike or caravan, with the reason

## Channels anchor + amplifiers ranked by outcome per hour, then the firing clock, a DRI each, and the rows deleted with the reason

## Run of show hour-by-hour for launch day, including the first comment

## Measurement baseline snapshot, day-1/7/30 targets, tracking method

## Risks what could flag, break or overwhelm us, and the response
```

Present it section by section and get agreement on each before moving to the next - a positioning error propagates into every post if you write them all first.

## Common failure modes

- **Announcing before the name is cleared.** A rename after public visibility costs the URL, the search history and the announcement itself. Clear it in Step 1 or accept that risk explicitly.
- **Launching to a fixed external date with blockers open.** Reduce scope instead; broken install commands become the top comment and outrank the project in search for years.
- **A flat launch read as bad luck.** Localize it by funnel stage before relaunching anywhere - see the diagnosis table in the measurement reference. Only "wrong channel" justifies a relaunch; the rest justify fixing the artifact.
- **Reposting a dead thread immediately.** Aggregators bury duplicates. Hacker News allows a small number of reposts only when a story "has not had significant attention in the last year or so" and separately runs a second-chance pool moderators use to re-surface good submissions that missed. Mailing them once is the sanctioned recovery path; resubmitting is not.
- **Nobody home.** A launch posted before a meeting-heavy day dies in the comments. Move it.
- **Winning the wrong audience.** Individual-developer channels for an enterprise-shaped project produce applause and no adoption; check the day-30 numbers, not the day-1 ones.
- **Burnout in week one.** An over-performing launch lands on a team of one or two, already fragile. Tidelift's maintainer surveys (2020, 2022) put burnout at 46% of professional maintainers, rising to 58% on widely-used projects - with almost 60% having quit or considered quitting a project. Agree the triage trigger (issue templates, thread locks, a temporary contribution freeze) and a response SLA you can hold before launch day, not while drowning.

## References

- [references/pre-launch-timeline.md](./references/pre-launch-timeline.md) - 8-weeks-out staged sequence: trademark, license, press, war room, freeze.
- [references/readiness-checklist.md](./references/readiness-checklist.md) - blockers, boosters, cold-run protocol.
- [references/channel-playbook.md](./references/channel-playbook.md) - per-channel norms, HN vs Product Hunt, title rules, what gets flagged.
- [references/launch-day-runbook.md](./references/launch-day-runbook.md) - hour-by-hour run of show, DRI model, first-comment and response patterns.
- [references/announcement-examples.md](./references/announcement-examples.md) - weak vs strong one-liners, titles, comparison tables, first comments.
- [references/measurement-plan.md](./references/measurement-plan.md) - baseline capture, day-1/7/30 metrics, flat-launch diagnosis.

Related skills in this collection:

- `samber/developer-relations-skills@readme-optimization` - the README the launch points at.
- `samber/developer-relations-skills@developer-quickstart-guide` - the first-success path the gate tests.
- `samber/developer-relations-skills@oss-license-strategy` - the license and CLA/DCO decision Step 1 assumes is settled.
- `samber/developer-relations-skills@tech-press-relations` - embargo and briefing mechanics.
- `samber/developer-relations-skills@oss-distribution-strategy` - the channel mix after the launch window closes.
- `samber/developer-relations-skills@open-source-company-strategy` - the boundary decision on what gets open-sourced, settled before this launch is planned.