rsc-universal 0.1.1

package/skills/cold-outreach/scripts/verify.sh

@@ -0,0 +1,170 @@
+#!/usr/bin/env bash
+#
+# verify.sh — structural guardrail for a drafted cold email / sequence.
+#
+# WHAT IT DOES (read-only; never edits or writes a file)
+#   Static, network-free checks over ONE draft file you point it at (a cold
+#   email or a multi-step sequence in plain text / markdown):
+#     1. First-touch length: the first message block's body is over ~80 words
+#        -> warn (soft; brevity is a strong preference, not a law).
+#     2. Single binary CTA: more than one question-mark line ("?") in the first
+#        touch -> warn (a cold first touch should ask exactly one binary thing).
+#     3. Opt-out present: no unsubscribe / opt-out / "reply stop" line anywhere
+#        -> FAIL (CAN-SPAM/GDPR hard requirement).
+#     4. Postal address present: no street-style postal-address placeholder
+#        (a line with a digit + a street/PO token, or an explicit
+#        {{address}} / [address] placeholder) -> FAIL (CAN-SPAM requirement).
+#     5. Banlist: spam-trigger + AI-tell phrases ("I hope this email finds you
+#        well", "just circling back", "just following up", "act now",
+#        "100% free", "free guide", "guarantee(d)", "limited time",
+#        "to whom it may concern", "I came across your") -> warn each hit.
+#     6. Unfilled template slots ({{...}}, [SLOT], ???) outside the address
+#        line -> warn (fill before sending).
+#
+#   Only #3 and #4 are hard failures. Everything else is a warning. A clean OR
+#   empty/missing-content file exits 0 — never a false failure.
+#
+# HOW TO RUN (inside YOUR project, not the skills repo)
+#   ./verify.sh draft.md                 # warnings + hard checks
+#   ./verify.sh draft.md --ceiling 100   # raise the first-touch word ceiling
+#   ./verify.sh draft.md --strict        # treat warnings as failures (CI gate)
+#
+# EXIT CODES
+#   0  clean, warnings only (without --strict), or empty/missing-content file
+#   1  a hard failure (no opt-out, or no postal address) — or any warning under --strict
+#   2  bad usage (no file given, or file does not exist)
+#
+# Runs on stock macOS bash 3.2: no mapfile, no associative arrays, no bc.
+
+set -euo pipefail
+
+if [ -t 1 ]; then
+  RED=$'\033[31m'; GREEN=$'\033[32m'; YELLOW=$'\033[33m'; NC=$'\033[0m'
+else
+  RED=''; GREEN=''; YELLOW=''; NC=''
+fi
+
+warn_count=0; fail_count=0
+ok()   { printf '%s[ ok ]%s %s\n' "$GREEN"  "$NC" "$*"; }
+warn() { printf '%s[warn]%s %s\n' "$YELLOW" "$NC" "$*"; warn_count=$((warn_count + 1)); }
+fail() { printf '%s[fail]%s %s\n' "$RED"    "$NC" "$*"; fail_count=$((fail_count + 1)); }
+
+usage() { sed -n '2,42p' "$0" | sed 's/^# \{0,1\}//'; }
+
+FILE=""
+CEILING=80
+STRICT=0
+while [ $# -gt 0 ]; do
+  case "$1" in
+    -h|--help) usage; exit 0 ;;
+    --ceiling) CEILING="${2:-80}"; shift 2 ;;
+    --strict) STRICT=1; shift ;;
+    -*) printf '%sunknown option: %s%s\n' "$RED" "$1" "$NC" >&2; usage; exit 2 ;;
+    *) if [ -z "$FILE" ]; then FILE="$1"; fi; shift ;;
+  esac
+done
+
+if [ -z "$FILE" ]; then
+  printf '%sno draft file given%s\n' "$RED" "$NC" >&2; usage; exit 2
+fi
+if [ ! -f "$FILE" ]; then
+  printf '%sfile not found: %s%s\n' "$RED" "$FILE" "$NC" >&2; exit 2
+fi
+
+# Empty / whitespace-only file: nothing to check, do not false-fail.
+if [ ! -s "$FILE" ] || ! grep -q '[^[:space:]]' "$FILE" 2>/dev/null; then
+  ok "empty file — nothing to check"
+  exit 0
+fi
+
+printf 'cold-outreach verify — %s (ceiling=%s words)\n\n' "$FILE" "$CEILING"
+
+# --- isolate the first-touch block --------------------------------------------
+# Heuristic: the first touch ends at the first "STEP 2", "Day +", "Follow-up",
+# or a markdown heading after content. We grab everything up to that marker,
+# then strip subject/footer-ish lines for the word count.
+FIRST_BLOCK="$(awk '
+  NR==1 {seen=0}
+  /^[[:space:]]*(STEP[[:space:]]*2|Follow[- ]?up[[:space:]]*2|Day[[:space:]]*\+|DM[[:space:]]*2|##[[:space:]])/ && seen {exit}
+  /[^[:space:]]/ {seen=1}
+  {print}
+' "$FILE")"
+
+# Body words: drop subject lines, unsubscribe/footer lines, and address lines.
+FIRST_WORDS="$(printf '%s\n' "$FIRST_BLOCK" \
+  | grep -iv -e '^[[:space:]]*subject:' -e '^[[:space:]]*asunto:' \
+             -e 'unsubscribe' -e 'opt[- ]out' -e 'reply "stop"' -e 'reply stop' \
+  | tr -s '[:space:]' '\n' | grep -c '[^[:space:]]' || true)"
+
+if [ "${FIRST_WORDS:-0}" -gt "$CEILING" ]; then
+  warn "first touch is ~${FIRST_WORDS} words (over the ${CEILING}-word ceiling) — tighten it"
+else
+  ok "first-touch length ~${FIRST_WORDS} words (<= ${CEILING})"
+fi
+
+# --- single binary CTA in the first touch -------------------------------------
+CTA_LINES="$(printf '%s\n' "$FIRST_BLOCK" | grep -c '?' || true)"
+if [ "${CTA_LINES:-0}" -gt 1 ]; then
+  warn "first touch has ${CTA_LINES} question lines — a cold first touch should ask exactly one binary thing"
+elif [ "${CTA_LINES:-0}" -eq 0 ]; then
+  warn "first touch has no question-mark CTA — add one binary yes/no ask"
+else
+  ok "first touch has exactly one CTA line"
+fi
+
+# --- opt-out present (hard) ----------------------------------------------------
+if grep -Eiq 'unsubscribe|opt[- ]out|reply[[:space:]]+["'\'']?stop|darse de baja|cancelar la suscripci' "$FILE"; then
+  ok "opt-out / unsubscribe line present"
+else
+  fail "no opt-out / unsubscribe line found — CAN-SPAM/GDPR requires a working opt-out"
+fi
+
+# --- postal address present (hard) --------------------------------------------
+# Accept either an explicit placeholder or a line that looks like a street addr.
+if grep -Eiq '\{\{[[:space:]]*(postal[_ ]?)?address|\[[[:space:]]*(postal[_ ]?)?address' "$FILE" \
+   || grep -Eiq '[0-9]+[[:space:]].*(street|st\.|ave|avenue|road|rd\.|blvd|suite|ste\.|p\.?o\.? box|calle|carrer|via)' "$FILE"; then
+  ok "postal address (or placeholder) present"
+else
+  fail "no physical postal address found — CAN-SPAM requires one (a {{address}} placeholder counts)"
+fi
+
+# --- banlist: spam-trigger + AI-tell phrases ----------------------------------
+BAN='i hope this email finds you well|just circling back|just following up|circling back|act now|100% free|free guide|guarantee|limited time|to whom it may concern|i came across your|dear sir or madam'
+HITS="$(grep -Eio "$BAN" "$FILE" 2>/dev/null | sort -u || true)"
+if [ -n "$HITS" ]; then
+  while IFS= read -r h; do
+    [ -n "$h" ] && warn "banned phrase present: \"$h\" (spam-trigger / AI-tell — rewrite)"
+  done <<EOF
+$HITS
+EOF
+else
+  ok "no banned spam/AI-tell phrases"
+fi
+
+# --- unfilled template slots (ignore the address-placeholder convenience) -----
+SLOTS="$(grep -Eo '\{\{[^}]*\}\}|\?\?\?|\[[A-Z_]{3,}\]' "$FILE" 2>/dev/null \
+  | grep -Eiv '\{\{[[:space:]]*(postal[_ ]?)?address|\[[[:space:]]*(POSTAL[_ ]?)?ADDRESS' \
+  | sort -u || true)"
+if [ -n "$SLOTS" ]; then
+  SLOT_N="$(printf '%s\n' "$SLOTS" | grep -c '[^[:space:]]' || true)"
+  warn "${SLOT_N} unfilled template slot(s) remain (e.g. $(printf '%s' "$SLOTS" | head -1)) — fill before sending"
+else
+  ok "no unfilled template slots"
+fi
+
+# --- summary ------------------------------------------------------------------
+printf '\n'
+if [ "$fail_count" -gt 0 ]; then
+  printf '%s%d hard failure(s), %d warning(s)%s\n' "$RED" "$fail_count" "$warn_count" "$NC"
+  exit 1
+fi
+if [ "$warn_count" -gt 0 ]; then
+  if [ "$STRICT" -eq 1 ]; then
+    printf '%s%d warning(s) — failing under --strict%s\n' "$YELLOW" "$warn_count" "$NC"
+    exit 1
+  fi
+  printf '%s%d warning(s), 0 hard failures%s\n' "$YELLOW" "$warn_count" "$NC"
+  exit 0
+fi
+printf '%sall checks passed%s\n' "$GREEN" "$NC"
+exit 0

