rsc-universal 0.1.1

package/skills/webhooks/evals/cases.yaml

@@ -0,0 +1,46 @@
+skill: webhooks
+
+should_trigger:
+  - prompt: "We need to receive webhooks from a provider and process them without dropping events or double-processing. Where do I start?"
+    why: "Core inbound flow: receive + dedupe + safe processing is the skill's whole mandate (verify → timestamp → dedupe → fast-ack)."
+  - prompt: "My webhook signature verification keeps failing even though the signing secret is definitely correct. What am I missing?"
+    why: "Non-obvious. The classic raw-body trap — verifying over re-serialized JSON instead of the raw bytes. The skill names this exact symptom."
+  - prompt: "The provider keeps retrying and our handler ends up running the same event twice. How do we make it idempotent?"
+    why: "At-least-once delivery + idempotency on the stable event id is a flagship section; phrased as a symptom, not jargon."
+  - prompt: "How do I do a constant-time signature compare and a timestamp/replay check on an incoming webhook?"
+    why: "Verify mechanics: timingSafeEqual / compare_digest plus the ~5-min tolerance window are core content."
+  - prompt: "Verificar la firma del webhook entrante y evitar procesar el mismo evento dos veces — ¿cómo lo monto en Express?"
+    why: "Spanish trigger covering signature verification + idempotency, the two central invariants."
+  - prompt: "Our webhook endpoint times out under load and the sender hammers it with retries. How do we ack fast and move the work off the request?"
+    why: "Non-obvious framing of the fast-ack-then-queue pattern; the timeout→retry-storm chain is the reason the pattern exists."
+  - prompt: "What status code should I return from a webhook handler when the signature is bad versus when my downstream save fails?"
+    why: "Status-code semantics (2xx = I own it, 4xx = forged/no-retry, 5xx = genuine retry) is a dedicated decision table."
+
+should_not_trigger:
+  - prompt: "Verify a Stripe webhook with the Stripe-Signature header and handle checkout.session.completed in my SaaS."
+    route_to: stripe
+    why: "Stripe's specific t=,v1= scheme, event model and stripe listen CLI belong to the specialized skill; webhooks covers only the generic case."
+  - prompt: "Handle Resend and SendGrid bounce and complaint webhooks so our suppression list stays clean."
+    route_to: email-connector
+    why: "The point is deliverability suppression state, not generic receive-and-verify mechanics."
+  - prompt: "Build a client that calls the GitHub REST API with auth, pagination and retries on the requests we initiate."
+    route_to: api-connector-builder
+    why: "That is the outbound client (we call them), the opposite direction from an inbound receiver."
+  - prompt: "After an order webhook lands, branch across Slack, the database and an email in a multi-step flow with conditions."
+    route_to: automation-flows
+    why: "Post-landing orchestration; webhooks ends at 'enqueued' and the flow engine takes over from there."
+  - prompt: "Tune our BullMQ worker concurrency and set up a dead-letter queue in Redis."
+    route_to: redis
+    why: "Broker/queue operations, not the front-door receiver; webhooks enqueues but does not own broker tuning."
+
+capability:
+  - scenario: "Implement an inbound webhook endpoint for a generic Standard-Webhooks provider in Node/Express that receives an event, proves it is authentic, refuses to process it twice, and acks fast — then describe where the real work runs."
+    must_include:
+      - "HMAC is computed over the RAW request body (raw buffer/text), not over JSON.parse(req.body) or a re-serialized object"
+      - "constant-time comparison via crypto.timingSafeEqual (not === / ==), with an equal-length guard"
+      - "timestamp tolerance check (~5 minutes) rejecting stale/replayed deliveries"
+      - "dedupe on the provider's stable event id (webhook-id) via a UNIQUE constraint or Redis SETNX, marked before processing"
+      - "dedupe TTL must outlive the provider's retry window (hours to days)"
+      - "returns 2xx only after the event is persisted/enqueued, then does the work in a background worker"
+      - "signing secret read from an environment variable, never a hard-coded literal"
+      - "bad/forged signature returns 400 or 401, not 200"

package/skills/webhooks/references/framework-raw-body.md

