Community Topic Scout

Use this skill when a creator wants to decide what community to build, what to name it, how to position it, or how to validate the topic before charging.

Inputs

Collect or infer:

• creator skills, lived experience, and repeatable workflows,
• audience they can credibly help,
• painful task or desired outcome,
• proof members can create in 20 minutes,
• topics to avoid,
• privacy boundaries,
• launch capacity for the next 7 days,
• paid ambition, if any.

If the user provides public benchmark data, use it as directional context only. Do not claim that visible member counts or public price metadata predict revenue.

Workflow

1. Identify 3 to 5 credible audience-topic pairs.
2. For each pair, define:
   • audience,
   • urgent problem,
   • first proof artifact,
   • why the creator can credibly lead it,
   • obvious competition or sameness risk.
3. Generate 10 community names using clear patterns:
   • Lab,
   • Sprint,
   • Studio,
   • Hub,
   • School,
   • Circle.
4. Score names for clarity, specificity, proof orientation, and hype risk.
5. Pick the best name and write:
   • one-line promise,
   • About-page opener,
   • first pinned post,
   • first 7-day proof challenge.
6. Define validation gates before any paid offer.

Output

Return:

• critical recommendation,
• ranked topic candidates,
• name shortlist with scores,
• selected name and one-line promise,
• first 7-day proof challenge,
• public-safe About opener,
• validation metrics,
• reject list.

Examples

Good public-safe inputs:

• "I help freelance bookkeepers turn messy client intake into a weekly checklist."
• "My audience is solo creators who already use public blog posts and want a repeatable clipping workflow."

Avoid inputs that require private source material, such as member lists, paid course lessons, private community posts, DMs, or exported customer records. Replace them with synthetic examples or user-owned notes before drafting.

Guardrails

• Do not scrape private communities, member lists, paid lessons, DMs, or hidden pages.
• Do not request, store, transform, or paste credentials, API keys, session cookies, payment data, private exports, or account recovery data.
• Do not promise income, growth, health, financial, legal, or education outcomes.
• Do not choose a topic only because a public benchmark has large visible member counts.
• Do not recommend a name that depends on another platform's trademark unless the user explicitly has rights and the final copy makes non-affiliation clear.
• Treat public benchmark patterns as examples, not market proof.
• Prefer proof-first names over guru, agency, or passive-learning names.