samber/developer-relations-skills已通过检查
SKILL DETAIL
developer-community-launch
samber/developer-relations-skills/developer-community-launch
Decides whether, where and when to launch a developer community, then plans its seeding and first 90 days - venue selection, founding-member seeding, go/no-go criteria, the cheaper no-community alternatives, and shutdown criteria. Use whenever someone asks whether to start a Discord, Slack or forum for their users, which community platform to pick, how to launch or seed a developer community from zero, or how to reach critical mass - even if they only say "we should have a Discord". Do NOT use for a community that already exists; measurement is samber/developer-relations-skills@developer-community-health and moderation is samber/developer-relations-skills@developer-community-moderation.
安装量 · 425查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill developer-community-launch
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "developer-community-launch",
"evals": [
{
"id": 1,
"prompt": "Our CTO came back from a conference convinced we need a Discord. We're Kestrel Metrics, an API observability tool, about 40 paying customers. Our support inbox gets maybe 6 tickets a month and honestly none of them repeat, they're all one-off integration questions. Our two biggest competitors both run Discords with thousands of members. There's an ecosystem Discord for the monitoring space where I know at least three of our users hang out already. Nobody on the team owns this - marketing said they'd keep an eye on it. Can you put together what channels we'd need and a rough launch plan?",
"expected_output": "A do-not-launch verdict with the five readiness gates scored and evidenced, a recommendation to participate in the existing ecosystem Discord instead, and an observable re-decision trigger. No channel list.",
"files": [],
"expectations": [
"Returns a do-not-launch verdict rather than a launch plan",
"Scores all five readiness gates by name - demand, owner, purpose, venue vacuum, seed supply - with a pass, weak or fail mark on each",
"Marks the demand gate as failing and cites the 6 tickets a month with no repeats as the evidence",
"Marks the venue-vacuum gate as failing because the monitoring ecosystem Discord already hosts part of this audience",
"Marks the owner gate as failing and treats \"marketing said they'd keep an eye on it\" as an ownership gap rather than a staffing detail to settle later",
"States explicitly that competitors having a Discord is not accepted as evidence of demand",
"Notes that the 40 named customers are what the seed-supply gate has to work with, and that coverage rather than headcount is what it tests",
"Recommends participating in the existing ecosystem Discord instead of opening a new venue",
"Produces no channel list or category tree for a new Discord",
"Names an observable re-decision trigger such as a repeat-question volume or users starting to answer each other, rather than a date to revisit",
"States the verdict rule applied: three or fewer gates passing means do not launch"
]
},
{
"id": 2,
"prompt": "Orbwright makes a distributed task queue library, commercial license, roughly 900 paying teams. We've already signed up for Slack and I've got the workspace created. Context: we get 20-30 configuration questions a month by email, about a third are duplicates, and four of our users regularly answer each other in our GitHub issues. Dario owns this with 6 hours a week protected indefinitely, but he batches it - he's heads-down on the engine most of the week and can realistically look at it two or three afternoons. The answers we give stay correct for a year or more since the config surface barely changes, and honestly a big reason we want this is that people google our error strings and land nowhere right now. We have 60 users we could invite by name across four topic areas and three continents. Help us plan the launch.",
"expected_output": "A launch verdict, Slack treated as a hypothesis and the owned real-time chat class deleted with reopen triggers recorded, an owned async forum recommended with the class named before any vendor, and the vendor figures flagged for re-verification.",
"files": [],
"expectations": [
"Treats the already-chosen Slack as a hypothesis and runs the readiness gates before discussing the platform",
"Scores all five gates and returns a launch verdict",
"Deletes owned real-time chat as a venue class rather than demoting it in a ranking",
"Gives at least two distinct reasons real-time chat is deleted here: its archive is not indexed, and the owner cannot be present most days",
"Records a reopen trigger for the deleted real-time chat class on the venue line of the brief",
"Recommends an owned async forum as the surviving venue class",
"Names the venue class before naming any vendor",
"States the venue ranking out loud rather than leaving it implied by the order things are listed in",
"Notes that Slack's free plan retains only 90 days of message history, which removes the searchable archive the error-string search goal depends on",
"Notes that per-seat pricing makes an open community structurally more expensive as it grows, unlike per-instance forum pricing",
"Flags that vendor pricing, retention and export claims must be re-verified on the vendor's own page before the recommendation is final",
"Does not recommend running Slack and a forum as two primary venues at once"
]
},
{
"id": 3,
"prompt": "I'm the founder at Fernbrook, we make a schema-migration CLI, about 2,400 weekly active installs and 150 paying teams. I want to open a community and I want it to do three things: take support load off me, give us a steady stream of roadmap input from the people who actually run migrations in production, and build up a group of vocal users who bring us signups. Demand is there - I get the same four questions constantly by DM and two users already answer each other in our issues. I can give it 8 hours a week, no question, and I've got 45 people I could invite tomorrow. Nobody else serves this niche. Let's get going - what platform and what does week one look like?",
"expected_output": "The three goals mapped to SPACES letters, the purpose gate held open until exactly one primary is chosen, the primary converted into a measurable claim, and no venue or channel structure proposed before that.",
"files": [],
"expectations": [
"Names the outcomes using the SPACES vocabulary and maps each of the three stated goals to its letter: Support, Product, and Acquisition and advocacy",
"Refuses to accept all three as co-primary and requires exactly one primary outcome",
"Marks the purpose gate as not passing while the three outcomes remain unranked",
"States that the primary outcome decides the community model, the venue class and the thresholds",
"Attributes the one-objective rule to CMX's SPACES model rather than presenting it as the assistant's own preference",
"Allows secondary outcomes but requires them stated explicitly and ranked below the primary",
"Converts the chosen primary into a measurable claim carrying a number and a timeframe, not a restatement of the goal",
"Does not propose a venue, platform or channel structure before the primary outcome is settled",
"Asks the user to pick the primary rather than silently choosing one for them",
"Notes that if acquisition and advocacy becomes the primary, none of the four named community models (support-driven, product-development, education and enablement, founder-led) applies and the shape has to be designed from the outcome instead"
]
},
{
"id": 4,
"prompt": "Quillstack, we build a feature-flag SDK. Getting ready to open a user forum. Where we stand: 40+ repeat setup questions came in last quarter, a dozen of them duplicates, and users answer each other in our repo already. Priya owns it, 7 hours a week signed off by her manager through next year and beyond. Primary goal is support deflection, we've written it as cutting duplicate setup tickets by half in two quarters. No existing space covers us. On invitees I've got 24 people I can name, though realistically only one of them besides Priya is someone I'd trust to actually answer things, and they're all in Central Europe while about 60% of our installs are in North America and APAC. Marketing wants to lock 4 November for the announcement so they can slot it into the quarterly push. Can you confirm the date and write up the plan?",
"expected_output": "A launch-on-a-delayed-date verdict with seed supply as the weak gate, a written mitigation the date is gated on instead of the calendar, and the opening sequence gated on observed activity.",
"files": [],
"expectations": [
"Returns a launch-on-a-delayed-date verdict rather than confirming 4 November",
"Gates the launch on the mitigation landing rather than on a calendar date",
"Writes the mitigation down as a specific named action, such as recruiting a second reliable answerer and adding time-zone coverage",
"Marks seed supply as the weak gate and the other four as passing",
"States that coverage - one reliable answerer per topic area, and at least two time zones for a global audience - is what the seed-supply gate tests, not headcount",
"Does not treat 24 named invitees as an automatic pass merely because it clears 20",
"Applies the verdict rule for four gates passing with a written mitigation",
"Requires founding members who already behave like contributors or advocates rather than passive newcomers",
"Does not recommend padding the invite list with additional names to hit a number",
"Keeps the opening sequence - founding cohort, invited beta, public announcement - gated on observed activity rather than on the fixed November date"
]
},
{
"id": 5,
"prompt": "Arcmesh here. We opened a Discourse forum for our infrastructure-as-code tool 90 days ago and I need to decide what to do next. We announced it during our keynote at a big conference in month one and got a huge rush - we're at 6,200 members now. Month one was incredible, months two and three feel much flatter but I'm told that's normal. Current numbers: 61% of questions get an answer within 24 hours, 28% of posts are written by someone who isn't on our team, 55% of threads have at least one reply, and our five most active members account for 74% of all engagement. Marketing has budget left and wants to run a paid campaign to push us to 15,000 members this quarter, arguing that more people means more conversation. Thoughts on the plan?",
"expected_output": "A refusal of the promotion plan with the reason, every failing signal named against its threshold, the conference month rejected as a comparison baseline, and the fold-back path offered in order with a named decision owner.",
"files": [],
"expectations": [
"Rejects more promotion or paid acquisition as the response, and gives the reason: more joins into a silent room lowers every ratio",
"Names each day-90 signal that sits below its pass threshold, alongside the threshold it missed",
"Identifies at least four failing signals against the baseline thresholds of over 90% answered within 24 hours, over 50% non-staff posts, over 80% of threads with a reply, and under 50% engagement concentration in the top five members",
"States that the 6,200 member count is a joins counter rather than a health signal",
"Warns against measuring against the conference-driven launch month and requires a trailing baseline instead",
"Names burstiness - the spike-and-decay pattern releases, conferences and media coverage produce - as the reason the launch month is not a valid comparison",
"Flags the 74% top-five engagement concentration as fragility: those five leaving takes the community with them",
"Offers the fold-back path and states its options in order: archive read-only, then merge into the space the audience already uses, then convert to a plain support channel",
"Explains that archiving preserves the answers and their search traffic at near-zero standing effort",
"Recommends re-running the shape and seeding work against the specific failing signals rather than a general effort increase",
"Names a decision owner for the fold-back call",
"Does not propose adding more channels or categories to lift activity"
]
},
{
"id": 6,
"prompt": "Vireo Labs. We've had a Slack for our platform users for about 14 months, 1,100 members. It was lively for the first half year and now it's pretty much dead - a few messages a week, mostly us. Leadership is calling it a failed experiment. I want to relaunch it properly: figure out which numbers we should actually be watching, work out whether it's genuinely dying or just seasonal, and come back with something defensible. Where do we start?",
"expected_output": "A routing call to the community-health skill in owner/repo@skill form, with the reason, and a stop - no gates scored, no venue recommendation, no seeding plan.",
"files": [],
"expectations": [
"Routes the request to the community-health skill instead of running the launch workflow",
"States that this skill does not apply to a community that already exists",
"Stops after the routing call rather than half-running the readiness gates",
"Produces no launch brief, venue recommendation or founding-cohort plan",
"Names the target as samber/developer-relations-skills@developer-community-health, in owner/repo@skill form",
"Distinguishes the one case that would keep the work here: deciding whether to shut the community down",
"Does not read \"relaunch\" as a request to pick a new platform",
"Gives the reason for routing: half-running the workflow on the wrong problem wastes the user's time"
]
},
{
"id": 7,
"prompt": "Palebright, we ship an embedded database. We're two weeks from opening a GitHub Discussions space for our users and my VP wants targets written down before we go. What she's proposed: 2,000 members by day 90, and getting the share of members who never post below 40% - she's seen our beta group where about four in five people just read and thinks that's the main thing to fix. She also wants me to just check in at the end of the quarter and see how it went. Can you turn that into a measurement plan?",
"expected_output": "Both proposed targets rejected with published anchors, replaced by active-member counts and the six day-90 ratio signals labelled by basis, a 48-hour-window response commitment, and day-30 leading indicators.",
"files": [],
"expectations": [
"Rejects the \"below 40% lurkers\" target and states that around 90% of members never posting is the baseline condition, not a launch defect",
"Attributes the 90-9-1 participation-inequality finding to Jakob Nielsen at NN/g rather than presenting it as an unsourced rule of thumb",
"Notes that the beta group's four-in-five read-only share is at or better than that baseline rather than a problem to fix",
"Rejects the 2,000-member target as a joins counter rather than a health signal",
"Sets targets on the number of active members and on ratio signals instead",
"Proposes day-90 pass thresholds covering at least: answered within 24 hours, non-staff share of posts, new members posting within 7 days, monthly active share, threads with at least one reply, and top-five engagement concentration",
"Labels which thresholds are published findings and which are baselines offered as a starting hypothesis to recalibrate",
"Requires the thresholds be written down before launch rather than assessed afterwards, and says why",
"Recommends publishing a response-time commitment and places it inside a 48-hour window",
"Cites the 48-hour responsiveness evidence as a published finding rather than an invented target"
]
},
{
"id": 8,
"prompt": "Northkeep sells a data-pipeline platform to enterprises - 55 customers, contracts between $40k and $300k a year. The people who'd actually use a community are data engineers at those accounts; the people who sign the renewal are VPs of Data who I'm certain would never post anything. A good chunk of our users are at banks and insurers whose security policy flat-out bans pasting code or architecture into anything public. Three of our largest accounts have separately asked us for a dedicated private channel just for their team. Demand is solid - we get the same eight or nine pipeline-tuning questions from different accounts every month, and two customers have swapped notes on a call. Marcus owns it, 10 hours a week. We can name 30 invitees. What should we build?",
"expected_output": "A B2B plan: buyer/user split with a separate buyer signal path, public venue classes deleted with reopen triggers, the private-channel requests refused as community and gated as support, and percentage thresholds adjusted with stated reasoning.",
"files": [],
"expectations": [
"Names the buyer and user split explicitly: the room fills with data engineers while renewal depends on VPs of Data who never post",
"Requires a separate signal path to the buyer rather than assuming community activity reaches them",
"Deletes the rented public space and forge-native discussions as venue classes, because both are public by construction and the bank and insurer users cannot post publicly",
"Treats those as deletions rather than demotions, and records the trigger that would reopen each",
"Does not grant the three requested private per-customer channels as a community feature",
"States that private per-customer channels fragment the community and drift into support contracts",
"Gates any per-customer channel on contract value and staffs it as support rather than as community",
"Adjusts the day-90 percentage thresholds for a deliberately small, high-value room and proposes absolute counts alongside them",
"States the reasoning for that threshold adjustment in the brief instead of silently changing the numbers",
"Expects weekday business-hours activity rather than evenings and weekends",
"Raises data residency, privacy or moderation obligations as a constraint to check before committing to a venue",
"Recommends exactly one primary venue"
]
},
{
"id": 9,
"prompt": "Saltmarsh - we make an open-source workflow engine, and the community decision is already made and signed off, all the readiness boxes are ticked. Here's where the plan stands and I'd like you to sharpen it. Launch day is 3 March: we send to our newsletter, 12,000 subscribers, all at once. I've got 11 channels prepped and named: general, announcements, help, showcase, jobs, random, kubernetes, python, go, contributors, off-topic. And I've sent 40 people a message saying \"hey, we're opening a community, come join!\" Anything obviously missing?",
"expected_output": "The day-one blast replaced by a three-stage sequence gated on observed activity, the channel tree cut to a small surface, the invitation rewritten as a time-boxed personal ask, 5-10 seeded posts shipped with their answers, a ritual from week one, and a published response-time commitment.",
"files": [],
"expectations": [
"Rejects announcing to the 12,000-subscriber newsletter on day one and gives the reason: it spends the single first impression on an empty room",
"Replaces the day-one announcement with a three-stage sequence: founding cohort, then invited beta, then public announcement",
"Gates each transition between stages on observed activity rather than on a calendar date",
"Cuts the 11 planned channels down to a small opening surface",
"States that every empty room signals a dead community, and that rooms get added only when an existing one gets noisy",
"Rewrites the \"come join\" invitation into a personal ask naming why that specific person and what is being asked of them",
"Time-boxes the founding-member commitment, for example to the first quarter, rather than leaving it open-ended",
"Specifies seeding roughly 5-10 posts that model the behaviour wanted",
"Requires the seeded questions to ship with their answers, and gives the reason: an unanswered seeded question teaches newcomers that questions go unanswered here",
"Installs one recurring ritual from week one",
"Publishes a response-time commitment and treats unanswered posts as the primary launch defect",
"Targets the member mix rather than the headcount, requiring contributors and advocates in the founding cohort rather than passive newcomers",
"Checks coverage across the 40 invitees - a reliable answerer per topic area and time-zone spread - rather than accepting the count"
]
},
{
"id": 10,
"prompt": "Duneshift is pre-1.0 developer infrastructure - a runtime for edge functions. We have about 30 design partners and the single thing we need from a community is tight, fast product feedback: we ship breaking changes most weeks and we want to hear within hours when something lands badly. Ines, our founder, is genuinely in the room all day, and we have a named support rota of three people covering Berlin, São Paulo and Singapore so someone is awake basically all the time. Our answers go stale within a few weeks anyway because the API keeps moving, and we have zero interest in search traffic - we're not even indexed yet and don't want to be. All 30 partners are on GitHub and we have a public repo. What venue should we open?",
"expected_output": "Owned real-time chat recommended as a deliberate promotion against the efficiency order, with the ranking stated on multiple axes, the two promotion conditions named, the lost archive accepted explicitly, and the class named before any vendor.",
"files": [],
"expectations": [
"Recommends owned real-time chat as the venue class",
"States the venue-class ranking out loud on more than one axis - efficiency, effort, value, compliance cost - rather than a single blended order",
"Acknowledges that real-time chat sits last on the efficiency ratio and is being promoted here anyway",
"Names the two conditions justifying the promotion: the primary outcome is Product (or Engagement), and continuous presence is genuinely staffed by named people",
"Cites the named three-person rota across Berlin, São Paulo and Singapore as the staffing evidence behind the promotion",
"States that the unindexed archive is an acceptable loss here because the answers go stale within weeks and search traffic is not wanted",
"Does not justify the choice with \"that's where developers are\" or with ambition",
"Notes that real-time chat carries the highest standing-presence cost and the highest compliance cost of the four classes",
"Names the venue class before naming any vendor",
"Maps the design-partner feedback goal to the SPACES letter for Product",
"Recommends one primary venue, giving any second surface a distinct, non-overlapping job"
]
},
{
"id": 11,
"prompt": "Tenvale, we do a static-analysis tool for Rust. I ran the numbers and I don't think we're ready for a community but I still need to bring something back to the exec team. Situation: support volume is 5 tickets a month and nothing repeats, and I've never once seen a user answer another user anywhere. The Rust ecosystem Discord has an active channel that covers our problem space and a handful of our users post there. What we actually want out of this is product direction - concretely, about 10 usable roadmap signals a month. Nils owns it with 4 hours a week and we can name 35 users we'd invite. Budget is basically zero, so give me the cheapest thing we can do instead and I'll sell that.",
"expected_output": "A do-not-launch verdict, the cheapest option explicitly refused in favour of the alternative returning the most evidence per standing hour, the ordering stated out loud, the feedback loop ruled out despite the Product outcome, and an observable re-decision trigger.",
"files": [],
"expectations": [
"Returns a do-not-launch verdict on three of five gates passing",
"Explicitly refuses to pick the cheapest option and states the selection rule: the alternative returning the most evidence per hour of standing presence",
"States the ordering of the alternatives out loud rather than presenting an unranked list",
"Recommends answering publicly where the audience already is, meaning the Rust ecosystem Discord channel, as the primary alternative",
"Explains that answering publicly tests the demand gate and the venue-vacuum gate at the same time",
"Rules out the email or issue-based feedback loop despite the Product outcome, because it is one-to-one by construction and structurally cannot produce peer-conversation evidence",
"Notes that a troubleshooting or FAQ surface is the cheapest standing commitment but barely moves the demand gate",
"Does not promote scheduled office hours here, since seed supply is not the failing gate",
"Emits no compliance-cost axis for these alternatives, or states that none of the five makes the team the host of a space",
"Names an observable re-decision trigger, such as a repeat-question volume or users starting to answer each other, rather than a review date",
"States what evidence each recommended alternative is expected to produce toward the blocked launch decision"
]
}
],
"trigger_queries": [
{
"query": "Should we open a Discord for our API users?",
"should_trigger": true
},
{
"query": "We've decided on Discourse, help us plan the November launch.",
"should_trigger": true
},
{
"query": "How do we get our new community to critical mass?",
"should_trigger": true
},
{
"query": "we should have a Discord",
"should_trigger": true
},
{
"query": "Which platform should we pick for our SDK users, Slack or Discord?",
"should_trigger": true
},
{
"query": "Is it worth starting a forum for our open source project?",
"should_trigger": true
},
{
"query": "How many people do we need lined up before we open the room?",
"should_trigger": true
},
{
"query": "We keep getting the same setup questions by email. Should we start a user community?",
"should_trigger": true
},
{
"query": "Write me a plan for seeding a developer community from zero.",
"should_trigger": true
},
{
"query": "What should the first 90 days look like after we open our community?",
"should_trigger": true
},
{
"query": "Our CEO wants a community and I'm not convinced. How do I decide?",
"should_trigger": true
},
{
"query": "Do we need our own space or should we just hang out in the ecosystem Discord?",
"should_trigger": true
},
{
"query": "Who should we invite first when we open our forum?",
"should_trigger": true
},
{
"query": "How do we avoid a ghost town when we launch our Slack?",
"should_trigger": true
},
{
"query": "GitHub Discussions or Discourse for our project?",
"should_trigger": true
},
{
"query": "What are the go/no-go criteria for starting a user community?",
"should_trigger": true
},
{
"query": "We have 30 customers we could invite. Is that enough to start?",
"should_trigger": true
},
{
"query": "We're planning to announce our new Discord to the whole newsletter on day one. Sanity check?",
"should_trigger": true
},
{
"query": "What would make us shut down a community we just started?",
"should_trigger": true
},
{
"query": "What are the cheaper alternatives to running our own community?",
"should_trigger": true
},
{
"query": "Should we turn on GitHub Discussions for our repo?",
"should_trigger": true
},
{
"query": "How do we seed the first conversations so the room isn't empty on day one?",
"should_trigger": true
},
{
"query": "Our users keep answering each other in GitHub issues. What should we do with that?",
"should_trigger": true
},
{
"query": "Set the thresholds that tell us whether our community launch worked.",
"should_trigger": true
},
{
"query": "We want to open a space for our users but nobody really has time to run it.",
"should_trigger": true
},
{
"query": "How do I pick between starting a subreddit and running our own forum?",
"should_trigger": true
},
{
"query": "Write me a launch brief for a developer community.",
"should_trigger": true
},
{
"query": "Is a Discord a good idea for a B2B devtool with 40 enterprise customers?",
"should_trigger": true
},
{
"query": "We're pre-launch. When is the right moment to start a community?",
"should_trigger": true
},
{
"query": "Should we build a place for our users to talk to each other?",
"should_trigger": true
},
{
"query": "what's the minimum viable version of this, community-wise",
"should_trigger": true
},
{
"query": "My open source project has 4,000 stars and nowhere for users to talk. Suggestions?",
"should_trigger": true
},
{
"query": "How do we know if we're ready to run a community?",
"should_trigger": true
},
{
"query": "Our support inbox is drowning. Would a community help?",
"should_trigger": true
},
{
"query": "Do we start private with a small group or go public straight away?",
"should_trigger": true
},
{
"query": "How many channels should we open on day one?",
"should_trigger": true
},
{
"query": "Should we just run office hours instead of a whole community?",
"should_trigger": true
},
{
"query": "Give me a decision framework for starting a developer community.",
"should_trigger": true
},
{
"query": "Our competitor has a Discord with 10k members. Should we have one too?",
"should_trigger": true
},
{
"query": "We want somewhere our users help each other instead of emailing us.",
"should_trigger": true
},
{
"query": "How do I convince my manager we're not ready for this yet?",
"should_trigger": true
},
{
"query": "What's a realistic target for the first quarter of a brand new forum?",
"should_trigger": true
},
{
"query": "Help me choose a venue for a developer community aimed at platform engineers.",
"should_trigger": true
},
{
"query": "We opened a room six weeks ago and it's dead. When do we call it?",
"should_trigger": true
},
{
"query": "We have a DevRel hire starting in Q2. Should we wait before opening the community?",
"should_trigger": true
},
{
"query": "Talk me out of starting a Slack for our users.",
"should_trigger": true
},
{
"query": "How should I structure the founding group for a new online user group?",
"should_trigger": true
},
{
"query": "Which of our users should we ask to answer questions once we open the space?",
"should_trigger": true
},
{
"query": "Our docs get 50k visits a month and there's nowhere to ask a question. What now?",
"should_trigger": true
},
{
"query": "We sell a paid dev tool. Where should our customers talk to each other?",
"should_trigger": true
},
{
"query": "Should we open a separate announcements channel when we launch?",
"should_trigger": true
},
{
"query": "Do we need a community or just better docs?",
"should_trigger": true
},
{
"query": "How do we set up a shared Slack space for our enterprise customers?",
"should_trigger": true
},
{
"query": "What evidence should I collect before committing to this?",
"should_trigger": true
},
{
"query": "Is it too early for us to have a community?",
"should_trigger": true
},
{
"query": "Pick a platform for peer-to-peer support for our CLI users.",
"should_trigger": true
},
{
"query": "Our Discord has 4,000 members and has gone quiet. Which metrics should I be tracking?",
"should_trigger": false
},
{
"query": "Which community health metrics matter for a two-year-old forum?",
"should_trigger": false
},
{
"query": "Build me a dashboard for community engagement reporting.",
"should_trigger": false
},
{
"query": "Diagnose why contributor numbers are falling in our three-year-old community.",
"should_trigger": false
},
{
"query": "Write a code of conduct for our Slack.",
"should_trigger": false
},
{
"query": "How do I handle a member who keeps derailing threads?",
"should_trigger": false
},
{
"query": "Design an enforcement ladder for our moderators.",
"should_trigger": false
},
{
"query": "Recruit and train volunteer moderators for our forum.",
"should_trigger": false
},
{
"query": "Someone reported harassment in our community. What's the incident runbook?",
"should_trigger": false
},
{
"query": "Set up an ambassador program for our top 20 users.",
"should_trigger": false
},
{
"query": "What perks should we give our community heroes?",
"should_trigger": false
},
{
"query": "Design the selection criteria for an MVP-style recognition program.",
"should_trigger": false
},
{
"query": "Start a monthly Rust meetup in Lisbon.",
"should_trigger": false
},
{
"query": "Our meetup attendance dropped from 60 to 12. Help.",
"should_trigger": false
},
{
"query": "Find speakers for our user group's next in-person event.",
"should_trigger": false
},
{
"query": "We're open-sourcing our library next week. Plan the announcement.",
"should_trigger": false
},
{
"query": "How do we get onto GitHub Trending on release day?",
"should_trigger": false
},
{
"query": "Write a CONTRIBUTING.md so strangers can land a first pull request.",
"should_trigger": false
},
{
"query": "Nobody contributes to my project. What's blocking them?",
"should_trigger": false
},
{
"query": "Our issue tracker has 800 open issues. Design a triage system.",
"should_trigger": false
},
{
"query": "Who decides what gets merged here? Write us a GOVERNANCE.md.",
"should_trigger": false
},
{
"query": "Should we donate the project to a foundation?",
"should_trigger": false
},
{
"query": "How much of our DevRel budget should go to community versus events?",
"should_trigger": false
},
{
"query": "Prove DevRel ROI to my CFO.",
"should_trigger": false
},
{
"query": "What should a brand new DevRel program do in its first year?",
"should_trigger": false
},
{
"query": "Should DevRel report to marketing or to product?",
"should_trigger": false
},
{
"query": "Who are our developers, actually? Cut them into segments.",
"should_trigger": false
},
{
"query": "Map the developer journey from first docs visit to first deploy.",
"should_trigger": false
},
{
"query": "Which conferences should we sponsor next year?",
"should_trigger": false
},
{
"query": "Plan a booth activation for a 4,000-person infrastructure conference.",
"should_trigger": false
},
{
"query": "Plan a quarter of blog posts and videos for our developer audience.",
"should_trigger": false
},
{
"query": "Benchmark our competitor's developer relations motion.",
"should_trigger": false
},
{
"query": "Write the release notes for v3.0.",
"should_trigger": false
},
{
"query": "Our quickstart takes 40 minutes. Fix it.",
"should_trigger": false
},
{
"query": "Audit our docs structure against Diátaxis.",
"should_trigger": false
},
{
"query": "Write a migration guide for the v2 to v3 breaking changes.",
"should_trigger": false
},
{
"query": "Should we build in public, and how much do we share?",
"should_trigger": false
},
{
"query": "Optimize our GitHub organization profile page.",
"should_trigger": false
},
{
"query": "Pick a license for our new library.",
"should_trigger": false
},
{
"query": "Open core or hosted open source - how should we make money?",
"should_trigger": false
},
{
"query": "What should we charge for our API?",
"should_trigger": false
},
{
"query": "Write a CFP submission for our talk on eBPF.",
"should_trigger": false
},
{
"query": "Prep me for a podcast interview about our platform.",
"should_trigger": false
},
{
"query": "Design a certification program for our platform.",
"should_trigger": false
},
{
"query": "Should we open extension points so partners can build integrations?",
"should_trigger": false
},
{
"query": "How do we grow our existing subreddit's subscriber count?",
"should_trigger": false
},
{
"query": "Write a Reddit post about our tool that won't get downvoted into oblivion.",
"should_trigger": false
},
{
"query": "Build a brand community flywheel for our consumer fitness app.",
"should_trigger": false
},
{
"query": "Write a Discord bot that welcomes new members to our server.",
"should_trigger": false
},
{
"query": "Set up roles and channel permissions on our existing Discord server.",
"should_trigger": false
},
{
"query": "Migrate our forum from vBulletin to Discourse - what are the technical steps?",
"should_trigger": false
},
{
"query": "How do we run a hackathon for our developer users?",
"should_trigger": false
},
{
"query": "Plan a summit for our existing ambassador cohort.",
"should_trigger": false
},
{
"query": "What's a good employer brand strategy for hiring backend engineers?",
"should_trigger": false
},
{
"query": "Design a referral program for our SaaS.",
"should_trigger": false
},
{
"query": "Our community manager is burning out. How do I restructure the role?",
"should_trigger": false
}
]
}
references/launch-brief-template.md›
# Community launch brief
Contents: template → worked example (launch verdict) → worked example (do-not-launch verdict) → weak example to avoid.
Present the brief one section at a time and get the user's agreement before writing the next. A brief delivered whole invites a single "looks good" that hides disagreement on the parts that matter.
## Template
```markdown
# Community Launch Brief - <project or product>
## 1. Verdict
Launch / Launch on <condition> / Do not launch - <one sentence of reasoning>.
Gates: demand <pass|weak|fail>, owner <…>, purpose <…>, venue vacuum <…>, seed supply <…>.
Evidence behind each gate: <one line each>.
## 2. Audience and outcome
Primary audience: <role, seniority, ecosystem>. B2B or B2C: <which, and what it changes>.
Primary outcome (SPACES letter): <support | product | acquisition and advocacy | content and contribution | engagement | success> - <measurable claim>. Secondary: <list, explicitly unranked below the primary>.
Community model: support-driven / product-development / education / founder-led.
## 3. Venue
Chosen: <class, then vendor> - highest surviving rung, at <standing presence per week> against <outcome bought>.
Deleted by constraint: <class> - reopens when <trigger>. <class> - reopens when <trigger>.
Rejected on the ratio: <class> because <reason>.
Mechanics verified on <date>: <pricing, history retention, permission model, export>.
## 4. Target member mix at 90 days
Founding cohort: <n> named people, <topic areas>, <time zones>.
Target: <n> contributors/advocates actively answering, <n> participants posting monthly.
## 5. Seeding plan
Founding invitations: <who, the ask, the time-box>.
Seeded content: <the 5-10 posts and who answers them>.
Opened surface: <the small set of rooms/categories and why each exists>.
Ritual: <what, when, who runs it>.
Published response-time commitment: <target>.
## 6. First 90 days
Weeks 1-2 (private cohort): <activities>.
Weeks 3-6 (invited beta): <activities, and the activity gate to pass before opening>.
Weeks 7-12 (public): <announcement channels, and what gets measured weekly>.
## 7. Thresholds and measurement
Day-30 leading indicators: <list>.
Day-90 pass thresholds: <table or list, with any B2B/B2C adjustment and its justification>.
Threshold basis: <which thresholds are published and which are baselines set for this plan, and what will recalibrate them>.
Who measures, how often, from which source.
## 8. Fold-back criteria
If <failing condition> at <date>, we <archive read-only | merge into <space> | convert to support channel>.
Decision owner: <name>.
## 9. Open risks
<risk> - <mitigation or accepted>.
```
## Worked example - launch verdict
> **Verdict:** Launch on 15 October, gated on the second answerer being confirmed.
> Gates: demand pass (31 setup questions arrived by email in 60 days, 9 of them duplicates; three users already answer each other in the repository's issues), owner pass (Priya, 6h/week committed through Q1, confirmed by her manager), purpose pass (SPACES: Support - "cut duplicate setup questions reaching the inbox by half within two quarters"), venue vacuum pass (the ecosystem's Discord has no channel for this problem domain and its moderators declined a dedicated one), seed supply weak (22 named invitees, but only one reliable answerer outside Priya - mitigation: recruit a second before opening).
>
> **Venue:** Owned async forum (self-hosted Discourse) - the highest rung left standing, at roughly an hour a day of batched moderation against durable indexed answers. Answers about setup and configuration stay valid for months, search traffic on error strings is a wanted acquisition channel, and per-instance pricing suits a growing free-tier audience. Deleted by constraint: real-time chat, because Priya cannot be present most days at 6h/week - reopens only if a second staffed owner joins and the primary outcome moves off Support. Forge-native discussions, because half the audience are operators without accounts on the forge - reopens if the operator segment stops being the majority.
>
> **Fold-back:** if fewer than 50% of posts come from non-staff at day 90, archive the forum read-only, redirect to the repository's discussions, and publish the top 20 answers as troubleshooting pages. Decision owner: Priya.
Why it works:
- Every gate cites evidence rather than intuition.
- The weak gate has a named mitigation and gates the launch date.
- The venue choice names the rejected options and the reasons.
- The exit is decided while it is still cheap to accept.
## Worked example - do-not-launch verdict
> **Verdict:** Do not launch. Gates: demand fail (support volume is 4 tickets/month, none repeating; no evidence users want to talk to each other), owner fail (no named owner; the plan assumed a DevRel hire in Q2), purpose weak ("build community" restated, no measurable claim), venue vacuum fail (the language's official Discord already hosts an active channel where two of our users post), seed supply pass (35 named customers).
>
> **Recommendation instead:** answer publicly in the ecosystem Discord under the company name for one quarter, convert the six most-asked questions into troubleshooting pages, and run monthly office hours. Re-decide when either repeat questions exceed 10/month or users start answering each other in the repository.
Why it works:
- The "no" is as specific as a "yes".
- The alternative serves the same outcome at a fraction of the cost.
- The re-decision trigger is an observable number rather than a date.
## Weak example - what to avoid
> We'll launch a Discord because that's where developers are. Channels: #general, #announcements, #help, #showcase, #jobs, #random, #frontend, #backend, #devops. We'll announce on launch day to the newsletter (8,000 subscribers) and aim for 1,000 members in the first quarter. Marketing will keep an eye on it.
Four defects:
1. The venue is picked by habit rather than by the standing presence it demands forever: a Discord is free to open and a standing job to keep alive, and nobody here has that job.
2. Nine empty rooms broadcast that nobody is there.
3. The whole audience is spent on a single announcement into an unseeded room.
4. "marketing will keep an eye on it" is the ownership gap that produces a ghost town.
The target is also a joins counter, not a health signal - 1,000 members with 20 weekly posters is a failure.
references/platform-mechanics.md›
# Venue mechanics
Contents: the four venue classes → named-vendor mechanics → verification rules → the one-venue rule. The class ranking itself lives in the skill body, where the choice is made.
Vendor pricing, limits and features change often. Treat every figure here as a starting point to re-verify on the vendor's own pricing or documentation page before putting it in a recommendation, and say when it was last checked.
## The four venue classes
Rows sit in the skill body's efficiency order - outcome bought per hour of standing moderation presence. The ordering, the per-class trade-offs and the constraints that delete a class live there; this file only carries what the classes are made of and which vendor implements them. Never re-rank them here.
| Class | Shape | Standing presence | Wins on | Loses on |
| ------------------------ | ----------------------------------- | ---------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------- |
| Forge-native discussions | threads attached to the repository | an hour a week, batched | no extra account, sits next to the code, indexed and exportable | thinner community feel, ties the audience to one forge |
| Rented public space | subreddit, Q&A site, ecosystem chat | an hour a week of showing up | existing traffic, no seeding, no hosting, host absorbs moderation | no ownership, host's rules, no member data |
| Owned async forum | threaded, indexed pages | an hour a day | public search traffic, durable answers, ownership, per-instance pricing | slower velocity, higher effort per post, you hold member data |
| Owned real-time chat | synchronous, channel-based | a standing job | immediacy, culture, low join friction, fastest feedback loop | searchability, archive value, always-on expectation |
The primary outcome promotes a class above its default rank:
- Support deflection with durable answers → async forum or forge-native discussions.
- Fast-moving product feedback and founder presence → real-time chat, and only if continuous presence is staffed.
- Contributor recruitment for an open-source project → forge-native discussions first; a separate venue only once discussion volume outgrows the repository.
- Awareness with no staffing → rented public space; participate rather than launch.
## Named-vendor mechanics
Listed in the same class order, best ratio first.
**GitHub Discussions** (forge-native):
- "a collaborative communication forum for the community around an open source or internal project"; discussions "do not need to be tracked on a project and are not related to code".
- Supports categories, polls and marking comments as answers, and converts both ways with issues.
- Any authenticated user who can see the repository can post. Creating categories, pinning and deleting need write permission; marking answers or locking needs triage permission.
- Zero extra account for an audience already on the forge, which makes it the cheapest first venue for an open-source project.
- Source: <https://docs.github.com/en/discussions/quickstart>.
**Rented public spaces** (subreddits, Q&A sites, ecosystem chats) - no hosting or seeding cost and existing traffic, but the host owns moderation policy, the archive and the member relationship, and the space can change its rules or disappear. Use to validate demand before owning a venue, and to reach an audience that would never join a vendor's room.
**Discourse** (owned async forum):
- Open source and free to self-host. Hosted plans listed at $100/month (Pro) and $500/month (Business), plus a free exploration tier.
- Cost is per instance, not per member: the opposite scaling shape from per-seat chat.
- Threaded, indexed, exportable.
- Best fit when answers have a long half-life and search traffic is an acquisition channel; the cost is a slower, higher-effort posting culture.
- Source: <https://www.discourse.org/pricing>.
**Discord** (owned real-time chat):
- Free at any member count, so cost does not scale with growth.
- Community features (rules screening, welcome and onboarding flows, announcement channels, forum-style channels, server insights) are opt-in per server.
- Real-time by default with weak public searchability.
- Discovery and partner-program requirements sit on support pages that block automated fetching; verify manually before promising discovery reach.
- Best fit is a large, informal, hobbyist or ecosystem audience.
- Free to open, and it is the standing presence, not the price, that decides whether it can be kept alive.
**Slack** (owned real-time chat):
- Free plan keeps 90 days of message history and up to 10 apps, with 1:1 external messaging only. Paid plans are per user per month (Pro listed around €8.25 monthly, €6.75 annual at the time of check).
- Two consequences: the free tier deletes the archive that makes a community searchable, and per-seat pricing makes an open community structurally expensive as it grows.
- Best fit is a bounded B2B customer community where members are familiar with the client and the archive matters less than immediacy.
- Source: <https://slack.com/pricing>.
## Verification rules
1. Re-check pricing, free-tier limits and history retention on the vendor's own page before recommending; quote the check date in the brief.
2. Check export and data-portability claims specifically - the ability to leave decides how reversible the choice is.
3. Check moderation tooling against the staffing floor: continuous-presence venues need more hours than the owner may have.
4. Check accessibility constraints for the audience's region, employer network policies and language support before committing.
## The one-venue rule
Running two owned venues before either reaches critical mass splits the same conversation volume in two and makes both look dead. Pick one primary venue. Give any second surface a distinct, non-overlapping job - announcements only, or long-form Q&A only - and say so publicly, so members know where to post.
references/readiness-and-thresholds.md›
# Readiness gates and critical-mass thresholds
Contents: gate checklist with evidence tests → verdict rules → day-30 leading indicators → published anchors → day-90 pass thresholds with their basis → measurement notes → sources.
## Table of Contents
- [Gate 1 - Demand](#gate-1-demand)
- [Gate 2 - Owner](#gate-2-owner)
- [Gate 3 - Purpose](#gate-3-purpose)
- [Gate 4 - Venue vacuum](#gate-4-venue-vacuum)
- [Gate 5 - Seed supply](#gate-5-seed-supply)
- [Verdict rules](#verdict-rules)
- [Day-30 leading indicators](#day-30-leading-indicators)
- [Published anchors](#published-anchors)
- [Day-90 pass thresholds](#day-90-pass-thresholds)
- [Measurement notes](#measurement-notes)
- [Sources](#sources)
## Gate 1 - Demand
The community makes peer conversation possible; it does not create the appetite for it. Accept as evidence:
- Repeat questions arriving privately (support inbox, DMs, maintainer email) that another user could have answered.
- Users answering each other unprompted in issues, threads, replies or a third-party space.
- A problem domain deep enough to sustain conversation. A product fully learnable from a quickstart generates no recurring discussion.
- A shared identity beyond the product - who members are or want to be. Rooms organized purely around a vendor's feature list run out of things to say.
Reject as evidence: competitor communities existing, a leadership request, a launch checklist item, "our users are technical so they'll want a Discord".
## Gate 2 - Owner
- One named person, not a team-in-principle, with weekly hours protected for the first 90 days _and_ a sustained figure for after them. The launch quarter is the cheap part; the standing presence is what the venue class is chosen against.
- The first phase is deliberately unscalable: answer every post, welcome every member by name, host the ritual. Budget hours for that, not for "monitoring".
- Record whether that person can be present most days or only in batches - it deletes venue classes outright rather than adjusting them.
- No named owner, or hours that depend on a future hire, fails the gate. Delay is cheaper than a public failure.
## Gate 3 - Purpose
Name the outcome with CMX's SPACES vocabulary, then state it as a measurable claim:
| Letter | Outcome | What the community is for |
| ------ | ------------------------ | ----------------------------------------------------------------------------------------------------- |
| S | Support | members answer each other, cutting support cost and raising satisfaction |
| P | Product | members' ideas and feedback drive product decisions |
| A | Acquisition and advocacy | a network of ambassadors drives awareness and growth |
| C | Content and contribution | members contribute content that becomes part of the product or its assets |
| E | Engagement | people gather around a common interest related to the product; internally, employees/partners/vendors |
| S | Success | adoption and customer lifetime value rise through best-practice sharing and upskilling |
CMX's own rule for a new community: "If you're starting out, just focus on one objective from the SPACES Model. Trying to accomplish too many things makes it difficult to clearly define and track community value." Source: <https://cmxhub.com/the-spaces-model/>.
Examples of the measurable claim:
- "cut repeat setup tickets by a third within two quarters"
- "get 10 usable roadmap signals per month"
- "convert 5 power users into contributors this year"
Secondary outcomes are fine, unranked outcomes are not: the primary outcome decides the community model, the venue and the thresholds.
## Gate 4 - Venue vacuum
Search for where the audience already gathers, then ask, for each, whether the outcome could be reached by showing up there instead:
- Ecosystem chats
- Subreddits
- Q&A sites
- Language communities
- An existing user group
Owning a space buys control, archive and member data; joining one costs no seeding and no moderation staffing. Fail this gate when an existing space already serves the outcome - the recommendation is to participate, not to launch.
FeverBee frames the same test as an ecosystem-maturity question: map whether an ecosystem already serves the need before building a new community on top of it. Source: Richard Millington, "Your Ecosystem's Maturity Should Guide Your Big Community Decisions," FeverBee, <https://www.feverbee.com/ecosystemmaturityindex/>; "We Need A New Playbook For Building Brand Communities," FeverBee, 2 September 2024, <https://www.feverbee.com/newplaybook/>. CNCF enforces a narrower, operational version of the same rule: Kubernetes project Slack channels exist "to organize an existing community, not seed new ones." Source: "Slack Guidelines," kubernetes.dev, <https://www.kubernetes.dev/docs/comms/slack/>.
## Gate 5 - Seed supply
- At least 20 people the team can invite **by name** this month, ideally 20-50.
- Coverage matters more than count: one reliable answerer per topic area, two or more time zones for a global audience.
- Founding members should already behave like contributors or advocates. A cohort of passive newcomers produces silence.
## Verdict rules
| Gates passed | Verdict |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| 5 | Launch. Proceed to venue choice and seeding. |
| 4 with written mitigation | Launch on a delayed date, gated on the mitigation landing - not on the calendar. |
| ≤ 3 | Do not launch. Recommend the alternative that returns the most per standing hour, plus the evidence to collect for a re-decision. |
The alternatives and their ranking live in the skill body - one ordering, by evidence bought per hour of standing presence, not by cost. Do not re-derive a second order here.
## Day-30 leading indicators
Too early for ratios, so watch behavior instead:
- Any post authored by someone outside the founding cohort.
- Any question answered by a member rather than the team.
- The ritual running on schedule, at least twice, with attendance above the organizer.
- Median first-response time under a few hours during working hours.
Zero member-authored answers at day 30 predicts a failed day-90 gate; act then, not later.
## Published anchors
Three published findings anchor this area. Frame the target with them before quoting any percentage.
| Finding | Source |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| ~90% of members never post, 9% contribute occasionally, 1% produce most contributions (90-9-1). Lurking is the baseline, not a defect; a _change_ in the ratio is the news. | Jakob Nielsen, NN/g, 8 October 2006, <https://www.nngroup.com/articles/participation-inequality/> |
| Contributors who received a review within 48 hours returned and contributed again at a much higher rate; "it only takes one negative experience to make someone not want to come back". | Mozilla study cited in GitHub Open Source Guides, <https://opensource.guide/building-community/> |
| Recurring activity, not cumulative membership, marks a group alive: inactive after >90 days without an event; active requires a quarterly event with more than 10 _attendees_. | CNCF community group rules, <https://github.com/cncf/communitygroups> |
Read every measurement against a trailing baseline rather than the launch month. CHAOSS's burstiness metric exists because releases, conferences and media coverage produce spikes that decay; comparing a quiet month against a launch spike is the most common false trend in community reporting. <https://chaoss.community/kb/metric-burstiness/>
## Day-90 pass thresholds
The metric _definitions_ below are sound and reusable. The cutoff values are adapted from practitioner baseline practices. Present them as a starting hypothesis to recalibrate against the community's own trailing data as soon as one exists, not as an unchangeable standard.
| Signal | Pass | Warning | Failing | Where the numbers come from |
| ------------------------------------- | ----- | ------- | ------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Questions answered within 24h | > 90% | 75-90% | < 75% | `community-building` ("unanswered questions" <10%/10-25%/>25%), consistent with `community-marketing`'s ">24 hours" warning sign |
| Share of posts written by non-staff | > 50% | 30-50% | < 30% | inverse of `community-building`'s moderator-message share (<30%/30-50%/>50%); the >50% pass is set here |
| New members posting within 7 days | > 40% | 20-40% | < 20% | `community-building`, adopted as published |
| Monthly active / total members | > 20% | 10-20% | < 10% | `community-building`; `community-marketing` states the same 20% DAU/MAU bar |
| Threads with ≥ 1 reply | > 80% | 60-80% | < 60% | metric named by `community-marketing`, thresholds set here |
| Engagement share of the top 5 members | < 50% | 50-80% | > 80% | the >80% failing band is `community-marketing`'s warning sign; the <50% pass is set here |
Reading the results:
- Two or more failing signals → re-run the shape and seeding steps on the specific failure, or trigger the fold-back. More promotion into a silent room lowers every ratio.
- High answer rate with a low non-staff share means the team is doing the community's job; the room is a support channel wearing a community's name.
- High activity concentrated in the top 5 members is fragile: those five leaving takes the community with them.
- Adjust thresholds for a deliberately small, high-value B2B room - a 40-member customer community can pass on absolute counts (every question answered, five distinct members posting weekly) while missing percentage bars. State the adjustment and its reasoning in the brief.
## Measurement notes
- Prefer the venue's native analytics; where they are thin, sample manually for one week per month rather than building instrumentation the owner cannot maintain.
- Count staff by role, not by badge: a paid contractor answering support is staff.
- Track joins and leaves separately; net member count hides churn.
- Report the count of active members alongside every ratio. With a ~90% lurker baseline, a percentage moves as fast when members leave as when activity grows.
## Sources
- GitHub Open Source Guides, "Building community" and "Finding users" - public-place-to-talk principle, 48-hour responsiveness evidence (Mozilla study), one-negative-experience warning. <https://opensource.guide/building-community/>, <https://opensource.guide/finding-users/>
- Jakob Nielsen, "Participation Inequality" (NN/g, 2006) for the 90-9-1 baseline. <https://www.nngroup.com/articles/participation-inequality/>
- CMX, "The SPACES Model" for the outcome vocabulary and the one-objective rule. <https://cmxhub.com/the-spaces-model/>
- CHAOSS burstiness metric for the spike-versus-trend caveat. <https://chaoss.community/kb/metric-burstiness/>
- CNCF community group rules for the activity floor. <https://github.com/cncf/communitygroups>
- Orbit Model for member-level vocabulary. <https://orbit-model.joshed.io/>
- FeverBee, "Your Ecosystem's Maturity Should Guide Your Big Community Decisions" and "We Need A New Playbook For Building Brand Communities" for the venue-vacuum test. <https://www.feverbee.com/ecosystemmaturityindex/>, <https://www.feverbee.com/newplaybook/>
- CNCF, "Slack Guidelines" for the operational venue-vacuum rule governing Kubernetes project Slack channels. <https://www.kubernetes.dev/docs/comms/slack/>
SKILL.md›
---
name: developer-community-launch
description: Decides whether, where and when to launch a developer community, then plans its seeding and first 90 days - venue selection, founding-member seeding, go/no-go criteria, the cheaper no-community alternatives, and shutdown criteria. Use whenever someone asks whether to start a Discord, Slack or forum for their users, which community platform to pick, how to launch or seed a developer community from zero, or how to reach critical mass - even if they only say "we should have a Discord". Do NOT use for a community that already exists; measurement is samber/developer-relations-skills@developer-community-health and moderation is samber/developer-relations-skills@developer-community-moderation.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Developer Community Launch
You are a developer community strategist. Your job is to make the launch decision defensible: whether a community is the right instrument at all, which venue class fits, when to open it, how to seed it, and what evidence 90 days later says keep or kill.
Most community failures happen before launch day: an empty room opens because launching felt like progress. Treat "do not launch yet" as a valid, frequent recommendation.
## Route before planning
Check what the user actually needs before running the workflow:
- Community already exists and needs rules, escalation or incident handling → `samber/developer-relations-skills@developer-community-moderation`.
- Community already exists and needs measurement or diagnosis → `samber/developer-relations-skills@developer-community-health`.
- They want to recruit and reward super-users → `samber/developer-relations-skills@developer-champions`.
- The "community" they mean is a recurring in-person meetup → `samber/developer-relations-skills@developer-meetup-program`.
- The "community" they mean is a recurring session where users bring questions to the team → `samber/developer-relations-skills@developer-office-hours-program`.
- They want to announce an open-source project → `samber/developer-relations-skills@oss-launch`.
Say which skill fits and stop. Half-running this workflow on the wrong problem wastes the user's time.
## Interview
Ask these one at a time, multiple-choice when the options are knowable. Stop asking once you can answer the readiness gates; do not run the full list mechanically.
**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 product or project, and who exactly are the developers you want in the room (role, seniority, ecosystem)?
2. Is this B2B (a paid developer tool where a buyer and a user may differ) or B2C/community-scale (open source, indie, hobbyist, students)?
3. Which single business outcome would justify the effort: support, product feedback, acquisition and advocacy, member-contributed content, engagement around a shared interest, or customer success and adoption? Pick one primary.
4. What proof exists that peer conversation already happens: repeat questions arriving privately that another user could have answered, or users answering each other unprompted somewhere?
5. Which spaces does this audience already use - ecosystem chats, subreddits, Q&A sites - and why would participating there not serve the outcome?
6. Who owns this, and how many hours per week can they sustain _after_ the launch quarter - not for the first 90 days, but for as long as the venue stays open? Can they be present most days, or only in batches?
7. By what date must the first result land, and who judges it then?
8. Do you want a one-off win - this quarter's repeat questions answered - or a compounding asset: an indexed archive and a member base that keeps paying off?
9. Name the first invitees: how many users, customers, or contributors could you personally invite this month, and which of them already answer other people's questions?
10. Does answer durability matter - do questions asked today stay valuable in six months?
11. Any constraints on data ownership, privacy, moderation obligations, or region/language coverage?
12. What would make you shut it down, and who gets to make that call?
Questions 4, 5 and 9 feed three different gates. Ask all three even when the answers start to sound similar:
- Question 4 tests demand.
- Question 5 tests the venue vacuum.
- Question 9 tests seed supply.
Answers 6, 7 and 8 re-rank the venue menu in _Where_ - carry them there instead of re-asking. Question 6 is the decisive one: a venue is cheap to open and expensive to keep alive, so the sustained weekly hours, not the setup budget, decide the class.
- Under a few hours a week deletes both owned classes.
- An owner who cannot be present most days deletes owned real-time chat outright.
- A hard date inside one quarter promotes the two venues that need no seeding, a rented public space and forge-native discussions, since an owned forum's search value compounds over quarters.
- A compounding mandate promotes the owned async forum.
- A one-off win promotes answering publicly where the audience already is.
## Workflow
1. Route, then interview until the gates are answerable.
2. Score the readiness gates and state a whether-verdict - launch, launch later, or do not launch and use an alternative.
3. Choose the venue class from the ranked menu - delete what the interview's constraints rule out, then take the highest surviving rung. Never pick from vendor familiarity.
4. Brainstorm 2-3 candidate launch approaches with trade-offs, then recommend one.
5. Design the seeding plan and the first 90 days.
6. Set the go/no-go thresholds and the kill criteria _before_ launch.
7. Write the launch brief section by section, validating each section with the user before moving on.
## Whether: readiness gates
Five gates. Score each pass, weak or fail with the evidence behind it. See [./references/readiness-and-thresholds.md](./references/readiness-and-thresholds.md) for the full checklist and what counts as evidence.
| Gate | Passes when |
| ------------ | -------------------------------------------------------------------------------------------------------- |
| Demand | Repeat questions arrive privately, or users already answer each other somewhere |
| Owner | One named person, with committed hours for the launch quarter and a sustained weekly figure for after it |
| Purpose | One primary business outcome, named and stated as a measurable claim |
| Venue vacuum | No existing space already serves this audience well enough to join instead |
| Seed supply | 20+ people the team can invite by name, with topic and time-zone coverage |
Name the purpose gate's outcome with CMX's SPACES vocabulary - Support, Product, Acquisition and advocacy, Content and contribution, Engagement, Success - and hold the user to exactly one. CMX's own instruction is the reason (David Spinks' SPACES model page, last updated 2021): "If you're starting out, just focus on one objective from the SPACES Model. Trying to accomplish too many things makes it difficult to clearly define and track community value." The chosen letter then decides the community model, the venue and the thresholds, so an unranked list of three outcomes fails the gate.
The gates, their pass conditions and the verdict rule are a baseline set here rather than an industry standard.
| Gates passing | Verdict |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| All five | Launch. |
| Four, with a written mitigation for the weak one | Launch on a delayed date, gated on the mitigation landing. |
| Three or fewer | Do not launch. Recommend the alternative below that returns the most per standing hour, never the cheapest one on the list. |
### Alternatives when the verdict is "not yet"
Five of them, ranked by evidence bought per hour of standing presence - because the thing blocked is the launch decision, and the alternative that serves the outcome without producing that evidence leaves the user exactly where they started. Say the order out loud, then recommend one:
- efficiency: `answer publicly where the audience already is > forge-native discussions on the repository > troubleshooting/FAQ surface > scheduled office hours > email or issue-based feedback loop`
- effort (standing presence, highest first): `office hours > answer publicly == forge-native discussions == feedback loop (tie argued: all three are an hour a week of replies written when the owner gets to them - no calendar to honor, no session to prepare, no attendance to fill) > FAQ surface (a week to write, near-zero to keep)`
- value (evidence bought toward the launch decision, highest first): `answer publicly > forge-native discussions > office hours > FAQ surface > feedback loop`
Each one, with its trade-off:
- **Answer publicly where the audience already is** - an hour a week, forever, in a room someone else keeps alive. Tests the demand gate and the venue-vacuum gate at the same time: you find out whether the questions repeat _and_ whether the existing space already serves them. Buys no archive and no member list.
- **Forge-native discussions on the repository** - an hour a week, forever, batched. The only alternative that converts directly into the launch if it works: the threads are indexed, owned and exportable, and the members are already there. Needs the audience to be on the forge, and an empty Discussions tab is a ghost town in miniature.
- **Troubleshooting/FAQ surface** - a week to write, near-zero forever, minus a refresh a quarter. Deflects the repeat question permanently and earns search traffic, but a page cannot show you users answering each other, so it barely moves the demand gate. Promote it to first when the primary outcome is Support: it may resolve the need outright and end the launch question.
- **Scheduled office hours** - an hour a week, forever, plus prep, and it must survive a session nobody attends. Buys the deepest signal per attendee and the closest proxy to community behavior: whether anyone shows up for a recurring thing. Promote it when seed supply is the failing gate.
- **Email or issue-based feedback loop** - an hour a week, forever, closing each loop by hand. Buys product feedback, and structurally cannot buy peer-conversation evidence: it is one-to-one by construction, so it never advances the gate that blocked the launch.
No compliance-cost axis here: none of these five makes the team the host of a space, which is where the standing moderation and member-data obligations attach.
What this order starves: office hours. It sits highest on the effort line and only third on value, so the ratio puts it fourth every round - yet it is the only one of the five that tests whether people will turn up for a recurring thing, which is what the first 90 days run on. Promote it whenever the doubt is about attendance rather than about demand.
This order is a default, not a law. It shifts with context and with who executes it: re-rank it against what you already know about this user before presenting it.
- An audience already gathered in an active ecosystem space promotes answering publicly, to the point where nothing else is worth starting.
- A maintainer who is in the repository all day anyway makes forge-native discussions nearly free.
- A docs site that already ranks promotes the FAQ surface above both, since the distribution it needs is already built.
## Where: venue class before vendor
Four classes, ranked by outcome bought per hour of standing moderation presence - not by setup cost, and not cheapest-first. The setup is a weekend in every class; what separates them is the presence the venue demands forever after, so that is the effort axis.
Say the order out loud to the user, then pick one. The axes disagree, so read all of them:
- efficiency: `forge-native discussions > rented public space > owned async forum > owned real-time chat`
- effort (standing presence, highest first): `owned real-time chat > owned async forum > forge-native discussions == rented public space (tie argued: both are an hour a week of batched replies in a room somebody else already runs - no signup queue, no taxonomy, no uptime, no onboarding flow to keep working)`
- value (outcome bought, highest first): `owned async forum > owned real-time chat > forge-native discussions > rented public space`
- compliance cost: `owned real-time chat > owned async forum > forge-native discussions > rented public space`
Each class, with its trade-off:
- **Forge-native discussions** - an hour a week, batched: the forge runs the venue, carries the abuse-reporting machinery, and needs no new account from anyone. Buys durable indexed answers you own and export, next to the code, at the lowest join friction of the four. Thin community feel, and it ties the audience to one forge. Default first rung unless a constraint below deletes it.
- **Rented public space** (subreddit, Q&A site, ecosystem chat) - an hour a week of showing up; the host absorbs moderation policy, spam and conduct enforcement entirely. Buys reach into an audience already gathered, with no seeding and no hosting. Buys no archive, no member list and no control: the host can change its rules or disappear, and your only compliance exposure is disclosing who you are. Lowest value, and the easiest to walk away from.
- **Owned async forum** - an hour a day: unanswered threads are the launch defect, and signup moderation, spam, the category tree and the vendor are all yours. Buys the most durable value of the four - indexed answers, search traffic as an acquisition channel, an exportable member list - plus per-instance pricing that stops punishing you as the room grows. Slowest to compound, and you hold member data, which is where residency and erasure obligations attach.
- **Owned real-time chat** - a standing job: the room is only alive while someone is in it, and real-time conduct is unreviewable before it is read, so the obligation is presence rather than response. Buys the highest engagement of the four - velocity, culture, founder proximity, the fastest feedback loop - and almost nothing that survives the week, since the archive is unindexed. Hardest to leave: the members are the venue, and they do not export.
Constraints delete a class rather than demoting it; a deleted class goes on the brief's Venue line with the trigger that would reopen it:
- Answers stay useful for months, or search traffic on them is a wanted acquisition channel → deletes owned real-time chat, which is not indexed.
- An owner who cannot be present most days → deletes owned real-time chat. Under a few hours a week sustained → deletes both owned classes.
- An active space already serves this audience and this outcome → deletes both owned classes; that is the venue-vacuum gate failing, and a duplicate room splits the conversation until both look dead.
- An audience without accounts on the forge, or a project with no public repository → deletes forge-native discussions.
- A contractual privacy requirement, or members who cannot post in public under their employer's rules → deletes the rented public space and forge-native discussions, both public by construction.
Default rung: forge-native discussions wherever the audience is already on the forge. Move up one rung to the owned async forum when search traffic on the answers is a named acquisition channel, or thread volume has already outgrown the repository, _and_ the owner has a daily pass to give.
What this order starves: owned real-time chat. It sits second on value only because the forum's archive outlasts it - on engagement itself nothing beats it.
It tops both the effort and compliance-cost lines outright, so the ratio puts it last in every round. A team that only obeys the efficiency line never opens the one venue where a founder-led, fast-feedback culture actually forms.
Promote it when the primary outcome is Product or Engagement - value that lives in the moment, not in the archive - and continuous presence is genuinely staffed by a named person or rota. Never promote it on ambition, and never on "that's where developers are": it is built to lose this ratio, and it only wins when the outcome makes the archive worthless.
This order is a default, not a law: it shifts with context and with who executes it. Re-rank it against what you already know about this user before presenting it.
- An audience already gathered in an ecosystem chat promotes the rented space, because the seeding cost is already spent.
- A maintainer who is in the repository all day anyway makes forge-native discussions nearly free.
- An existing forum or docs platform the team already runs promotes the owned async forum, since the standing job is already staffed.
- A global audience with no time-zone coverage past one person deletes real-time chat whatever the outcome says.
Open exactly one primary venue. A second surface only ships with a distinct, non-overlapping job (announcements only, long-form Q&A only).
Current vendor mechanics - pricing, history limits, permission models, and what to re-verify before recommending - live in [./references/platform-mechanics.md](./references/platform-mechanics.md). Read it when the user needs a named recommendation; never quote figures from memory, since plans change.
## Brainstorm the shape
Never jump from interview to plan. Put 2-3 candidate approaches on the table, each with its trade-off and its failure mode, then recommend one and say why:
- Vary the opening scope (private cohort vs. public), the community model, and the venue class - but only across the classes the constraints left standing. A class deleted in _Where_ never comes back as a candidate here.
- Community models are not ranked by efficiency: the primary outcome picks the model outright, so a value-per-effort order over them would be false precision dressed as a recommendation. Most start founder-led and specialize later; a launch aimed at acquisition/advocacy, member-contributed content or plain engagement has no model to copy here, so design its shape from the outcome instead of forcing it into one of the four. Chosen from the primary outcome:
- **Support-driven**: repeat questions, peers answer faster than the team.
- **Product-development**: opinionated users shape the roadmap.
- **Education/enablement**: the learning curve gates activation.
- **Founder-led**: early stage, the founder's voice is the trust.
- Target the member mix, not the headcount. Orbit-model vocabulary is useful here: explorers (passive newcomers) → participants → contributors → advocates. A launch that recruits only explorers produces silence; the founding cohort must be contributors and advocates.
Present the recommendation as a claim the user can reject: "Async forum, founder-led, private for six weeks - because answer half-life is long and one owner cannot staff real-time chat."
## Seed: founding cohort and the first 90 days
1. **Recruit 20-50 founding members by hand, for coverage rather than headcount** (the 20-50 range is Corey Haines', _Founding Marketing_; the coverage rule is set by this skill). Personal asks only, each stating why that person and what you want from them (answer questions in their area, post once a week, for the first quarter). Cover every topic area you plan to open with at least one reliable answerer, and at least two time zones if the audience is global.
2. **Open a small surface.** Fewer categories or channels with visible activity beat a complete taxonomy of empty ones. Add rooms only when an existing one gets noisy.
3. **Seed 5-10 posts that model the behavior you want** - real questions, real answers, a win, a resource. Seed the answers too; an unanswered seeded question teaches newcomers that questions go unanswered here.
4. **Write the vibe, not just the rules.** Describe what great participation looks like. A code of conduct sets a floor, not a culture, and its enforcement belongs to the moderation skill.
5. **Install one recurring ritual from week one** - a weekly working-on thread, office hours, or show-and-tell. Rituals convert one-time visits into habit.
6. **Commit to a response time and publish it.** Fast acknowledgement is the retention lever with the strongest published evidence (see the thresholds section); treat unanswered posts as the primary launch defect.
Sequence the opening separately from the seeding, each transition gated on observed activity, never on a calendar date:
1. Founding cohort
2. Invited beta
3. Public announcement
Announcing to the whole audience on day one spends the single first impression on an empty room.
## Objective: critical-mass thresholds
Set the pass thresholds before launch and write them into the brief; measuring after the fact invites rationalization.
Three published findings anchor this area. Frame the targets on them before quoting any percentage:
- **Around 90% of members never post.** Jakob Nielsen's 90-9-1 participation inequality (NN/g, 2006) holds across forums and wikis. Lurking is the baseline condition, not a launch defect: set targets on the number of active members, not on shrinking the lurker share.
- **Responsiveness is the retention lever with published evidence.** A Mozilla study cited by GitHub's Open Source Guides found contributors who received a code review within 48 hours returned and contributed again at a much higher rate, a code-contribution finding applied here to community response time. The same guide warns "it only takes one negative experience to make someone not want to come back." Publish a response-time commitment inside that window.
- **Recurring activity beats cumulative membership as a liveness test.** CNCF marks a community group inactive after more than 90 days without an event, and requires a quarterly event with more than 10 _attendees_ (attendees, not registrations). The rule is written for in-person groups; the recurring-activity principle is what transfers.
The day-90 table below sets baseline thresholds adapted from published community-health measurement practices. Present it as a starting hypothesis to recalibrate against the community's own trailing data, never as an industry standard.
| Signal | Pass (baseline) |
| ---------------------------------- | --------------- |
| Questions answered within 24h | > 90% |
| Posts written by non-staff members | > 50% |
| New members posting within 7 days | > 40% |
| Monthly active / total members | > 20% |
| Threads with at least one reply | > 80% |
| Engagement from the top 5 members | < 50% of total |
Read the table with three rules:
- Compare every number against a trailing baseline, never against the launch month. A launch, a release or a conference produces a burst of activity that decays - CHAOSS names this burstiness - and comparing a quiet month against a spike is the most common false trend in community reporting.
- Member count is a joins counter, not a health signal. A 5,000-member room with 20 weekly posters is a failed launch with good PR.
- Two or more signals below pass → do not "push harder on promotion"; more joins into a silent room lowers every ratio. Re-run workflow steps 4-6 on the failing signal, or trigger the fold-back.
Full definitions, warning bands, each row's basis - published or set here - and the day-30 leading indicators are in [./references/readiness-and-thresholds.md](./references/readiness-and-thresholds.md).
Write the fold-back condition into the brief before launch. Choose the exit in this order: `archive to read-only > merge into the space the audience already uses > convert to a plain support channel`.
- Archiving keeps the answers and their search traffic at near-zero standing effort.
- Merging keeps the people but abandons the archive.
- A support channel keeps the standing job and drops only the community pretense.
Pick by what you are least willing to lose, and name the exit in advance: that is what makes the honest call possible later.
## B2B versus B2C
The gates, venue reasoning and seeding mechanics are identical. These differ:
**B2B developer tools:**
- The user and the buyer differ: the room fills with implementers while the renewal depends on someone who never posts. Plan a separate signal path to that buyer.
- Members work under employer constraints - many cannot paste code, discuss architecture, or appear publicly.
- Customers frequently request private per-customer channels. They fragment the community and drift into support contracts: gate them on contract value and staff them as support, not community.
- Expect weekday-business-hours activity, a smaller and higher-value membership, and stricter data-residency and privacy questions.
**B2C / open-source / hobbyist:**
- Activity peaks evenings and weekends; moderation load per member is higher and arrives out of hours.
- Membership is larger and far more transient, and public search traffic is a primary acquisition channel - which favors indexed async venues.
- Status and recognition motivate participation more than vendor access does.
Name which one the plan targets. A mixed audience needs a stated primary and an explicit answer for the other, not silence.
## Failure modes
- **Ghost town** - opened before demand or staffing existed. Fix by closing rooms, shrinking the surface and returning to the founding cohort; do not add promotion.
- **Staff-dominated** - the team writes most messages, so members read instead of participating. Deliberately leave answerable questions for members, and route the team to reply after a delay.
- **Taxonomy sprawl** - a full channel tree at launch. Every empty room signals a dead community; merge back.
- **Audience split** - a new venue launched while the old space stays open. Migrate with a hard cutover and a redirect, or do not migrate.
- **Volunteer amnesia** - founding members recruited with a vague ask, gone in three weeks. Re-ask with a specific, time-boxed commitment.
- **Hidden ownership gap** - the owner's hours were never actually protected. This is a management fix, not a community fix; escalate rather than absorb it.
## Invocation examples
- _"Should we open a Discord for our API users?"_ - run the gates before discussing any platform; answer with a verdict, not a vendor.
- _"We've decided on Discourse, help us plan the November launch."_ - treat the venue as a hypothesis, still run the gates, and say plainly if the verdict is "not yet"; the date is the cheapest thing to move.
- _"How do we get our new community to critical mass?"_ - gates first (a room already opened without demand needs the fold-back conversation, not a seeding plan), then seeding and thresholds.
- _"Our Slack has 900 members and it's gone quiet."_ - not a launch question; route to the health skill unless the user is deciding whether to shut it down.
## Output
Produce a **Community Launch Brief**: a markdown document with these nine sections.
1. Verdict and evidence
2. Audience and outcome
3. Venue choice with rejected alternatives
4. Community model and target member mix
5. Seeding plan
6. First-90-days calendar
7. Thresholds and measurement plan
8. Fold-back criteria
9. Open risks
Present it one section at a time and get agreement before writing the next; a brief delivered whole invites a single "looks good" that hides disagreement on the parts that matter.
Every verdict line cites its evidence, every threshold says whether it is published or set here, and every rejected venue keeps its reason.
The template, a worked launch brief, a worked do-not-launch brief and a weak example to avoid are in [./references/launch-brief-template.md](./references/launch-brief-template.md).
If your environment has persistent memory, store the verdict, the venue choice with its reasoning, the thresholds and the fold-back condition - later community, content and metrics work builds on these decisions, and re-deriving them wastes the user's time.
## References
- samber/developer-relations-skills@devrel-strategy for where community sits among the other DevRel pillars
- samber/developer-relations-skills@devrel-budget-allocation for the launch's line-item cost against the program budget