@@ -0,0 +1,97 @@
+# Getting the raw body, per framework
+
+If your signature check fails but the secret is correct, you are almost always
+verifying over a **re-serialized** body instead of the raw bytes the sender
+signed. Each framework hides the raw body somewhere different. The rule is the
+same everywhere: **capture the raw bytes, verify, and only then parse.**
+
+## Express
+
+A global `express.json()` consumes the stream, so by the time your handler runs
+the original bytes are gone. Mount `express.raw()` on the webhook route only.
+
+```js
+import express from "express";
+const app = express();
+app.use(express.json()); // fine for the rest of the app
+
+// Webhook route gets RAW, mounted before/instead of the global parser for this path.
+app.post("/webhooks", express.raw({ type: "*/*" }), (req, res) => {
+  const raw = req.body; // Buffer — exact bytes
+  if (!verify(raw, req.headers)) return res.sendStatus(400);
+  const event = JSON.parse(raw.toString("utf8"));
+  // dedupe + enqueue + res.sendStatus(200)
+});
+```
+
+If a global parser already ran, recover the bytes with a `verify` callback:
+`express.json({ verify: (req, _res, buf) => { req.rawBody = buf; } })`.
+
+## Next.js (App Router)
+
+Route handlers do **not** auto-parse, but `await req.json()` reads the stream and
+discards the raw bytes. Read the text instead and parse it yourself after
+verifying.
+
+```ts
+// app/api/webhooks/route.ts
+export async function POST(req: Request) {
+  const raw = await req.text(); // raw string; do NOT call req.json() first
+  const headers = Object.fromEntries(req.headers);
+  if (!verify(raw, headers)) return new Response("bad sig", { status: 400 });
+  const event = JSON.parse(raw);
+  // dedupe + enqueue
+  return new Response("ok", { status: 200 });
+}
+```
+
+(Pages Router differs: set `export const config = { api: { bodyParser: false } }`
+and read the stream — prefer the App Router handler above.)
+
+## FastAPI / Starlette
+
+Typing the parameter as a Pydantic model parses the body for you and throws away
+the bytes. Take the raw `bytes` from the `Request`.
+
+```python
+from fastapi import FastAPI, Request, Response
+app = FastAPI()
+
+@app.post("/webhooks")
+async def webhooks(request: Request):
+    raw = await request.body()  # bytes — do not declare a model param
+    if not verify(raw, request.headers):
+        return Response(status_code=400)
+    event = json.loads(raw)
+    # dedupe + enqueue
+    return Response(status_code=200)
+```
+
+## Hono
+
+```ts
+app.post("/webhooks", async (c) => {
+  const raw = await c.req.text(); // before any c.req.json()
+  if (!verify(raw, c.req.header())) return c.text("bad sig", 400);
+  const event = JSON.parse(raw);
+  return c.text("ok", 200);
+});
+```
+
+## Serverless (Lambda / Vercel / Cloudflare Workers)
+
+- **AWS Lambda (API Gateway / function URL):** the body arrives as a string in
+  `event.body`; if `event.isBase64Encoded` is true, `Buffer.from(event.body,
+  "base64")` first. Verify over that, never over a parsed object.
+- **Vercel Functions:** disable the body parser for the route and read the raw
+  stream (Edge runtime: `await req.text()`).
+- **Cloudflare Workers:** `await request.text()` / `await request.arrayBuffer()`
+  in the `fetch` handler; the body is unbuffered, so read it once.
+
+## Common traps
+
+- A reverse proxy or middleware that re-encodes the body (gzip, charset
+  normalization) changes the bytes after the sender signed them — verify before
+  any transform, and disable response/transit re-encoding on the webhook path.
+- Reading the body stream twice: many runtimes let you read it once. Capture the
+  raw bytes into a variable and reuse that variable for both verify and parse.

package/skills/webhooks/references/signature-schemes.md

