@damiangilgonzalez/harness 1.3.7

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 and reminder funnel, scripting the run-of-show, and splitting post-event follow-up by segment. Covers a low live attend rate, attendees who do not buy, and the transition into the pitch. 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"

package/skills/webinar/references/email-cadence.md

@@ -0,0 +1,75 @@
+# Email cadence — promotion, reminders, segmented follow-up
+
+The single dated schedule the SKILL.md points to: T-28d through T+7d. Each row carries
+its purpose and the funnel metric it moves. Adjust the calendar to your event date;
+keep the relative spacing.
+
+## Phase 1 — Promotion (T-28d → T-1d)
+
+Start ~4 weeks out. Email is the dominant channel (~86% of teams); pair every email
+with organic, and turn on paid social from ~T-14d. Metric moved: **registration count**.
+
+| When | Touch | Purpose |
+|---|---|---|
+| T-28d | Announce (email + organic) | open registration; the single promise |
+| T-21d | Value teaser (email) | preview one belief-shift; turn on paid social |
+| T-14d | Social proof (email + organic) | a past result or agenda reveal |
+| T-7d | Urgency (email) | "one week left", second push |
+| T-3d | Personal note (email) | host's reason this matters now |
+| T-1d | Last call (all channels) | final registration push |
+
+## Phase 2 — Reminders (confirmation → 5-min before)
+
+The show-up lever. Day-of reminders drive ~38% of total live attendance; the 5-min
+email is the single biggest boost. SMS on the last two touches lifts
+registrant→attendee from ~56% to as high as 71%. Metric moved: **show-up rate**.
+
+| When | Touch | Purpose |
+|---|---|---|
+| On registration | Confirmation (email) | calendar invite + what to expect + add-to-calendar |
+| T-24h | Reminder (email) | the one thing live has that replay won't |
+| T-1h | Reminder (email + SMS) | join link, "starts in 1 hour" |
+| T-5min | Going live (email + SMS) | join link, "we're live now" — biggest single lever |
+
+## Phase 3 — Segmented follow-up (T+0 → T+7d)
+
+Conversion is segment-specific; open rates halve after 48h (~58% within 24h → ~31%
+after 48h). First touch in 0–24h, then 2–4 touches over 5–7 days. ~25% of sales close
+post-event. Metric moved: **conversion rate** (and recovered pipeline).
+
+### Engaged attendee (converts ~12–15%)
+
+| When | Touch | Purpose |
+|---|---|---|
+| T+0–4h | Direct ask (email) | book the call / claim the offer before deadline |
+| T+1d | Recap + proof (email) | restate the offer, one testimonial |
+| T+3d | Deadline (email) | the close window is ending |
+
+### Passive attendee (converts ~3–5%)
+
+| When | Touch | Purpose |
+|---|---|---|
+| T+0–24h | Replay + objection (email) | replay link + the likely objection, then offer |
+| T+2d | Value nudge (email) | the resource CTA they didn't claim |
+| T+5d | Soft offer (email) | lower-commitment next step |
+
+### No-show registrant (converts ~2–3%)
+
+| When | Touch | Purpose |
+|---|---|---|
+| T+0–24h | "You missed it" (email) | replay link, time-boxed access |
+| T+3d | Last chance replay (email) | replay expiring + the offer |
+
+### Replay-only viewer
+
+| When | Touch | Purpose |
+|---|---|---|
+| On watch | Offer + deadline (email) | matched lower-commitment next step |
+
+## Hand-offs
+
+- Recurring nurture for everyone who didn't convert this cycle → the newsletter program.
+- Deals the webinar generated → the sales pipeline.
+- Programmatic sends / transport → email-connector; calendar invites → calendar-scheduling.
+
+You own only the 0–72h conversion window after the event.

package/skills/webinar/references/run-of-show.md

@@ -0,0 +1,83 @@
+# Run-of-show — annotated timed template
+
+The full template the SKILL.md skeleton points to. Timings assume a ~60-minute live
+webinar selling a single offer. Scale blocks proportionally for shorter/longer slots.
+The stack changes by offer type — notes at the end.
+
+## The principle
+
+The opening story plus the teaching should do ~80% of the selling. By the time you
+reach the offer, the audience should already believe they need it; the ask is then a
+small step, not a leap. Reverse-build every block from the offer line you wrote first.
+
+## Timed blocks
+
+```text
+00:00–05:00  HOOK
+  - The big promise, stated once, plainly. "By the end of this hour you'll know X."
+  - The story: a specific before→after (yours or a student's). Concrete numbers.
+  - First poll inside minute 5 — sets the norm that this room participates.
+  - Name the agenda in one line so they know the pitch is coming (no ambush).
+
+05:00–40:00  TEACHING — one block per false belief (2–3 blocks)
+  Block 1: false belief → why it's wrong → the true mechanism → proof.
+  Block 2: same shape, the next belief in the chain.
+  Block 3 (optional): the belief that makes "do it yourself" feel hard.
+  - One poll between blocks (~every 10–12 min).
+  - One live resource CTA mid-teaching — a downloadable the offer builds on.
+    This download is ALSO your engagement flag for follow-up segmentation.
+
+40:00–42:00  PERMISSION TRANSITION  (the make-or-break moment)
+  - Acknowledge the slides are enough to DIY.
+  - Ask permission to show the done-with-you path. Name the mode switch.
+  - Promise Q&A after, so nobody feels trapped.
+
+42:00–52:00  STACK + OFFER
+  - Each component framed against the cost of staying stuck, not as a feature list.
+  - Price revealed AFTER the stacked value, once.
+  - The single next step + a clean, real deadline (no fake countdowns).
+
+52:00–60:00  Q&A / CLOSE
+  - Handle live objections. Restate the next step + deadline as you answer.
+  - Do NOT re-open the teaching — questions only.
+```
+
+## The permission-transition script pattern
+
+The bridge from teaching to offer is where most webinars die. The pattern:
+
+1. **Validate the DIY path.** "These slides are enough to do this on your own."
+2. **Offer the faster path as a choice.** "For those who'd rather do it with us..."
+3. **Ask permission + time-box.** "Can I take two minutes to show you how?"
+4. **Promise the exit.** "Then we'll open it up for questions."
+
+```text
+"That's the entire method — and honestly, the slides I just shared are enough to
+ run it yourself. Some of you will, and that's great. For the rest of you who'd
+ rather not spend six months figuring out the edge cases alone — can I take two
+ minutes to show you exactly how we do this with you? Then I'll stay on for every
+ question you've got."
+```
+
+This lowers resistance because it hands the room a choice instead of a sales lurch,
+and it earns the pitch rather than springing it.
+
+## Poll placement
+
+- Minute 5: an easy opinion poll. Goal is participation habit, not data.
+- Between teaching blocks: a poll that surfaces the belief the next block breaks
+  ("What's your biggest blocker with X?") — it pre-sells the teaching.
+- Just before the transition: a readiness poll ("Want the DIY path or done-with-you?")
+  — it segments the room and warms the offer.
+
+## How the stack changes by offer type
+
+| Offer | Stack emphasis | Next step asked for |
+|---|---|---|
+| High-ticket cohort/coaching | transformation + access + accountability | book a call |
+| Course / self-serve product | outcome + speed + bonuses | buy now, deadline pricing |
+| Free trial / SaaS | activation + time-to-value | start trial, guided onboarding |
+| Lead-gen / consultation | the diagnosis they'll get | book the consult |
+
+Keep the offer to ONE primary next step. A second option splits the room's attention
+and lowers conversion on both.