package/skills/community/SKILL.md

@@ -0,0 +1,225 @@
+---
+name: community
+description: "Use when building or running a persistent two-way community space — Discord, Telegram, or Circle — and you need structure, onboarding, moderation, rituals, growth, or health metrics; covers picking the platform, standing up channels/roles/spaces, the rules/verification gate, the 3-layer moderation stack, an operating-rhythm of rituals, lurker-to-contributor growth loops, and the few metrics that prove it is alive. Triggers: 'set up our Discord server', 'our community is a graveyard / dead chat', 'we keep getting spam raids and scam DMs', 'Discord vs Telegram vs Circle', 'design community rituals / weekly cadence', 'how do I get lurkers to post', 'community onboarding flow', 'community health metrics', 'monta la comunitat de Discord', 'la comunidad está muerta, nadie escribe'. NOT customer churn-prevention for a paid product (that is retention), NOT one-to-many broadcast email (that is newsletter), and NOT running a single live event (that is webinar)."
+tags: [community, discord, telegram, moderation, growth, rituals]
+recommends: [retention, newsletter, social-publisher, brand-voice, whatsapp-telegram, webinar]
+profiles: []
+origin: risco
+---
+
+# community
+
+Run the community like a **product with a job**, not a vanity chat room. The space — a Discord server, a Telegram group+channel, a Circle — is the product. **Onboarding is activation, rituals are the feature, moderation is reliability, and one north-star metric tied to your purpose is the only number that matters.** A room with 5,000 silent members is a failed product, not a big one. Design the system around the conversation, not the conversation itself.
+
+## When to use
+
+- Standing up a new Discord / Telegram / Circle from zero: structure, roles, onboarding, rules.
+- A community exists but is a graveyard — lurkers only, no rhythm, nobody posts — needs rituals + re-activation.
+- Moderation is on fire: spam waves, raids, scam DMs, bans applied by mood, no incident process.
+- Choosing between Discord vs Telegram vs Circle for a given audience, purpose, and monetization model.
+- Designing a growth loop that compounds (referrals, intro rituals, partner cross-posts) instead of buying dead members.
+- Defining community health metrics and targets and instrumenting the few that prove the thing is alive.
+
+## When NOT to use — route instead
+
+| The ask | Route to |
+|---|---|
+| Stop *paying customers of a product/SaaS* from churning (win-back, lifecycle, NPS) | `retention` |
+| Write the one-to-many broadcast email that nurtures the list | `../newsletter/SKILL.md` |
+| Schedule / cross-post public posts across X, LinkedIn, Instagram | `../social-publisher/SKILL.md` |
+| Run a single timed live event end-to-end (registration, speakers, replay) | `webinar` |
+| Build an automated support desk / ticket triage | `customer-support` |
+| Actually code or host the Discord/Telegram bot (gateway, slash handlers) | `whatsapp-telegram`, `automation-flows` |
+| Define the voice/name/tone the community speaks in | `../brand-voice/SKILL.md` |
+
+You own the **persistent, two-way space and its ongoing operating rhythm.** The boundary that bites most: `retention` keeps *buyers of a product* from churning; you keep *members of a shared space* active and contributing. They rhyme (cohorts, re-activation) but the subject differs — a SaaS seat vs a Discord membership. When a near-miss is really "send a broadcast," it is `newsletter`/`social-publisher`; when it is "stop churn of buyers," it is `retention`; when it is "run an event," it is `webinar`.
+
+## Step 0 — Purpose & north-star gate (hard rule)
+
+**Do not design a single channel until you have (a) a one-line purpose and (b) one business metric tied to it.** Why: a community without a job becomes a dead chat — there is no signal to design toward, so you sprawl channels and beg for activity. This is the most common cause of graveyards.
+
+If either is missing, **STOP and ask one focused batch**, then proceed:
+
+> 1. In one sentence, what is this community *for* — and for whom?
+> 2. What single business outcome does it move? (support deflection, retention uplift, expansion revenue, qualified referrals — pick ONE)
+
+Bad → Good:
+
+```text
+Bad:  "Set up a Discord for our users." → 14 channels, no purpose, silent in 3 weeks.
+Good: Purpose = "where indie game-devs trade WIP feedback so free players become paying supporters."
+      North-star = monthly free→supporter conversions sourced from the server.
+```
+
+Everything below is derived from those two lines. If a channel, ritual, or metric does not serve the purpose or move the north-star, cut it.
+
+## Pick the platform — decision table
+
+| Platform | Best for | Real-time chat | Broadcast | Monetization | Moderation maturity | Cost |
+|---|---|---|---|---|---|---|
+| **Discord** | Active, real-time builder/gamer/dev communities | Strong | Weak (announcement channels only) | Indirect (roles/Patreon links) | High — native AutoMod + bot ecosystem | Free |
+| **Telegram** (group **+** channel hybrid) | Mobile-first, fast-growing, announce-heavy audiences | Good | Strong (channel = one-way broadcast) | Weak native | Medium — native ML anti-spam >200 members + bots | Free |
+| **Circle** | Paid memberships bundling courses/events | Weak | Good | Strong (built-in payments + tiered Spaces) | Medium | Professional ~$89–129/mo → Business ~$199–219 → Circle Plus ~$419+ + 0.5–2% Circle fee on top of Stripe's 2.9%+$0.30 |
+
+Decision rules (pick the *purpose*, not the logo):
+- **Need persistent real-time conversation and free?** → Discord. It is the deepest moderation toolset and the strongest two-way default.
+- **Audience lives on mobile and you broadcast a lot?** → Telegram, run the hybrid: a **channel** for announcements + a **linked group** for discussion. This is the 2026 standard; a bare group has no broadcast lane and a bare channel has no conversation.
+- **You are charging for membership and bundling courses/events?** → Circle. But see the anti-pattern: do not monetize before activation works.
+
+Per-platform setup depth (AutoMod filters, verification levels, anti-spam tiers, plan ladder) is in `references/platform-playbooks.md`.
+
+## Structure & onboarding = activation
+
+Keep the structure **minimal**. Why: empty channels signal a dead room; people pattern-match "nobody's here" and leave. Start with the fewest channels the purpose needs (often 4–6: welcome/rules, intros, one core topic, help, off-topic, announcements) and split a channel only when an existing one is *demonstrably overflowing*.
+
+The onboarding path is an activation funnel. Drive every new member to a **first meaningful action** through a short, gated path:
+
+1. **Role-on-join** — pick a role/interest, which personalizes which channels they see. Why: a tailored, smaller room feels alive; the firehose feels dead.
+2. **Rules/membership gate** — on Discord, Rules Screening / Membership Screening blocks talking and DMs until rules are acknowledged. Why: it stops drive-by spam *and* forces a first deliberate click.
+3. **Intro with a prompt** — not "introduce yourself" (blank-page freeze) but a 3-field prompt. Why: prompted intros get answered; open ones get skipped.
+4. **Point to where-to-ask** — one obvious channel for "I need help." Why: time-to-first-response is a core health metric and it starts here.
+
+Bad → Good intro channel:
+
+```text
+Bad:  #introductions — "Say hi and introduce yourself!"  → blank-page paralysis, 4% post.
+Good: #introductions — pinned prompt: "(1) what you're building, (2) what you're stuck on,
+       (3) one thing you can help others with." → reply with the right role-ping. Activation jumps.
+```
+
+## Moderation — the 3-layer stack
+
+Moderation is reliability. The canonical stack is **native → bot → human**, and you scale layers by size, never skip the native layer.
+
+1. **Native** — Discord AutoMod (one Commonly-Flagged-Words preset rule + up to 6 custom keyword rules, each filter holding up to 1,000 terms, plus a mention-spam cap configurable up to 50 unique mentions/message) and an explicit **verification level** (Medium = verified email + 5-min-on-server before talking). Telegram: native ML anti-spam kicks in for groups **>200 members** (with an "Aggressive" auto-delete mode); for **≤30 messages/hour, slow-mode alone** is the right zero-setup control; add a CAPTCHA-on-join gate (button/math/question, e.g. Shieldy) as the raid wall.
+2. **Bot** — a specialized moderation bot for raid detection, scam-link filtering, and audit logs.
+3. **Human** — named mods, an escalation path, and a written ban policy.
+
+Size-tiered config (Discord, per Discord's own size guidance):
+
+| Server size | Native | Bot layer | Human |
+|---|---|---|---|
+| < 1,000 | AutoMod + Medium verification | optional | 1–2 mods |
+| > 1,000 | AutoMod + custom keyword rules | add one specialized bot | rota of mods |
+| > 10,000 | + Commonly-Flagged filter on | robust multi-tool bots | mod team + on-call |
+| > 100,000 | full filters + raid mode | multiple specialized bots | tiered mod org |
+
+Incident + ban policy (write these down before you need them):
+- **Ban policy is a rubric, not a mood** — define warn → mute → kick → ban thresholds and what triggers each. Why: inconsistent bans destroy trust faster than the spam did.
+- **Raid runbook** — who flips lockdown (slow-mode + raise verification + pause invites), who triages, where it is logged.
+- **Scam-DM stance** — pin a "we will never DM you first" notice; AutoMod-flag known scam phrases.
+
+Filter specifics, verification levels, and bot picks by tier live in `references/platform-playbooks.md`.
+
+## Rituals — the operating rhythm
+
+**Predictable cadence beats sporadic heroics.** Why: members learn when to show up only if there is something to show up *for*; rhythm is the feature that pulls lurkers back. Install a small set of recurring beats and run them on time, every time.
+
+Sample weekly cadence:
+
+| Day | Ritual | Friction |
+|---|---|---|
+| Mon | "What are you working on this week?" thread | Low — one reply |
+| Wed | Office hours / AMA in a voice or thread slot | Medium — opt-in |
+| Fri | "Wins of the week" — share + react | Low — a reaction counts |
+
+Design for **low-friction participation**: polls, emoji reactions, and *opt-in* role pings. The over-pinging trap: blasting `@everyone` for non-urgent posts. Why it backfires — over-pinging trains members to mute the server, and a muted member is functionally gone. Use a dedicated opt-in "announcements" role and reserve `@everyone` for genuine all-hands moments.
+
+A ritual template library and the full cadence rationale are in `references/metrics-and-rituals.md`.
+
+## Growth — loops, not buys
+
+Build loops that compound, not headcount that decays:
+- **Referral loop** — make inviting a friend a one-tap, rewarded action tied to a role/perk.
+- **Intro loop** — every prompted intro is a hook other members reply to, pulling the newcomer into a thread on day one.
+- **Partner cross-post** — trade shout-outs with an adjacent community whose audience overlaps but does not compete.
+
+**90-9-1 is a range, not a ceiling.** The old "1% rule" (90% lurk, 9% occasional, 1% drive activity) is a *starting observation*, not a law — healthier communities skew far more active (real profiles like 55-30-15 and 17-57-26). Design to **move lurkers up a tier** (prompts, easy reactions, direct asks), do not accept 90% lurkers as fixed.
+
+```text
+Bad:  Buy 2,000 members from a growth service to "look big."  → DAU/MAU craters,
+       signal drowns in silence, real members read the room as dead and leave.
+Good: Run a referral ritual + prompted intros. 200 members who each reply
+       in week one beats 2,000 who never speak.
+```
+
+Bought or inactive members are **negative-value**: they dilute every signal, wreck DAU/MAU, and make the room *look* dead to the people you actually want.
+
+## Metrics & health
+
+Three clusters plus exactly one business metric. Steer on these, not on raw member count.
+
+| Metric | What it tells you | Target |
+|---|---|---|
+| DAU/MAU stickiness | How often members come back | Floor ≥ 20%; social/messaging band ~50–80% |
+| 30/60/90-day cohort retention | Whether onboarding actually activates | Track each cohort vs the last |
+| Returning-member ratio | Rhythm is working | Trending up |
+| Time-to-first-response (TTFR) | A newcomer's first experience | Minutes-to-low-hours, the lower the better |
+| Answered rate | Questions don't die unanswered | → 100% |
+| **One business metric** (purpose-tied) | The only number that justifies the work | Set in Step 0 |
+
+The one business metric is a menu — **pick exactly one** that matches your purpose: support deflection, retention uplift, expansion revenue, or qualified referrals. Review the scorecard on a fixed cadence (weekly glance, monthly cohort read). Benchmark depth and metric definitions are in `references/metrics-and-rituals.md`.
+
+## The artifact you emit
+
+Produce two files the user can apply directly: a `community-plan.md` (prose: purpose, platform rationale, structure, growth, metrics) and a machine-checkable `moderation-config.yaml`:
+
+```yaml
+platform: discord            # discord | telegram | circle
+purpose: "where indie game-devs trade WIP feedback so free players become paying supporters"
+north_star_metric: "monthly free→supporter conversions sourced from the server"
+onboarding_path:
+  - role-on-join
+  - rules-gate
+  - prompted-intro
+  - where-to-ask
+moderation:
+  layers:
+    native: "AutoMod preset + custom keyword rules, Medium verification"
+    bot: "specialized raid + scam-link bot"
+    human: "2 named mods, written ban rubric"
+rituals:
+  - name: "WIP Mondays"
+    cadence: "weekly"
+  - name: "Wins Fridays"
+    cadence: "weekly"
+```
+
+Then validate it:
+
+```bash
+scripts/verify.sh path/to/moderation-config.yaml
+```
+
+`verify.sh` checks the required keys exist, that `north_star_metric` is non-empty, that all three moderation layers are declared, and that at least one ritual has a cadence — it catches the most common defect (a "plan" with no purpose, no mod layers, or no rhythm).
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails | Do instead |
+|---|---|---|
+| Channel sprawl on day one | Empty channels read as "dead"; people leave | Start 4–6; split only on demonstrated overflow |
+| No purpose / no north-star | Nothing to design toward → graveyard | Run Step 0 gate before any structure |
+| `@everyone` for non-urgent posts | Trains members to mute → functionally gone | Opt-in announce role; reserve `@everyone` |
+| Buying members to "look big" | Negative-value: dilutes signal, wrecks DAU/MAU | Referral + intro loops; activate the real ones |
+| Ban-by-mood | Inconsistency destroys trust | Written warn→mute→kick→ban rubric |
+| Treating 90% lurkers as permanent | Leaves activation on the table | 90-9-1 is a range; move lurkers up a tier |
+| Monetizing on Circle before activation works | Charging for a dead room churns instantly | Prove rhythm + retention, then gate/monetize |
+| Broadcasting in a two-way space | Wrong tool; kills conversation | One-to-many → `../newsletter/SKILL.md` / `../social-publisher/SKILL.md` |
+
+## Launch-readiness checklist
+
+Gate before "go live":
+
+- [ ] Purpose written in one line **and** one north-star business metric chosen (Step 0).
+- [ ] Platform chosen by decision rule, not vibes.
+- [ ] ≤ ~6 channels/spaces, each justified by the purpose.
+- [ ] Onboarding path wired: role-on-join → rules gate → prompted intro → where-to-ask.
+- [ ] All 3 moderation layers configured (native + bot + human) sized to expected scale.
+- [ ] ≥ 1 ritual scheduled with an explicit cadence.
+- [ ] North-star + ≥ 1 health metric (TTFR or DAU/MAU) instrumented.
+- [ ] `community-plan.md` + `moderation-config.yaml` emitted and `verify.sh` passes.
+
+## References
+
+- `references/platform-playbooks.md` — per-platform setup depth: Discord (AutoMod filters, verification levels, Rules/Membership Screening, Onboarding, bots by size), Telegram (group+channel hybrid, native anti-spam >200, slow-mode, CAPTCHA bots), Circle (Spaces, 2026 plan ladder + fees, monetization gating).
+- `references/metrics-and-rituals.md` — metric definitions + benchmarks (DAU/WAU/MAU stickiness, cohort retention, TTFR, answered rate, returning-member ratio, the business-metric menu), the 90-9-1 reality, and a ritual template library + sample weekly calendar.

package/skills/community/evals/README.md

@@ -0,0 +1,3 @@
+# Evals — community
+
+`cases.yaml` is a judging harness, not an executable test suite. Run it with a human or an LLM judge. The `should_trigger` and `should_not_trigger` cases check routing discipline: each `should_trigger` prompt should pull in this skill (including the non-obvious "graveyard" and Catalan phrasings), and each `should_not_trigger` prompt should route to the named sibling (`retention`, `newsletter`, `social-publisher`, `webinar`) instead of here. The `capability` case is run end-to-end against a real session: give the agent the scenario and score the response against the `must_include` rubric — every bullet must be satisfied (purpose+north-star gate, platform rationale, onboarding path, 3-layer moderation, a ritual with cadence, the metrics, and the emitted artifact validated by `scripts/verify.sh`). Structural defects in the emitted `moderation-config` are caught mechanically by `scripts/verify.sh`; the rubric covers the process rigor that no script can check.

package/skills/community/evals/cases.yaml

@@ -0,0 +1,40 @@
+skill: community
+
+should_trigger:
+  - prompt: "Set up our Discord server for the SaaS user community — channels, roles, and rules."
+    why: Core stand-up job — structure + onboarding + moderation for a persistent two-way space.
+  - prompt: "Our Telegram group is a graveyard, nobody posts anymore. How do we revive it?"
+    why: Non-obvious — no setup words, but it is a dead two-way space needing rituals + re-activation, the heart of this skill.
+  - prompt: "We keep getting spam raids and scam-DM waves in our community — lock it down."
+    why: Moderation / incident response (native + bot + human stack, raid runbook) is owned here.
+  - prompt: "Should we run our paid membership on Circle or just use Discord?"
+    why: Platform decision including monetization — the decision table routes this.
+  - prompt: "La comunitat de Discord està morta, ningú escriu — com la reactivem?"
+    why: Catalan phrasing for a graveyard re-activation; rituals + growth loops.
+  - prompt: "How do I get the lurkers in our community to actually post something?"
+    why: Lurker-to-contributor growth (90-9-1 is a range, move members up a tier) is a core job.
+
+should_not_trigger:
+  - prompt: "Our SaaS users keep cancelling in month 2 — build a win-back and churn-reduction flow."
+    route_to: retention
+    why: Paying-customer churn of a product, not activity in a shared member space.
+  - prompt: "Write this week's broadcast email to our subscriber list."
+    route_to: newsletter
+    why: One-to-many opted-in email, not a two-way persistent space.
+  - prompt: "Schedule and cross-post our launch announcement across X, LinkedIn, and Instagram."
+    route_to: social-publisher
+    why: Public-feed posting, not a community space.
+  - prompt: "Run our product-launch webinar end-to-end: registration page, speakers, and replay."
+    route_to: webinar
+    why: A single timed live event, not a persistent two-way space.
+
+capability:
+  - scenario: "Stand up a Discord community for an indie game-dev audience whose business goal is converting free players into paying supporters."
+    must_include:
+      - States or extracts a one-line purpose AND one north-star business metric before designing anything (Step 0 gate).
+      - Justifies Discord over Telegram and Circle for this audience using the decision rules.
+      - Minimal channel set (no sprawl) + role-on-join + an onboarding "first meaningful action" path with the rules/membership gate.
+      - 3-layer moderation — native AutoMod + a verification level, a bot, and human mods — sized to expected scale.
+      - At least one weekly ritual with an explicit cadence.
+      - Names the one business metric plus at least one health metric (e.g. TTFR or DAU/MAU ≥20% floor).
+      - Emits a community-plan.md + moderation-config artifact and references scripts/verify.sh.

package/skills/community/references/metrics-and-rituals.md

@@ -0,0 +1,58 @@
+# Metrics & rituals
+
+The health scorecard and the operating-rhythm library. Use this with the Metrics and Rituals sections of `../SKILL.md`. Facts carry source + access date.
+
+## The metric clusters
+
+Metrics cluster into three groups plus exactly one business metric tied to your Step-0 purpose.
+
+### Cluster 1 — activation / retention
+- **DAU / WAU / MAU** and **stickiness = DAU/MAU**. Benchmark band for social/messaging products is **~50–80%**; treat **≥ 20% as a floor** for a healthy community. Below 20% the room is decaying.
+- **30 / 60 / 90-day cohort retention** — track each join-cohort's survival; it is the truest read on whether onboarding actually activates.
+- **Returning-member ratio** — share of members who came back this period; the direct signal that rituals are working.
+
+### Cluster 2 — member value
+- **Time-to-first-response (TTFR)** — how long until a newcomer's first post gets a reply. Lower is better; this is the newcomer's first lived experience of the room.
+- **Answered rate** — share of questions that get any answer. Drive toward 100%; unanswered questions teach members not to ask.
+
+### Cluster 3 — exactly ONE business metric
+Pick **one** that matches the purpose, and only one:
+- **Support deflection** — questions answered by members vs tickets filed.
+- **Retention uplift** — product retention of members vs non-members.
+- **Expansion revenue** — upgrades/supporter conversions sourced from the space.
+- **Qualified referrals** — warm intros / leads the community generates.
+
+Source: Bevy *Top 11 Community Engagement Metrics for 2025*, Discourse *20 Community Metrics Explained* (2025-04), Geckoboard *DAU/MAU*, accessed 2026-06-02.
+
+## The 90-9-1 reality
+
+- **Participation inequality / "1% rule":** ~**90% lurk, 9% contribute occasionally, 1% drive most activity** — but this is a **range, not a law**.
+- Healthier communities skew far more active: observed profiles like **55-30-15** and **17-57-26**.
+- Design implication: **do not accept 90% lurkers as fixed.** Move lurkers up a tier with prompts, one-tap reactions, and direct asks.
+- Source: NN/g *Participation Inequality* (Nielsen) + Higher Logic *90-9-1 … Officially Outdated*, accessed 2026-06-02.
+
+## Ritual template library
+
+Predictable cadence beats sporadic effort. Run each on time, every time; consistency is the whole point.
+
+| Ritual | Cadence | Friction | What it produces |
+|---|---|---|---|
+| "What are you working on?" thread | Weekly (Mon) | Low — one reply | Re-engagement hook, surfaces who's active |
+| Office hours / AMA | Weekly (Wed) | Medium — opt-in | High-value 1:1-in-public, answered-rate boost |
+| "Wins of the week" | Weekly (Fri) | Low — a reaction counts | Positive loop, social proof |
+| Monthly show-and-tell / demo day | Monthly | Medium | Deepens the 1%/9%, content for announcements |
+| Onboarding "intro Tuesday" round-up | Weekly | Low | Pulls new members into threads day one |
+| Poll of the week | Weekly | Very low — one tap | Cheap participation for lurkers |
+
+### Sample weekly calendar
+```text
+Mon  WIP thread posted 09:00 local
+Wed  Office hours 17:00–18:00 (opt-in @office-hours role)
+Fri  Wins thread + react-to-celebrate
+Sun  (mod) scorecard glance: TTFR, answered rate, new-member activation
+```
+
+### Low-friction participation rules
+- Prefer **reactions and polls** over "write a paragraph" — every tier can participate.
+- Use **opt-in role pings** for ritual reminders; never `@everyone` for routine beats (over-pinging trains mutes, and a muted member is functionally gone).
+- Reserve `@everyone` for genuine all-hands moments only.

package/skills/community/references/platform-playbooks.md

@@ -0,0 +1,64 @@
+# Platform playbooks
+
+Per-platform setup depth. Pick the platform with the decision table in `../SKILL.md`; this file is the build manual for each. Every load-bearing fact carries its source + access date.
+
+## Discord — the real-time default
+
+### AutoMod (native layer)
+- **Keyword filters**: one **Commonly-Flagged-Words preset rule** (`KEYWORD_PRESET`: Insults & Slurs, Sexual Content, Severe Profanity), **1 per guild**, **plus up to 6 custom keyword rules** (`KEYWORD` trigger), each filter holding **up to 1,000 terms** (60 chars each). Use a custom rule for your scam-phrase blocklist and link patterns. Note: the "1,000" is the per-rule *filter* size; do not confuse it with the 100-entry cap on a `KEYWORD` rule's per-rule *allow_list* (exception terms).
+- **Mention-spam cap** (`MENTION_SPAM`, 1 per guild): configurable up to **50 unique role/user mentions per message** before AutoMod acts. Set this low (e.g. 5) for raid resistance.
+- Actions per rule: block message, alert a mod channel, timeout the author. Always route a copy to a private `#mod-log`.
+- Source: Discord — *Auto Moderation* developer docs (docs.discord.com/developers/resources/auto-moderation) + *AutoMod FAQ* (support.discord.com), accessed 2026-06-02.
+
+### Verification levels
+- Set **Medium** as the baseline: verified email + member for >5 minutes before talking. **High** adds a 10-minute server-tenure requirement; **Highest** requires a verified phone. Raise the level temporarily during a raid (the "lockdown" lever).
+
+### Rules Screening / Membership Screening
+- Gates **talking and DMs** until a new member explicitly acknowledges the rules. This both stops drive-by spam and forces the first deliberate click of the onboarding funnel.
+- Pair with **Onboarding** (role/interest selection on join) so the rules-ack flows straight into role-on-join → personalized channels.
+- Source: Discord — *Rules Screening FAQ* + community-building playbooks, accessed 2026-06-02.
+
+### Layered defense by size (Discord's own guidance)
+| Size | Recommended stack |
+|---|---|
+| Small (< 1,000) | Native AutoMod + Medium verification |
+| > 1,000 | Add a specialized moderation bot + custom keyword rules |
+| > 10,000 | Robust multi-tool bots + Commonly-Flagged filters on |
+| > 100,000 | Multiple specialized bots + tiered human mod org |
+- Canonical 3-layer stack everywhere: **native tools → bot automod → human mods**.
+- Source: Discord safety guidance summarized in friendify.net *Discord Moderation & AutoMod Complete Guide (2025)*, accessed 2026-06-02.
+
+## Telegram — mobile-first, broadcast-heavy
+
+### The hybrid pattern (2026 standard)
+- **Groups = two-way conversation; channels = one-way broadcast.** A bare group has no clean announce lane; a bare channel has no conversation. Run a **channel for announcements + a linked discussion group** so each post can spawn a thread.
+- Source: Metricgram — *Telegram Group vs Channel*, accessed 2026-06-02.
+
+### Native anti-spam + slow-mode
+- **Native ML anti-spam activates for groups > 200 members**, with an **"Aggressive" mode** that auto-deletes suspected spam. Below that threshold it is unavailable.
+- For low-traffic groups (**≤ 30 messages/hour**), **slow-mode alone** is the recommended zero-setup control — no bot needed.
+- Source: Metricgram — *Best Telegram Anti-Spam Bots* / *Supergroups Explained*, accessed 2026-06-02.
+
+### Raid gate
+- **CAPTCHA-on-join** is the standard raid wall: button / math / question challenge (e.g. **Shieldy**). New accounts must pass before they can post.
+- Source: Metricgram — *Anti-Spam Bots*, accessed 2026-06-02.
+
+## Circle — the paid / monetized end
+
+### Spaces and structure
+- Content is organized into **Spaces**, which structure **tiered membership** and bundle **courses and events**. This is the monetization primitive — gate Spaces by paid tier.
+
+### 2026 plan ladder + fees
+Circle **discontinued the old "Basic" tier** — **Professional is now the entry plan**.
+
+| Plan | Approx monthly | Circle transaction fee |
+|---|---|---|
+| Professional (entry) | ~$89 annual / ~$129 monthly | 2% |
+| Business | ~$199 annual / ~$219 monthly | 1% |
+| Circle Plus (Enterprise, custom) | ~$419+ | 0.5% |
+- The transaction fee is **tiered 0.5%–2%** (2% Professional, 1% Business, 0.5% Circle Plus) and is charged by Circle **on top of Stripe's standard 2.9% + $0.30** per transaction — budget both layers when modeling take rate.
+- **Real-time chat is weaker than Discord** — choose Circle for monetized membership + content bundling, not for fast live conversation.
+- Source: Circle.so *Pricing* (circle.so/pricing) summarized in SchoolMaker *Circle.so Pricing 2026*, accessed 2026-06-02.
+
+### Monetization gating
+- Do **not** monetize before activation works. Charging for a dead room produces instant churn. Prove rhythm + cohort retention on the free or trial tier first, then gate the high-value Spaces.

package/skills/community/scripts/verify.sh

@@ -0,0 +1,83 @@
+#!/usr/bin/env bash
+# verify.sh — structural check for a community moderation-config artifact.
+# Read-only. Validates required keys, a non-empty north-star, all 3 moderation
+# layers, and at least one ritual with a cadence. Exits 0 on a clean/empty target.
+#
+# Usage: scripts/verify.sh [path/to/moderation-config.yaml|.json]
+# If no path is given, scans the working tree for moderation-config.{yaml,yml,json}.
+# No target found => nothing to check => exit 0 (no false failure).
+
+set -euo pipefail
+
+fail() { echo "FAIL: $1" >&2; exit 1; }
+ok()   { echo "OK: $1"; }
+
+# --- resolve targets -------------------------------------------------------
+targets=()
+if [ "$#" -ge 1 ]; then
+  for arg in "$@"; do
+    [ -f "$arg" ] || fail "no such file: $arg"
+    targets+=("$arg")
+  done
+else
+  while IFS= read -r f; do targets+=("$f"); done < <(
+    find . -type f \( -name 'moderation-config.yaml' -o -name 'moderation-config.yml' -o -name 'moderation-config.json' \) 2>/dev/null
+  )
+fi
+
+if [ "${#targets[@]}" -eq 0 ]; then
+  echo "OK: no moderation-config artifact found — nothing to verify."
+  exit 0
+fi
+
+# --- per-file checks -------------------------------------------------------
+check_file() {
+  local file="$1"
+  local body
+  body="$(cat "$file")"
+
+  # Parse-only sanity for JSON; YAML is checked line-wise via grep below.
+  case "$file" in
+    *.json)
+      if command -v python3 >/dev/null 2>&1; then
+        python3 -c "import json,sys; json.load(open(sys.argv[1]))" "$file" \
+          || fail "$file is not valid JSON"
+      fi
+      ;;
+  esac
+
+  # required top-level / nested keys (token presence is enough for the structural gate)
+  local required=(platform purpose north_star_metric onboarding_path moderation rituals)
+  local k
+  for k in "${required[@]}"; do
+    grep -Eq "(\"$k\"[[:space:]]*:|^[[:space:]]*$k[[:space:]]*:)" <<<"$body" \
+      || fail "$file is missing required key: $k"
+  done
+
+  # north_star_metric must be non-empty (the no-purpose defect)
+  local nsm
+  nsm="$(grep -E "(\"north_star_metric\"|north_star_metric)[[:space:]]*:" <<<"$body" \
+        | head -n1 | sed -E 's/.*north_star_metric"?[[:space:]]*:[[:space:]]*//' \
+        | tr -d '",' | sed -E 's/^[[:space:]]+//; s/[[:space:]]+$//')"
+  [ -n "$nsm" ] || fail "$file has an empty north_star_metric"
+
+  # moderation must declare all three layers
+  local layer
+  for layer in native bot human; do
+    grep -Eq "(\"$layer\"[[:space:]]*:|^[[:space:]]*$layer[[:space:]]*:)" <<<"$body" \
+      || fail "$file moderation does not declare the '$layer' layer"
+  done
+
+  # at least one ritual with a non-empty cadence
+  grep -Eq "(\"cadence\"|cadence)[[:space:]]*:[[:space:]]*[\"']?[[:alnum:]]" <<<"$body" \
+    || fail "$file has no ritual with a non-empty cadence"
+
+  ok "$file passed all structural checks."
+}
+
+for t in "${targets[@]}"; do
+  check_file "$t"
+done
+
+echo "OK: all ${#targets[@]} artifact(s) verified."
+exit 0