@@ -0,0 +1,66 @@
+# Per-provider signature schemes
+
+Every webhook signature is the same primitive — `HMAC-SHA256(secret, message)`
+compared in constant time — wrapped in a different header layout. Map the
+provider onto the generic verify routine in `SKILL.md` by answering three
+questions: **which headers carry the id/timestamp/signature**, **what string is
+signed**, and **how is the signature encoded**.
+
+## Comparison table
+
+| Provider | Signature header | Signed message | Encoding | Timestamp source |
+|----------|------------------|----------------|----------|------------------|
+| Standard Webhooks | `webhook-signature` (`v1,<sig> …` space-separated) | `{webhook-id}.{webhook-timestamp}.{raw-body}` | base64 | `webhook-timestamp` header (Unix seconds) |
+| Stripe | `Stripe-Signature` (`t=<ts>,v1=<sig>`) | `{t}.{raw-body}` | hex | `t` field inside the header |
+| GitHub | `X-Hub-Signature-256` (`sha256=<sig>`) | raw body only | hex | none — rely on TLS + secret; no replay window |
+| Shopify | `X-Shopify-Hmac-SHA256` | raw body only | base64 | none |
+| Slack | `X-Slack-Signature` (`v0=<sig>`) + `X-Slack-Request-Timestamp` | `v0:{timestamp}:{raw-body}` | hex | `X-Slack-Request-Timestamp` header |
+| Svix | same as Standard Webhooks (`svix-id/timestamp/signature` or `webhook-*`) | `{id}.{timestamp}.{raw-body}` | base64 | timestamp header |
+
+Notes that bite:
+
+- **Stripe and Standard Webhooks both prefix versions and both allow multiple
+  comma/space-separated signatures** for secret rotation — accept the request if
+  *any* candidate matches. Never `break` on the first mismatch.
+- **GitHub and Shopify sign the body alone** (no id/timestamp), so they have no
+  built-in replay window. Lean on HTTPS and the secret; if you need replay
+  protection, dedupe on a delivery id (`X-GitHub-Delivery`).
+- **Slack signs `v0:{ts}:{body}`** with a colon separator and a literal `v0:`
+  prefix — different layout from the dot-joined Standard Webhooks string.
+- For the **Stripe** scheme specifically (event model, `stripe listen`, the
+  billing flows) use `../../stripe/SKILL.md`; this table only covers verifying
+  the signature.
+
+## Verify primitives by language
+
+The two things that must be language-correct: feed the **raw bytes** to the HMAC,
+and use the **constant-time** comparator.
+
+| Language | HMAC-SHA256 | Constant-time compare |
+|----------|-------------|------------------------|
+| Node.js | `crypto.createHmac("sha256", key).update(raw).digest()` | `crypto.timingSafeEqual(a, b)` (equal-length Buffers) |
+| Python | `hmac.new(key, raw, hashlib.sha256).digest()` | `hmac.compare_digest(a, b)` |
+| Go | `hmac.New(sha256.New, key); mac.Write(raw)` | `hmac.Equal(expected, got)` |
+| Ruby | `OpenSSL::HMAC.digest("SHA256", key, raw)` | `Rack::Utils.secure_compare(a, b)` |
+| PHP | `hash_hmac("sha256", $raw, $key, true)` | `hash_equals($a, $b)` |
+
+```go
+// Go — Standard Webhooks verify, constant time, raw body in.
+func verify(raw []byte, id, ts, header, secretB64 string) bool {
+	key, _ := base64.StdEncoding.DecodeString(secretB64)
+	mac := hmac.New(sha256.New, key)
+	mac.Write([]byte(id + "." + ts + "."))
+	mac.Write(raw)
+	expected := base64.StdEncoding.EncodeToString(mac.Sum(nil))
+	for _, part := range strings.Fields(header) { // space-separated for rotation
+		sig := strings.TrimPrefix(part, "v1,")
+		if hmac.Equal([]byte(sig), []byte(expected)) {
+			return true
+		}
+	}
+	return false
+}
+```
+
+Whatever the layout, the order from `SKILL.md` does not change: raw body →
+verify → timestamp window → dedupe → enqueue → `2xx`.

package/skills/webhooks/scripts/verify.sh

