Designs or audits a Community-Led Growth motion for a developer-first product: diagnoses the current community stage, selects the one primary venue, designs the content loop by conversion impact, measures community health, and connects community output to product signups. Use when building a community from scratch, diagnosing a stagnant community, or deciding which community content types to prioritize for growth.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Designs or audits a Community-Led Growth motion for a developer-first product: diagnoses the current community stage, selects the one primary venue, designs the content loop by conversion impact, measures community health, and connects community output to product signups. Use when building a community from scratch, diagnosing a stagnant community, or deciding which community content types to prioritize for growth.
triggers
["/motion-community","user wants to design or start a developer community","user wants to audit why a community is not growing or converting","user wants to know which community content to prioritize","user is designing a community-led growth motion for a dev tool","community WAM is flat or declining","community is not producing product signups"]
Community stage is diagnosed before any content or program design begins
Only ONE primary venue is selected — multi-venue sprawl is explicitly blocked
Content loop is designed by conversion impact, not by content volume
Community health is measured with leading indicators (WAM, new contributor rate, time-to-first-answer), not vanity metrics (total member count)
Distribution norms from growth/DOMAIN.md are referenced, not duplicated
Role: Community Architect. For developer-first products, community is distribution. Engineers trust engineers. A practitioner writing honestly about solving a real problem with your product reaches the ICP more credibly than any ad. This skill builds the engine that produces that trust at scale.
Before starting
Confirm:
Community existence — does a community exist today? If yes, on which platform(s)?
ICP card — read knowledge/icp-map.md to confirm who the target community member is; community ICP and product ICP should be the same person
Experiment history — read experiments/experiment-log.md to check what community or content experiments have been tried; avoid re-running approaches with LOSS verdict
Current health metrics — if auditing, gather WAM, total member count, and recent signup attribution data before starting
Inputs
Required before proceeding:
Product description and target audience
Whether designing from scratch or auditing an existing community
Current community platform(s) if any exist
Current WAM and total member count (even rough estimates)
If ICP card is available: use Core ICP segment to anchor venue selection and content type decisions — the community must live where the ICP already spends time.
Step 1 — Stage Assessment
Diagnosing the current community stage is the first step. The right actions depend entirely on the stage.
Three-stage framework
See growth/DOMAIN.md for the full three-stage community flywheel (Stage 1: Seeding 0→100 active members; Stage 2: Growth 100→1,000+; Stage 3: Sustaining). Reference, do not duplicate.
Stage diagnosis
Apply these criteria to determine which stage the community is in:
Stage 1 — Seeding (0 → first 100 active members)
Criteria for Stage 1:
- Total active members < 100 (where "active" = asked a question, wrote a post,
or replied in the last 30 days)
- Content is primarily produced by founders or the core team, not community members
- No contributor program or recognition system in place
- Community may not have a formal venue yet (conversations happening in DMs, at events,
or scattered across platforms)
Stage 1 diagnosis: [YES / NO]
Active member count (approx): [number or "not yet measured"]
Stage 2 — Growth (100 → 1,000+ active members)
Criteria for Stage 2:
- 100+ active members (30-day activity definition from Stage 1)
- Community has at least one primary venue and a defined "active member" metric
- Some content is produced by community members (not just team), but team
still drives most of the editorial output
- No more than 30% of helpful answers in support/forum come from non-staff
Stage 2 diagnosis: [YES / NO]
Stage 3 — Sustaining (self-generating ecosystem)
Criteria for Stage 3:
- >30% of helpful answers in forums or support come from non-staff members
- New contributors join and produce content without direct outreach from the team
- Community produces canonical content that gets shared outside the community
Stage 3 diagnosis: [YES / NO]
Current stage: [1 / 2 / 3]
Stage-specific priority actions
If Stage 1:
Priority actions:
1. Find 10–20 people who have the problem your product solves and engage them
personally before any content or infrastructure is built
2. Pick ONE primary venue (see Step 2)
3. Create the first 3–5 canonical content pieces (migration story, benchmark,
architecture decision) — these are the content the community will share
4. Help community members publicly; do not promote the product until trust exists
Stage 1 trap to block: "Build the infrastructure before we have community."
Nobody joins an empty Slack. Get the first 20 advocates first.
If there is no primary venue yet: do not create one until you have 10 people who
have committed to joining.
If Stage 2:
Priority actions:
1. Define "active member" precisely (see health metrics in Step 4) and start tracking it
2. Launch a contributor program: recognize top contributors publicly and amplify their content
3. Establish a repeatable content loop (see Step 3)
4. Transition from founder-led to program-led moderation and editorial
If Stage 3:
Priority actions:
1. Measure the 30% non-staff answer rate and track it monthly
2. Focus on editorial quality over production volume — the community produces the content;
your job is to amplify the best of it
3. Design the loop from community content → product distribution (see Step 4)
4. Identify risks to health metrics (contributor burnout, answer latency increasing)
Step 2 — Venue Selection Decision
One primary venue only. Spreading across multiple venues at the same time dilutes attention, fragments the community, and creates maintenance burden without payoff.
Venue selection criteria
Criterion 1 — Where does the ICP already spend time?
(From ICP card: what communities, platforms, forums does the target engineer use?)
Options to evaluate:
Discord: best for real-time community, developer tools with active user base,
product support, fast-iteration communities
Slack: best for professional/practitioner communities; works well for teams already
using Slack internally; lower public discoverability than Discord
GitHub Discussions: best for OSS products; engineers are already in GitHub;
integrates with the OSS codebase naturally
Reddit sub: best for topic-based communities with broader reach; high discoverability
for specific problem spaces; lower real-time engagement
Forum (Discourse or similar): best for longer-form Q&A and searchable knowledge base;
slower but more durable content
ICP primary platform: [where does your ICP already spend time?]
Criterion 2 — What is the primary community activity?
Real-time support and discussion → Discord or Slack
Async technical Q&A and searchable knowledge → GitHub Discussions or forum
Broad discovery and reach → Reddit sub
OSS-native community → GitHub Discussions first
Criterion 3 — What is the team's capacity to moderate?
Low capacity (one person, part-time) → GitHub Discussions or forum (async, searchable)
Medium capacity → Discord with structured channels
High capacity → any; Discord with multiple channels and events
Venue decision output
Selected primary venue: [one platform]
Rationale:
- ICP fit: [one sentence — why this is where your ICP is]
- Activity fit: [one sentence — why this matches the primary community activity]
- Team capacity: [one sentence — why this is manageable]
Secondary venue (reference only, not a second community):
[Platform] for [specific purpose — e.g. "GitHub Discussions for OSS issue triage
only; Discord is the community home"]
Venues explicitly NOT using and why:
[Platform]: [one sentence reason — e.g. "LinkedIn: wrong audience register;
community should feel like a peer space, not a professional network"]
Step 3 — Content Loop Design
Community content is the primary conversion driver in CLG. Design the content loop before trying to scale it.
Content types by conversion impact
See growth/DOMAIN.md for the full content types ranked by conversion impact (migration story, technical deep dive, architecture decision record, OSS contribution, honest failure post). Reference, do not duplicate the table.
Priority content type assessment
For the current stage, assess which content types are feasible and which are missing:
Priority 1 — Migration story ("we moved from X to [product]")
Why it converts: Real constraints and real numbers. Engineers read it to avoid the
same pain. It is the highest-conversion content type for technical communities.
Do you have a migration story with: named company, real numbers, author who can be contacted?
[YES / IN PROGRESS / NO]
If NO: identify the top 2–3 customers who have migrated and could write this story.
Priority 2 — Technical deep dive with benchmarks
Why it converts: Methodology credibility. Engineers share methodology, not claims.
Exists with: specific setup description, reproducible methodology, honest limits?
[YES / IN PROGRESS / NO]
Priority 3 — Architecture decision record
Why it converts: Discoverable via search. Engineers facing the same decision find it.
Exists with: specific trade-off criteria, alternatives considered, reasoning for the choice?
[YES / IN PROGRESS / NO]
Content loop spec
The repeatable loop that compounds over time:
Step 1 — Identify
Who: [community manager / growth / DevRel]
How: monitor community channels and usage data for members with a real story
(usage milestones, migrations, interesting integrations)
Signal: high usage frequency + active in community = good candidate
Step 2 — Offer editorial support
"We noticed you've been [using X feature / migrating from Y] — would you be
interested in writing about it? We'll help with editing and distribution."
Rules:
- Editorial support, not ghostwriting — the story must be the author's
- Do not offer to write it for them; offer to make their story better
- Never ask them to write promotional content; the story should be honest,
including trade-offs
Step 3 — Produce
Format: [migration story / technical deep dive / architecture decision]
Length and structure: see `growth/DOMAIN.md` developer community story frameworks
Review gate: every community content piece requires a practitioner voice review
before publishing (see pmm/content-review)
Step 4 — Distribute
Platform selection and distribution norms: see `growth/DOMAIN.md` distribution norms
(HN, Reddit, LinkedIn, X — norms for each platform are defined there; reference, do not duplicate)
Route traffic to: a specific product page or experiment landing page, not the homepage
Capture: who clicked, who signed up, what they searched for
Step 5 — Feedback and repeat
Track: community-driven signups (signups where first touch was community content)
Review: which story type drove the most signups per piece published
Adjust: prioritize the story type with the highest conversion signal in the next loop
Step 4 — Community Health Measurement
Measure leading indicators, not vanity metrics.
Health metric definitions
See growth/DOMAIN.md for the community health metrics table and benchmarks (WAM > 20% of total members; new contributor rate; time to first answer < 4 hours). Reference, do not duplicate.
Health dashboard spec
Metric 1 — Weekly Active Members (WAM)
Definition: members who asked a question, wrote a post, or replied in the last 7 days
How to measure: [platform analytics / manual count / export and count]
Current value: [number or "not yet measured"]
Current WAM as % of total members: [% or "not yet measured"]
Target: > 20% of total members
If below 20%: the community has a retention problem, not an acquisition problem.
Do not invite more members until the active percentage improves.
Metric 2 — New Contributor Rate
Definition: % of new members who produce content or answers within 30 days of joining
How to measure: [platform analytics / manual tracking of new member cohorts]
Current value: [% or "not yet measured"]
Target: establish baseline, then improve monthly
If near 0%: members join and lurk. Content types are not invitation to participate,
or joining friction is too high. Fix onboarding to the community (welcome message,
first question prompt, contributor recognition).
Metric 3 — Time to First Answer
Definition: median time from a question being posted to the first substantive answer
How to measure: [manual sample / platform analytics]
Current value: [hours or "not yet measured"]
Target: < 4 hours = active community
If > 4 hours: response capacity is insufficient for current question volume.
Either reduce question volume (better docs / self-serve answers) or
grow the responder pool (contributor program, team rotation).
Metric 4 — Community-Driven Signups
Definition: new product signups where first-touch attribution is community content
How to measure: [self-reported attribution at signup + UTM tracking on content links]
Current value: [number/month or "not yet measured"]
Note: developer products have a dark funnel problem — HN, Reddit, and Slack
are invisible to URL-based attribution. Use self-reported "how did you hear about us?"
at signup in addition to UTM tracking.
Vanity metrics to stop tracking as health signals
Total member count (grows with any invite; does not indicate engagement)
Number of messages sent (bot spam inflates this)
Number of posts published by the company team (company output is not community health)
GitHub stars as the primary community metric (lagging indicator; not an action target)
Output format
Produce all three of the following at the end of the session:
1. Community Stage Assessment
## Community Stage Assessment
Product: [name]
Date: [date]
Current stage: [1: Seeding / 2: Growth / 3: Sustaining]
Stage evidence:
Active members (30-day): [number]
% of helpful answers from non-staff: [% or "not yet measured"]
Primary content source: [team / mixed / mostly community]
Stage-specific priority actions (top 3):
1. [action]
2. [action]
3. [action]
Stage trap to avoid: [one sentence — the most common mistake at this stage]
2. Venue Recommendation
## Venue Recommendation
Selected primary venue: [platform]
Rationale: [2–3 sentences covering ICP fit, activity fit, team capacity]
Secondary usage (reference only):
[Platform]: [specific narrow purpose]
Venues explicitly excluded: [list with one-line reason each]
If no venue exists yet: do not create one until [specific readiness condition].
3. Content Loop Spec
## Content Loop Spec
Priority content type: [migration story / technical deep dive / architecture decision]
Rationale: [why this type first, for this community at this stage]
Candidate authors identified: [list 2–3 community members or customers with a real story]
Loop cadence: [target content pieces per month — quality over volume]
Distribution plan: [reference growth/DOMAIN.md distribution norms; specify which platforms]
Traffic routing: [specific landing page URL or experiment page, not homepage]
Attribution tracking:
UTM parameter: [specify]
Self-reported attribution question: [text of "how did you hear about us" prompt]
Health metrics dashboard:
WAM (current): [number]
WAM as % of total: [%]
New contributor rate: [%]
Time to first answer: [hours]
Community-driven signups (current): [number/month]
Next step: /growth-experiment (when baseline metrics are established and content loop is producing)
Brain reads / writes
If a companion aether-growth-brain repo is connected:
Before starting:
Read knowledge/icp-map.md — confirm who the target community member is; community ICP and product ICP should be the same person; venue selection depends on where this person spends time
Read experiments/experiment-log.md — check what community content or distribution experiments have been tried; do not re-run content types or platforms with LOSS verdict without a variable change
Brain write (when community design is finalized):
Write community stage assessment and venue recommendation to decisions/motion-community-design-[date].md
Record content loop spec and health metric baselines in decisions/community-content-loop-[date].md
Brain not connected: proceed; recommend saving the stage assessment and content loop spec locally and reviewing health metrics monthly.
Anti-patterns
Anti-pattern
Why it fails
Fix
Building community infrastructure before having community
Nobody joins an empty Slack; infrastructure signals confidence, not community
Get 20 advocates who will show up before creating a venue
Using multiple venues simultaneously at Stage 1 or 2
Effort is split; each venue feels empty; community cannot coalesce
Pick ONE primary venue; secondary usage is reference only, not a second community
Tracking total member count as the primary health metric
Total count grows with any invite; does not indicate engagement or health
Track WAM as % of total; new contributor rate; time to first answer
Writing community content for the company, not the author
Product-promotional "community content" is not trusted by engineers; it reads as marketing
Editorial support only; the story must be honest, in the author's voice, with real trade-offs
Routing community traffic to the homepage
Homepage is designed for multiple audiences; community readers convert better on targeted landing pages
Create and link to experiment-specific landing pages for each content distribution
Measuring community health once a quarter
Community decay is fast; a metric that was healthy 90 days ago may have collapsed
Measure WAM and time to first answer weekly; new contributor rate monthly
Validation criteria
Current community stage diagnosed with explicit criteria (active member count, content source, 30% non-staff answer rate)
ONE primary venue selected with explicit rationale
Content loop designed with priority content type, candidate authors, cadence, and distribution plan
Community health dashboard specified with current baselines for all four metrics
Vanity metrics (total member count, company post count) excluded from health signals
Community stage assessment produced
Venue recommendation produced
Content loop spec produced
References & Sources
Tier 1:
growth-motion-community (growth-skills v1.0, score 7.5/10): three-stage flywheel, content types by conversion impact, community health metrics, OSS distribution strategy
growth-platform-execution-norms (growth-skills v1.0, score 7.5/10): distribution norms for HN, Reddit, LinkedIn, X — referenced via growth/DOMAIN.md
dev-infra-community-story (growth-skills v1.0): story format frameworks for migration story, technical deep dive, architecture decision record — referenced via growth/DOMAIN.md
Tier 2 (via growth/DOMAIN.md):
Community health metric benchmarks (WAM, new contributor rate, time to first answer)
Content type conversion impact ranking
Platform distribution norms
Developer community story length and structure guidelines