@@ -0,0 +1,142 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# ============================================================================
+# NAME
+#   verify.sh — webhooks inbound-handler invariant linter
+#
+# USAGE
+#   ./verify.sh [PATH]
+#   Run from the ROOT of YOUR project (the repo containing your webhook
+#   handler), NOT from the skills repository. PATH defaults to the current
+#   directory. Read-only: it never writes, never fixes, never installs.
+#
+# WHAT IT DOES
+#   Heuristically scans candidate webhook-handler files for the five inbound
+#   invariants and prints PASS / WARN / FAIL per file:
+#     1. raw body is used for HMAC verification (flags parsed-body verify)
+#     2. a constant-time signature compare is present (flags ==/=== on a sig)
+#     3. a timestamp / tolerance check exists
+#     4. the signing secret comes from env, not a string literal
+#     5. a dedupe step references a stable event id
+#
+#   It is a HEURISTIC (grep-based), advisory not a compiler. A WARN means
+#   "no evidence found", which is not necessarily a bug.
+#
+# EXIT CODES
+#   0  no candidate files found (clean/empty tree), OR all candidates PASS
+#      every hard check. WARN never fails the run.
+#   1  a candidate file FAILS a hard check (parsed-body verify, ==/=== on a
+#      signature, or a hard-coded secret).
+# ============================================================================
+
+TARGET="${1:-.}"
+
+if [ ! -e "$TARGET" ]; then
+  echo "verify.sh: target not found: $TARGET" >&2
+  exit 0
+fi
+
+# ----------------------------------------------------------------------------
+# Find candidate handler files: source files that look like they touch
+# webhooks / HMAC signatures. Prune dependency + VCS dirs. NUL-delimited so
+# paths with spaces survive.
+# ----------------------------------------------------------------------------
+# Portable (bash 3.2 / macOS + GNU) NUL-safe array build — no mapfile, no
+# process substitution, and -name globs instead of -iregex (BSD/GNU agree on
+# globs). We stage the NUL-delimited find output in a temp file, then read it.
+LISTFILE="$(mktemp -t webhooks-verify.XXXXXX 2>/dev/null || mktemp)"
+trap 'rm -f "$LISTFILE"' EXIT
+
+find "$TARGET" \
+  \( -name node_modules -o -name .git -o -name dist -o -name build \
+     -o -name vendor -o -name .venv -o -name venv -o -name __pycache__ \) -prune \
+  -o -type f \( -name '*.js' -o -name '*.cjs' -o -name '*.mjs' \
+                -o -name '*.ts' -o -name '*.tsx' -o -name '*.py' \
+                -o -name '*.go' -o -name '*.rb' -o -name '*.php' \) \
+  -print0 > "$LISTFILE" 2>/dev/null || true
+
+CANDIDATES=()
+while IFS= read -r -d '' f; do
+  if grep -Eilq 'webhook|x-hub-signature|stripe-signature|x-slack-signature|hmac' "$f" 2>/dev/null; then
+    CANDIDATES+=("$f")
+  fi
+done < "$LISTFILE"
+
+if [ "${#CANDIDATES[@]}" -eq 0 ]; then
+  echo "PASS  no webhook-handler files found under '$TARGET' — nothing to lint."
+  exit 0
+fi
+
+C_RESET=$'\033[0m'; C_RED=$'\033[31m'; C_GRN=$'\033[32m'; C_YEL=$'\033[33m'
+say_pass() { printf '%sPASS%s  %s\n' "$C_GRN" "$C_RESET" "$1"; }
+say_warn() { printf '%sWARN%s  %s\n' "$C_YEL" "$C_RESET" "$1"; }
+say_fail() { printf '%sFAIL%s  %s\n' "$C_RED" "$C_RESET" "$1"; }
+
+# matches lines, case-insensitive, fixed cost
+has() { grep -Eiq "$1" "$2" 2>/dev/null; }
+
+exit_code=0
+
+for f in "${CANDIDATES[@]}"; do
+  echo "── $f"
+
+  # 1. raw body used / parsed-body verify NOT used --------------------------
+  #    Hard fail if we see a signature/HMAC built from an obviously parsed
+  #    body (JSON.stringify(req.body), JSON.parse(...) fed to the digest).
+  if has 'createHmac|hmac\.new|OpenSSL::HMAC|hash_hmac|hmac\.New' "$f"; then
+    if has 'JSON\.stringify\s*\(\s*req\.body|JSON\.stringify\s*\(\s*request\.body' "$f"; then
+      say_fail "(1) HMAC appears to run over re-serialized parsed body (JSON.stringify(req.body)) — verify over the raw bytes"
+      exit_code=1
+    elif has 'rawbody|raw_body|req\.text\(\)|request\.body\(\)|c\.req\.text\(\)|arraybuffer|express\.raw|isbase64encoded' "$f"; then
+      say_pass "(1) raw body captured for HMAC verification"
+    else
+      say_warn "(1) HMAC found but no clear raw-body capture — confirm you verify over the raw bytes, not parsed JSON"
+    fi
+  else
+    say_warn "(1) no HMAC call detected in this file"
+  fi
+
+  # 2. constant-time compare -----------------------------------------------
+  if has 'timingsafeequal|compare_digest|hmac\.equal|secure_compare|hash_equals' "$f"; then
+    say_pass "(2) constant-time signature compare present"
+  elif has 'signature\s*===|signature\s*==|sig\s*===|sig\s*==|=== *expectedsig|== *expectedsig' "$f"; then
+    say_fail "(2) signature compared with ==/=== — timing leak; use a constant-time comparator"
+    exit_code=1
+  else
+    say_warn "(2) no constant-time compare detected — confirm timingSafeEqual / compare_digest is used"
+  fi
+
+  # 3. timestamp / tolerance check -----------------------------------------
+  if has 'webhook-timestamp|x-slack-request-timestamp|timestamp' "$f" \
+     && has '300|5 *\* *60|tolerance|skew|maxage|max_age|window' "$f"; then
+    say_pass "(3) timestamp tolerance / replay window check present"
+  else
+    say_warn "(3) no timestamp tolerance check detected — reject events outside ~5 minutes"
+  fi
+
+  # 4. secret from env, not a literal --------------------------------------
+  if has 'webhook_secret\s*=\s*["'\''][a-z0-9_]{12,}|signing_secret\s*=\s*["'\''][a-z0-9_]{12,}|whsec_[a-z0-9]' "$f"; then
+    say_fail "(4) signing secret looks hard-coded — read it from an environment variable"
+    exit_code=1
+  elif has 'process\.env|os\.environ|os\.getenv|env\(|ENV\[' "$f"; then
+    say_pass "(4) signing secret sourced from environment"
+  else
+    say_warn "(4) no env lookup detected — confirm the signing secret comes from env"
+  fi
+
+  # 5. dedupe on event id ---------------------------------------------------
+  if has 'unique|setnx|set .* nx|already.processed|already.seen|seen_event|idempoten|webhook-id|event\.id|delivery.id' "$f"; then
+    say_pass "(5) dedupe / idempotency on an event id present"
+  else
+    say_warn "(5) no dedupe step detected — dedupe on the provider's stable event id (UNIQUE / SETNX)"
+  fi
+done
+
+echo
+if [ "$exit_code" -eq 0 ]; then
+  echo "${C_GRN}verify.sh: no hard failures.${C_RESET} WARN lines are advisory — review them."
+else
+  echo "${C_RED}verify.sh: hard failures found.${C_RESET} Fix the FAIL lines above."
+fi
+exit "$exit_code"

package/skills/webinar/SKILL.md

@@ -0,0 +1,196 @@
+---
+name: webinar
+description: "Use when planning, promoting, or running a webinar meant to convert — deciding the offer before the title, building the registration + reminder funnel, scripting the run-of-show, or splitting post-event follow-up by segment. Triggers: 'plan a webinar', 'webinar that converts', 'people register but don't show up', 'webinar got attendees but no sales', 'reminder email sequence', 'no-show replay follow-up', non-obvious: 'my live attend rate is only 30%', 'how do I transition into the pitch without it feeling salesy', ES 'montar un webinar que convierta', CA 'fer un webinar que vengui'. NOT the slide visuals themselves (that is presentations), NOT the registration page copy (that is landing-copy)."
+tags: [webinar, conversion-funnel, run-of-show, registration, follow-up, marketing-brand]
+recommends: [presentations, landing-copy, content-engine, newsletter, lead-gen, cold-outreach, sales-pipeline, calendar-scheduling, email-connector]
+profiles: []
+origin: risco
+---
+
+# webinar
+
+Run the webinar as **one conversion event from end to end** — from "we should do a webinar" to "we closed deals from it." You own four coupled phases in order: decide the offer, fill the seats, run it to convert, follow up by segment. You do not own the artifacts the specialists make. The slide visuals, the registration page's final words, the recurring content calendar, the standing newsletter — those get handed to siblings. What you own is the funnel and the run-of-show that stitch them into one timeline. A webinar is a sales conversation scheduled in advance; design the conversation, not the talk.
+
+## When to use
+
+- Planning from scratch: deciding the offer / single next step before the title or any slide.
+- Choosing live vs automated/on-demand for the goal and audience size.
+- Writing the run-of-show: hook → teaching → permission transition → stack → offer → close → Q&A.
+- Building the 4-week promotion schedule across email + organic + paid social.
+- Writing the pre-event reminder sequence (confirmation → 24h → 1h → 5-min) that drives show-up rate.
+- Designing the segmented post-event follow-up (attendees vs no-shows vs replay) in the 0–72h window.
+- Rescuing a webinar that gets registrations but no-shows, or attendees but no sales — diagnosing which funnel stage leaks.
+- "Montar un webinar que convierta" (ES), "fer un webinar que vengui" (CA).
+
+## When NOT to use — route instead
+
+| The ask | Route to |
+|---|---|
+| Design the slide deck's visual layout / build the actual slides | `../presentations/SKILL.md` |
+| Write the final words on the registration landing page | `../landing-copy/SKILL.md` |
+| The recurring editorial calendar this webinar is one slot inside | `../content-engine/SKILL.md` |
+| The standing newsletter / general nurture program | `../newsletter/SKILL.md` |
+| Source and score the target list you'd invite | `lead-gen` |
+| Cold DMs/emails inviting individuals one-to-one | `../cold-outreach/SKILL.md` |
+| Work the deals the webinar generates through stages | `sales-pipeline` |
+| The investor/vision deck delivered to a room | `pitch-deck` |
+
+The test: if the deliverable is the *event funnel, the run-of-show, or the promote-and-follow-up timeline*, it is webinar. If it is the *slides*, that is presentations. If it is the *registration page's copy*, that is landing-copy.
+
+## Decide the offer first
+
+**Before the title, before a single slide, write down the ONE thing this webinar sells — or the single next step it asks for.** Why: the teaching only lands if you reverse-build it from the offer. A pitch bolted onto a finished talk feels like an ambush; a talk built backward from the offer feels like the obvious conclusion. The opening story plus the teaching should do ~80% of the selling, so the ask at the end is a small step, not a leap (Graham Cochrane $100k webinar template 2025; Best Seller Publishing 2025).
+
+State it in one sentence before anything else:
+
+```text
+This webinar sells: [the $1,500 6-week cohort]
+The single next step we ask for: [book a 15-min enrollment call by Friday]
+The 2–3 false beliefs the teaching must break: [1] ... [2] ... [3] ...
+```
+
+If you cannot fill that in, stop. You are not ready to pick a title. Everything downstream — the hook, which beliefs the teaching dismantles, the stack, the follow-up CTA — is derived from these three lines.
+
+## The funnel you're optimizing
+
+You are optimizing five numbers, not one. Anchor every plan to **registrants**, because roughly half of them never show up live — median live attend rate is ~41.6% of registrants; B2B averages ~35–45% (Univid Webinar Report 2026; ON24 2025 Benchmarks). If you plan for "attendees," you under-fill the top and over-promise the close.
+
+```text
+Registrants  →  Show-up (~42%)  →  Engaged  →  Converted  →  Post-event
+  reminder         interaction       offer        follow-up      replay/segment
+  sequence         (polls/CTA)        + close      0–72h          ~25% of sales
+```
+
+Diagnose by stage when something leaks:
+
+| Symptom | Leaking stage | The lever |
+|---|---|---|
+| Lots of registrants, weak live turnout | show-up | reminder sequence + SMS (see below) |
+| Good turnout, audience goes passive/drops | engaged | mid-session polls + live resource CTA |
+| Engaged room, no sales | converted | the offer/stack and the permission transition |
+| Live went fine, pipeline went quiet | post-event | segmented 0–72h follow-up |
+
+### Live vs automated/on-demand
+
+Pick by goal, audience size, and repeatability — not by what feels more "premium."
+
+| | Live | Automated / on-demand |
+|---|---|---|
+| Best for | launches, high-ticket, real-time Q&A and urgency | evergreen offers, always-on lead gen, time-zone spread |
+| Audience | one concentrated cohort | trickle of registrants over weeks |
+| Conversion driver | live interaction + scarcity | replay reach (40–44% of all views) |
+| Cost | one production, full team | build once, runs unattended |
+| Risk | one shot; weather/tech can sink it | feels canned if you fake "live" |
+
+Default to **live for the first run** of any new offer (you learn the objections), then automate the winner.
+
+## Run-of-show
+
+The skeleton, with the 80/20 selling rule baked in:
+
+```text
+1. Hook (0–5 min)        — the promise + the story that earns the room's attention
+2. Teaching (5–40 min)   — break the 2–3 false beliefs, one block each, proof per block
+3. Permission transition — explicitly ask to switch modes before you pitch
+4. Stack + offer         — what they get, framed against the cost of staying stuck
+5. Close (the ask)       — the single next step, with a clean deadline
+6. Q&A                   — handle the live objections; do NOT re-open the teaching
+```
+
+The transition is where most webinars die — the speaker lurches from "value" to "buy now" with no bridge, and the room feels sold-at. Ask permission and name the shift:
+
+```text
+Bad:  "...and that's the framework. So anyway — I've got something to show you.
+       For just three payments of $500 you can..."
+
+Good: "That's the whole method. Now — some of you want to implement this alone, and
+       these slides are enough to do that. For the rest who'd rather we do it with you
+       over the next six weeks, can I take two minutes to show you exactly how that
+       works? Then we'll open it up for questions."
+```
+
+The "Good" version gives the room a choice, which lowers resistance — and it earns the pitch instead of springing it. Place a poll roughly every 10–12 minutes so the teaching stays a conversation. The full annotated, timed template — hook block, the per-belief teaching blocks, the stack/offer mechanics, poll placement, and how the stack changes by offer type — is in `references/run-of-show.md`. Hand the slide *visuals* for all of this to `../presentations/SKILL.md`.
+
+## Promote & fill seats
+
+Start promotion **~4 weeks out**; email is the dominant channel (~86% of teams), then organic and paid social (Amra & Elma 2025). Earlier start + multi-channel = more registrants. The channel mix, email-led:
+
+```text
+T-28d  announce            email to list + organic posts
+T-21d  value teaser        what they'll learn (one belief preview) + paid social on
+T-14d  social proof        past-attendee result / agenda reveal
+T-7d   urgency builds      "one week left", second list email
+T-1d   last call           final registration push across all channels
+```
+
+For the registration page itself, write a **brief** and hand the page to `../landing-copy/SKILL.md` — do not write the final page copy yourself. The brief names: the single promise (matches the offer line above), the 3 belief-shifts as bullets, the date/time with time-zone, the host + credibility line, and the one CTA ("Save my seat"). Where this webinar sits in the wider calendar belongs to `../content-engine/SKILL.md`. The full dated promotion table lives in `references/email-cadence.md`.
+
+## Reminder sequence — the show-up lever
+
+This is the highest-leverage block in the whole funnel and it is not optional polish. **Day-of reminder emails drive ~38% of total live attendance, and the "5 minutes before" email gives the single biggest boost** (ProperExpression). Adding SMS lifts registrant→attendee from a ~56% baseline to as high as 71% — a ~27% lift (Amra & Elma 2025).
+
+```text
+Confirmation (instant)   calendar invite + what to expect + "add to calendar"
+T-24h  email             one reason to show up live (the thing replay won't have)
+T-1h   email + SMS       link + "starts in 1 hour"
+T-5min email + SMS       "we're going live now — join link"   ← biggest single lever
+```
+
+Send the calendar invite via `calendar-scheduling`; if you're wiring the sends programmatically, `email-connector` owns the transport. The full row-by-row cadence with the metric each touch moves is in `references/email-cadence.md`.
+
+## Run it live
+
+Interaction roughly doubles lead conversion: **interactive webinars (mid-session polls + a live resource-download CTA) converted attendees to MQLs at 38% vs 19% for passive slide-only decks** (Amra & Elma 2025). Build the interaction into the run-of-show, don't improvise it:
+
+- A poll roughly every 10–12 min — the first inside the first 5 minutes to set the norm that this room participates.
+- One live resource CTA mid-session (a downloadable the offer builds on) — this is also your engagement flag for follow-up segmentation.
+- Watch chat; pull 2–3 questions into the teaching by name. Save the rest for Q&A.
+
+Pick the platform from attendee count + session length + budget, not brand (StackScored 2026; Riverside 2026):
+
+| Platform | Fits | Note |
+|---|---|---|
+| Demio | small live, ≤50 attendees | Starter ~$49/mo, 3h session cap |
+| Livestorm | mid-size, polished | per-credit ~€2.50/unique-attendee — 3,000 live ≈ €7,500/event, expensive at scale |
+| Zoom Webinars | large, familiar | scales to 10,000+ |
+| Riverside | large + studio-quality recording | scales to 10,000+, strong replay asset |
+
+## Follow up by segment
+
+**Conversion is segment-specific** — one follow-up does not fit all. High-engagement attendees convert to sales conversations at 12–15%, passive at 3–5%, replay-watching no-shows at 2–3% (Martal 2025). And the window is short: follow-up open rates drop from ~58% within 24h to ~31% after 48h (Default.com). Send the first touch in 0–24h, then 2–4 touches over 5–7 days. The follow-up is half the revenue — **~25% of webinar-related sales happen post-event, and 40–44% of total views come from replay** (DigitalApplied 2026; Cloud Present).
+
+| Segment | First touch | CTA matched to readiness |
+|---|---|---|
+| Engaged attendee | 0–4h | direct ask — book the call / claim the offer before deadline |
+| Passive attendee | 0–24h | replay + the one objection they likely have, then the offer |
+| No-show registrant | 0–24h | "you missed it — here's the replay", time-boxed |
+| Replay-only viewer | on watch | offer + deadline, lower-commitment next step |
+
+Hand the *recurring* nurture program (people who don't convert this cycle) to `../newsletter/SKILL.md`. Hand the *deals* the webinar generated to `sales-pipeline` to work through stages. You own only the 0–72h conversion window.
+
+## Metrics scorecard
+
+Report these five and judge against benchmark — vanity registration counts hide every real leak:
+
+```text
+Registration count        — top of funnel (necessary, not sufficient)
+Show-up rate              — registrants → live; benchmark ~42% (B2B 35–45%)
+Engagement rate          — poll responses / live CTA clicks per attendee
+Conversion rate          — segment-split: engaged 12–15%, passive 3–5%, replay 2–3%
+Post-event %             — share of total sales closed after the live event (~25%)
+```
+
+## Anti-patterns
+
+| Bad | Why it leaks | Good |
+|---|---|---|
+| Pick the title, then figure out what to sell | the teaching can't reverse-build; the pitch feels bolted on | write the one offer + next step before the title |
+| Plan capacity off "attendees" | ~58% of registrants never show; you under-fill | anchor every number to registrants, assume ~42% show-up |
+| One confirmation email, no reminders | day-of reminders drive ~38% of attendance — you forfeit it | confirmation → 24h → 1h → 5-min, add SMS |
+| Slide-only, no interaction | passive converts to MQL at half the rate (19% vs 38%) | a poll every ~10–12 min + one live CTA |
+| Lurch straight into the pitch | the room feels sold-at and resistance spikes | the permission transition — ask, name the mode switch |
+| A 20-minute pitch block | selling should be ~20%, the teaching ~80% | story + teaching do the selling; the ask is a small step |
+| One follow-up email to everyone | conversion is segment-specific; you waste the engaged and annoy the cold | three paths — attendee / no-show / replay |
+| Follow up "next week" | opens halve after 48h; pipeline goes cold | first touch 0–24h, 2–4 touches over 5–7 days |
+| Report registration count as the win | hides which stage actually leaked | the five-number scorecard, judged vs benchmark |
+| Fake "live" on an automated webinar | the moment the audience notices, trust collapses | be honest it's on-demand, or run it genuinely live |

package/skills/webinar/evals/README.md

@@ -0,0 +1,14 @@
+# Evals — webinar
+
+These cases are run by the catalog's eval harness, not a standalone script. The
+`should_trigger` and `should_not_trigger` prompts validate that the description routes
+correctly — webinar should fire on offer-first planning, show-up/no-sale diagnosis, the
+reminder cadence, and the permission-transition question (incl. the Spanish phrasing),
+and should hand off cleanly to presentations (slide visuals), landing-copy (page words),
+newsletter (recurring program), lead-gen (list sourcing), and sales-pipeline (working
+deals). The single `capability` case checks the body actually produces a complete
+offer-first funnel plan: offer-before-tactics, registrant-anchored math, the 4-week
+promotion + reminder + SMS levers, a run-of-show with the permission transition, the
+segmented 0–72h follow-up, a platform pick sized to the audience, and the hand-offs.
+Run it through whatever harness loads `cases.yaml`; there is no checkable artifact, so
+there is no `verify.sh` — webinar is a process skill and its rigor is the capability rubric.

package/skills/webinar/evals/cases.yaml

@@ -0,0 +1,44 @@
+skill: webinar
+
+should_trigger:
+  - prompt: "Plan a webinar to launch our new course"
+    why: "Core plan-from-offer — webinar owns the full conversion-event lifecycle."
+  - prompt: "People register for our webinars but barely half show up live"
+    why: "Non-obvious symptom that maps to the show-up funnel stage; the reminder sequence is the lever."
+  - prompt: "We got 200 attendees but zero sales — what went wrong?"
+    why: "Diagnose the converted stage — run-of-show offer/transition plus segmented follow-up."
+  - prompt: "Write the reminder email sequence for our Thursday webinar"
+    why: "Pre-event reminder cadence (confirmation → 24h → 1h → 5-min) is squarely webinar's show-up block."
+  - prompt: "How do I transition into the pitch without it feeling salesy?"
+    why: "Non-obvious phrasing — the permission transition inside the run-of-show."
+  - prompt: "Montar un webinar para vender nuestro programa"
+    why: "Spanish trigger for the full offer-first funnel."
+
+should_not_trigger:
+  - prompt: "Design the slides for my webinar deck — make them look good"
+    route_to: presentations
+    why: "Slide visuals/craft, not the funnel or run-of-show."
+  - prompt: "Write the registration landing page copy"
+    route_to: landing-copy
+    why: "The page's final words; webinar only writes the brief and hands it off."
+  - prompt: "Set up our monthly newsletter"
+    route_to: newsletter
+    why: "Recurring email publication, not a one-time conversion event."
+  - prompt: "Build me a target list of accounts to invite"
+    route_to: lead-gen
+    why: "Sourcing and scoring the list, not running the event."
+  - prompt: "Move the deals from last week's webinar through our sales stages"
+    route_to: sales-pipeline
+    why: "Working deals through stages is downstream of webinar's 0–72h window."
+
+capability:
+  - scenario: "We're running a live webinar in 3 weeks to sell a $1,500 cohort; we have a list of 4,000 and a finished deck. Build the plan."
+    must_include:
+      - "Confirms or sets the single offer + the single next step before any tactics"
+      - "Registrant-anchored funnel math using the ~42% show-up assumption"
+      - "4-week promotion schedule with an email-led, multi-channel mix"
+      - "Reminder sequence including the day-of and 5-min touches plus the SMS lever"
+      - "Run-of-show with the permission transition and at least one poll"
+      - "Segmented follow-up across attendee / no-show / replay within the 0–72h window"
+      - "Platform note appropriate to the ~1,700 expected live attendees (e.g. Zoom/Riverside scale, not Demio's 50 cap)"
+      - "Hands the slide work to presentations and the registration page to landing-copy"