rsc-universal 0.1.1

package/skills/clickhouse-analytics/scripts/verify.sh

@@ -0,0 +1,109 @@
+#!/usr/bin/env bash
+# verify.sh — static linter for ClickHouse DDL/queries emitted by the
+# clickhouse-analytics skill. Read-only: it greps candidate .sql text for
+# anti-patterns from SKILL.md. It does NOT connect to any cluster.
+#
+# Usage:
+#   scripts/verify.sh [PATH ...]      # lint given .sql files
+#   scripts/verify.sh                 # lint *.sql under the current dir
+#   cat x.sql | scripts/verify.sh -   # lint stdin
+#
+# Exit: 0 when nothing flagged (also on empty/no input — no false failure).
+#       1 when at least one anti-pattern line is found.
+
+set -u
+
+findings=0
+
+# Emit a finding line and bump the counter.
+flag() { # file line_no message line_text
+  printf '%s:%s: %s\n    %s\n' "$1" "$2" "$3" "$(printf '%s' "$4" | sed 's/^[[:space:]]*//')"
+  findings=$((findings + 1))
+}
+
+# Lint one already-collected buffer. Args: label, full-text-in-$2.
+lint_buffer() {
+  local label="$1" text="$2"
+  [ -z "${text//[[:space:]]/}" ] && return 0   # empty buffer: nothing to flag
+
+  local lineno=0 line lower
+  while IFS= read -r line || [ -n "$line" ]; do
+    lineno=$((lineno + 1))
+    # Strip trailing line comments so they don't trip the matchers.
+    local code="${line%%--*}"
+    lower="$(printf '%s' "$code" | tr '[:upper:]' '[:lower:]')"
+    [ -z "${lower//[[:space:]]/}" ] && continue
+
+    # 1. Over-fine partitioning: per-day / per-hour buckets.
+    case "$lower" in
+      *partition\ by*toyyyymmdd*|*partition\ by*tostartofhour*|*partition\ by*tostartofminute*|*partition\ by*todate\(*)
+        flag "$label" "$lineno" "fine PARTITION BY (per-day/hour) — partition coarsely (toYYYYMM); the sparse index does the speed" "$line" ;;
+    esac
+
+    # 2. Single-row INSERT ... VALUES (...) on one line — tiny parts.
+    case "$lower" in
+      *insert\ into*values*\(*\)*)
+        flag "$label" "$lineno" "single-row INSERT ... VALUES — batch 10k-100k+ rows or rely on async inserts" "$line" ;;
+    esac
+
+    # 3. POPULATE on a materialized view — blocks/OOM on big tables.
+    case "$lower" in
+      *materialized\ view*populate*|*populate*as\ select*)
+        flag "$label" "$lineno" "POPULATE on a materialized view — create it empty and backfill in bounded windows" "$line" ;;
+    esac
+
+    # 4. SELECT * — defeats columnar storage on wide tables.
+    case "$lower" in
+      *select\ \**) flag "$label" "$lineno" "SELECT * — name only the columns you need (columnar store reads per-column)" "$line" ;;
+    esac
+
+    # 5. FINAL — merges at query time, keep off hot paths.
+    case "$lower" in
+      *\ final\ *|*\ final\;*|*\ final|*\)final*)
+        flag "$label" "$lineno" "FINAL — merges at query time; keep it off dashboard/hot-path queries" "$line" ;;
+    esac
+  done <<EOF
+$text
+EOF
+
+  # 6. MergeTree-family ENGINE with no ORDER BY anywhere in the statement set.
+  #    Whole-buffer check because ORDER BY may sit lines below ENGINE.
+  if printf '%s' "$text" | grep -iqE 'engine[[:space:]]*=[[:space:]]*[a-z]*mergetree'; then
+    if ! printf '%s' "$text" | grep -iqE 'order[[:space:]]+by[[:space:]]+[^t]'; then
+      flag "$label" "0" "MergeTree-family ENGINE with no usable ORDER BY — define a 3-5 col sort key (ORDER BY tuple() leaves no sparse index)" "ENGINE = *MergeTree"
+    fi
+  fi
+}
+
+# Collect input sources.
+inputs=()
+if [ "$#" -eq 0 ]; then
+  while IFS= read -r f; do inputs+=("$f"); done < <(find . -type f -name '*.sql' 2>/dev/null)
+else
+  for arg in "$@"; do inputs+=("$arg"); done
+fi
+
+# Nothing to lint at all: clean exit, no false failure.
+if [ "${#inputs[@]}" -eq 0 ]; then
+  echo "clickhouse-analytics verify: no .sql input found — nothing to check."
+  exit 0
+fi
+
+for src in "${inputs[@]}"; do
+  if [ "$src" = "-" ]; then
+    lint_buffer "(stdin)" "$(cat)"
+  elif [ -f "$src" ]; then
+    lint_buffer "$src" "$(cat "$src")"
+  else
+    echo "clickhouse-analytics verify: skip (not a file): $src" >&2
+  fi
+done
+
+if [ "$findings" -gt 0 ]; then
+  echo "---"
+  echo "clickhouse-analytics verify: $findings anti-pattern line(s) flagged. See SKILL.md."
+  exit 1
+fi
+
+echo "clickhouse-analytics verify: clean — no anti-patterns found."
+exit 0

package/skills/client-onboarding/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: client-onboarding
+description: "Use when a deal just closed or a user just signed up and you need a real activation plan — not an ad-hoc welcome email: defining what 'activated'/first-value means for the product, taking the sales→delivery handoff so nothing promised is lost, running a kickoff (agenda + welcome packet + RACI), or laying a 30/60/90 (high-touch) or day-0→day-14 nudge sequence (self-serve) with owners, dates, and a measurable exit. Triggers: 'build an onboarding plan for a new client', 'define our activation event', 'the deal is signed, what now before they go cold', 'run the kickoff call', 'sales-to-CS handoff', 'plan de onboarding para un cliente nuevo', 'munta'm el kickoff i el pla de 30/60/90', 'day-0 to day-14 nudge sequence to the aha moment'. NOT inbound ticket triage (that is customer-support), NOT the ongoing renewal/churn/health program (that is retention), NOT the pre-close proposal/SOW (that is proposals)."
+tags:
+  - onboarding
+  - activation
+  - kickoff
+  - time-to-value
+  - customer-success
+recommends:
+  - customer-support
+  - retention
+  - proposals
+  - sales-pipeline
+  - calendar-scheduling
+  - e-signature
+  - technical-writing
+profiles: []
+origin: risco
+---
+
+# Client onboarding
+
+You run the **post-signature activation sprint**: the window between "deal
+closed / account created" and "customer is live and has felt real value at
+least once." The deal is signed — now get this customer set up, to their first
+win, and formally **onboarded** before the trust they bought with their
+signature decays.
+
+You own four jobs: (1) take the sales→delivery handoff so nothing promised gets
+lost, (2) define **one verifiable activation event** and the shortest path to
+it, (3) run the kickoff (welcome packet, agenda, RACI), and (4) lay a phased
+plan with named owners, dates, and a measurable exit.
+
+What you do **not** own — hand off explicitly:
+
+- Inbound ticket from an existing customer → [`customer-support`](../customer-support/SKILL.md). You are proactive first-30-days, not reactive triage.
+- Renewals, churn programs, health scoring of the installed base → [`retention`](../retention/SKILL.md). You **end** at the onboarded gate; the lifecycle after it is theirs.
+- The proposal/SOW that precedes the signature → [`proposals`](../proposals/SKILL.md). You start *after* the win.
+- Moving the deal through pre-close stages / forecasting → [`sales-pipeline`](../sales-pipeline/SKILL.md). The handoff is the seam between you.
+- Sending kickoff invites → [`calendar-scheduling`](../calendar-scheduling/SKILL.md); e-signing the order form → [`e-signature`](../e-signature/SKILL.md); writing the help-center setup docs → [`technical-writing`](../technical-writing/SKILL.md).
+
+Building the product's in-app tour widget is a product job. You define the
+*plan and content*, not the tour UI.
+
+## Step 1 — Pick the motion first
+
+The whole plan branches here. Decide before you write a single email.
+
+| Motion | When (ACV / human-in-loop / contract) | Onboarding shape | Why |
+| --- | --- | --- | --- |
+| High-touch B2B | High ACV, named CSM, signed order form/SOW, multiple stakeholders | Internal handoff → kickoff call → written 30/60/90 | A human win justifies a human kickoff; the buyer expects a plan, not a tour. |
+| Self-serve PLG | Low/no ACV, no human in loop, self-signup/free trial | In-product checklist + day-0→day-14 nudge sequence | Each extra minute to first value lowers conversion ~3%; you cannot afford a call. |
+| Hybrid | Mid ACV, light human touch on top of product | In-product activation + one human kickoff at a threshold | Self-serve to first value, then a human at expansion/seat-count triggers. |
+
+Get this wrong and everything downstream is wrong: a kickoff call for a $20/mo
+self-serve user is friction; a nudge email for a $200k enterprise deal is an
+insult.
+
+## Step 2 — The sales→delivery handoff
+
+Run this **before** first customer contact. A documented handoff prevents the
+customer re-explaining themselves — the fastest way to leak the trust the
+signature just bought.
+
+The AE briefs the CSM/delivery owner on a handoff packet:
+
+- **Stakeholders & roles** — economic buyer, champion, end users, the skeptic.
+- **Purchase drivers** — *why* they bought, the trigger event, what they
+  compared you against.
+- **Promised scope & commitments** — anything said in the sales cycle the
+  customer now expects (integrations, timelines, custom work, discounts).
+- **Success criteria the buyer bought** — the outcome they're measuring you on.
+- **Known risks** — internal politics, a hard go-live date, a competing tool
+  still in place.
+- **Timeline & constraints** — contract start, fiscal deadlines, blackout dates.
+
+Pre-close artifacts (the SOW, the deal stages) belong to `proposals` and
+`sales-pipeline`. Pull from them; don't re-create them.
+
+## Step 3 — Define "first value" before anything else
+
+You cannot onboard toward a target you haven't named. **Activation ≠ adoption.**
+Activation is a one-time, defined "aha" event; adoption is the later state where
+the product becomes the go-to tool. Define the activation event first.
+
+Pick the **one** event by four tests:
+
+1. **Tied to core value** — it's the thing they're actually paying you for.
+2. **Predictive of retention** — users who hit it stick; users who don't, churn.
+3. **Verifiable** — you can measure it fired, unambiguously.
+4. **Influenceable** — onboarding can directly drive it.
+
+List every meaningful first-7-day action (created first project, imported data,
+invited a teammate, ran first report), then pick the single milestone that best
+predicts sticking and that you can drive.
+
+Write it as **one measurable sentence**:
+
+```text
+Bad:  "The customer is activated when they're using the product."
+Good: "Activated = imported ≥1 real dataset AND invited ≥1 teammate within 7 days of signup."
+```
+
+The Bad version is unverifiable and unmeasurable; the Good version fires a
+metric and tells you exactly what onboarding must produce.
+
+Set a **realistic target** off the benchmark band, not a vanity number:
+
+| Motion | Typical activation rate | Read |
+| --- | --- | --- |
+| Simple tools | 40–60% | — |
+| Complex B2B | 25–40% | — |
+| Freemium | ~20% | — |
+| SaaS average | ≈37.5% | >40% healthy · 30–40% room · <30% concerning · <20% urgent |
+
+## Step 4 — The kickoff (high-touch)
+
+A kickoff is a **working session**, not a welcome call and not a demo. Cover six
+areas, in order:
+
+1. **Introductions** — who's who on both sides.
+2. **Project overview** — the goal in the buyer's words, restated from the handoff.
+3. **Roles & responsibilities (RACI)** — who does what.
+4. **Communication plan** — cadence, channel, escalation path.
+5. **Action items / next steps** — owner + date on each.
+6. **Q&A.**
+
+Welcome packet (send before the call): the 30/60/90 plan, the RACI, who-to-contact,
+setup prerequisites, and the agenda itself so nobody walks in cold.
+
+Compact RACI (R=does it, A=accountable, C=consulted, I=informed):
+
+| Task | Customer champion | CSM | Customer admin |
+| --- | --- | --- | --- |
+| Provision accounts | C | A | R |
+| Import first dataset | A | C | R |
+| Define success metric | A | R | I |
+| Sign-off on go-live | R | A | I |
+
+```text
+Bad:  Subject: We're so excited to have you! 🎉
+      "Welcome aboard! Can't wait to get started. Let us know if you need anything!"
+
+Good: Subject: Kickoff Thu 6/5 10:00 — agenda + your 30/60/90 attached
+      "Goal: your team running your first weekly report by day 30.
+       Agenda (45m): intros · overview · RACI · comms plan · action items · Q&A.
+       Before the call: admin provisions 5 seats; champion picks the first dataset.
+       Owners and dates are in the attached plan."
+```
+
+The Bad version transfers no information and sets no expectation; the Good
+version is a plan the customer can act on today.
+
+## Step 5 — The plan: 30/60/90 and day-0→14
+
+Front-load everything into days 1–30: ~90% of customers form their retention
+opinion in the first 30 days, and ~75% of new users abandon within the first
+week if they never hit value. Each phase row carries an **owner + date + exit
+milestone**.
+
+High-touch 30/60/90 (skeleton — full filled table in references):
+
+| Phase | Focus | Owner | Exit milestone |
+| --- | --- | --- | --- |
+| Day 0–30 | Setup + activation event | CSM + champion | First meaningful outcome delivered (the activation event fires) |
+| Day 31–60 | Expand usage, second use case | CSM | Milestone review meeting; usage across ≥2 teams |
+| Day 61–90 | Prove value, transition | CSM → account team | Value review vs. success criteria; formal transition to steady-state |
+
+Self-serve day-0→day-14 nudge sequence to the activation event:
+
+| When | Trigger | Nudge | Goal |
+| --- | --- | --- | --- |
+| Day 0 | Signup | In-product checklist + one-step setup | Reach the first setup step |
+| Day 1 | No activation yet | Email: "do the one thing" with a deep link | Hit the activation event |
+| Day 3 | Activated | Email: "you did X — now do Y" | Pull toward second value |
+| Day 7 | Not activated | Email: remove the blocker, offer help | Recover the at-risk user |
+| Day 14 | — | Convert/upgrade prompt or graduation | Onboarded exit |
+
+Share the high-touch plan with the customer on **day one** — a 30/60/90 nobody
+sees is internal theater, not onboarding.
+
+## Step 6 — Cut friction to value
+
+The path to the activation event must be the shortest possible.
+
+- **Segment the route by role/use-case**, not the welcome copy. Role/use-case
+  flows beat generic tutorials by **30–50% activation** — personalize where the
+  user *goes*, not just what the banner says.
+- **Minimize setup fields.** Every extra signup/setup field costs ~7%
+  conversion. Defer everything you don't need to reach first value.
+- **Shortest path to the one value moment**, then nurture for the rest.
+
+```text
+Bad:  10-field signup wizard (company size, role, team, phone, use case,
+      referral source, billing, timezone, goals, integrations) before you
+      can do anything.
+
+Good: 2 fields (email, password) → land directly in "import your first
+      dataset" → ask the rest later via progressive disclosure once the
+      user has felt value.
+```
+
+## Step 7 — Instrument it
+
+Measure value, never proxy activity (logins are vanity).
+
+| Metric | Definition | What low means / do |
+| --- | --- | --- |
+| Time-to-Value (TTV) | Signup → first realized value | Long TTV → cut steps; deep-link to the value moment |
+| Activation rate | (users hitting the activation event ÷ total) × 100 | Below the band → wrong event or too much friction |
+| Onboarding-completion rate | Reached the "onboarded" gate ÷ started | Low → the plan stalls; find the drop-off phase |
+| Early-churn rate | Churn within the first ~30/90 days | High → onboarding never delivered first value |
+
+Cutting TTV ~20% has lifted ARR growth ~18% for mid-market SaaS; a smooth
+onboarding makes customers ~53% less likely to churn. This is the lever.
+
+## Step 8 — The "onboarded" exit gate
+
+Onboarding is **done** only when all of these are true. This checklist is the
+boundary with `retention`.
+
+- [ ] Activation event has fired (verifiable, not assumed).
+- [ ] Success plan agreed and shared with the customer.
+- [ ] Communication cadence and escalation path set.
+- [ ] Health baseline captured (usage, key metric, sentiment).
+- [ ] Owner for steady-state named.
+
+When the gate closes, hand off to [`retention`](../retention/SKILL.md):
+onboarding gets them to first value, retention keeps them past it.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails | Do instead |
+| --- | --- | --- |
+| A "welcome!" email instead of a plan | Transfers no information, sets no expectation | Send a plan with owners + dates (Step 4) |
+| No defined activation event | You're onboarding toward nothing measurable | Define one verifiable event first (Step 3) |
+| Letting the customer re-explain after handoff | Leaks the trust the signature bought | Run the sales→delivery handoff first (Step 2) |
+| A 30/60/90 nobody shares with the customer | Internal theater, not alignment | Share it on day one (Step 5) |
+| 10-field setup wizard | ~7% conversion lost per field | 2 fields + progressive disclosure (Step 6) |
+| Generic tutorial for every role | Misses 30–50% activation lift | Segment the route by role/use-case (Step 6) |
+| Onboarding with no exit gate | Never "done"; bleeds into support forever | Define the done-criteria checklist (Step 8) |
+| Measuring logins instead of value | Vanity metric; high logins, low retention | Instrument TTV + activation rate (Step 7) |
+| Kickoff is a demo, not a working session | No decisions, no owners, no momentum | Six-area working agenda (Step 4) |
+| Front-load nothing, hope for day-60 | ~75% abandon in week 1 without value | Front-load days 1–30 (Step 5) |
+| Same motion for every customer | A call insults self-serve; a nudge insults enterprise | Pick the motion first (Step 1) |
+| Treating activation as adoption | Conflates a one-time event with a long-term state | Define activation; leave adoption to `retention` |
+
+## References
+
+Full fill-in templates — sales→CS handoff checklist, welcome-packet template,
+the timed kickoff-call agenda script, a worked RACI matrix, a filled 30/60/90
+table, the day-0→day-14 nudge sequence, and the exit-gate checklist — are in
+[`references/onboarding-playbook.md`](references/onboarding-playbook.md).

package/skills/client-onboarding/evals/README.md

@@ -0,0 +1,14 @@
+# Evals — client-onboarding
+
+These cases are graded by an LLM against the rubric in `cases.yaml`, run through
+the repo's eval harness. The `should_trigger` set (including the non-obvious
+"deal is signed, what now" phrasing and the Spanish/Catalan prompts) checks that
+the router selects `client-onboarding`. The `should_not_trigger` set checks the
+near-miss boundaries route to the named real sibling instead — `customer-support`
+for reactive tickets, `retention` for the post-gate lifecycle, `proposals` and
+`sales-pipeline` for pre-close work. The single `capability` case grades a full
+mid-market onboarding plan against the `must_include` rubric (motion choice,
+handoff packet, defined activation event, kickoff + RACI, an owner/date/exit
+30/60/90, metrics with a realistic band, and the explicit exit gate handed to
+retention). There is no `verify.sh`: this is a judgment skill whose output is a
+plan, so the capability rubric carries the rigor.

package/skills/client-onboarding/evals/cases.yaml

@@ -0,0 +1,40 @@
+skill: client-onboarding
+
+should_trigger:
+  - prompt: "We just closed a new enterprise account — build me an onboarding plan with a kickoff and a 30/60/90."
+    why: "Core high-touch motion: post-signature activation plan with kickoff + phased success plan."
+  - prompt: "How do I define our activation event — what should 'first value' mean for a new signup?"
+    why: "Core job: defining the one verifiable activation event before onboarding toward it."
+  - prompt: "The deal is signed, what happens now so they don't go cold before they're live?"
+    why: "Non-obvious — never says 'onboarding'; it's the post-signature trust-decay window this skill owns."
+  - prompt: "Plan de onboarding para un cliente nuevo con kickoff y plan de 30/60/90."
+    why: "Spanish trigger for the same high-touch onboarding plan; must still route here."
+  - prompt: "Design a day-0 to day-14 nudge sequence to get new free-trial users to their aha moment."
+    why: "Self-serve PLG motion + time-to-value; the day-0→14 activation sequence is squarely this skill."
+  - prompt: "Munta'm el handoff de vendes a CS per a un client que acaba de signar."
+    why: "Catalan, and targets the sales→delivery handoff sub-job specifically."
+
+should_not_trigger:
+  - prompt: "A current customer emailed that the app is down — handle this support ticket."
+    route_to: customer-support
+    why: "Reactive inbound triage from an existing customer, not the proactive first-30-days activation."
+  - prompt: "Build our renewal and churn-reduction program with customer health scores."
+    route_to: retention
+    why: "Ongoing lifecycle after the onboarded gate; this skill ends at that gate."
+  - prompt: "Write the proposal and SOW to send this prospect before they sign."
+    route_to: proposals
+    why: "Pre-close document; client-onboarding starts only after the deal is won."
+  - prompt: "Move this deal from discovery to negotiation and forecast the quarter."
+    route_to: sales-pipeline
+    why: "Pre-close deal stages and forecasting, not the post-close handoff."
+
+capability:
+  - scenario: "A B2B SaaS just closed a mid-market account. The operator has the signed order form and a one-line sales note ('they bought to consolidate reporting; champion is the VP Ops; hard go-live before their Q3') and asks for a full onboarding plan."
+    must_include:
+      - "Picks the high-touch motion and says why (named account, signed order form, multiple stakeholders)."
+      - "Produces a sales→delivery handoff packet: stakeholders/roles, purchase drivers, promised scope, success criteria the buyer bought, known risks, timeline."
+      - "Defines one verifiable activation event tied to core value and predictive of retention — written as a measurable sentence, not 'logged in'."
+      - "Supplies a kickoff agenda covering the six areas (intros, overview, roles/RACI, comms plan, action items, Q&A) plus a compact RACI."
+      - "Lays a 30/60/90 with an owner + date + exit milestone per phase, front-loading days 1–30."
+      - "Names onboarding metrics (TTV, activation rate, early-churn) with a realistic target band, not a vanity number."
+      - "States an explicit 'onboarded' exit gate and hands off to retention."

package/skills/client-onboarding/references/onboarding-playbook.md

@@ -0,0 +1,126 @@
+# Onboarding playbook — fill-in templates
+
+Long, branch-specific lookup material offloaded from `SKILL.md`. Copy the
+relevant block, fill the brackets, delete the rest.
+
+## 1. Sales → CS/delivery handoff checklist
+
+Run this internally **before** first customer contact. Source it from the deal
+record (`sales-pipeline`) and the signed SOW (`proposals`); do not re-interview
+the customer.
+
+```md
+# Handoff: [Customer name] — [order form date]
+AE: [name]   Receiving CSM/owner: [name]   Kickoff target: [date]
+
+## Stakeholders
+- Economic buyer: [name, role] — cares about: [outcome]
+- Champion: [name, role] — internal motivation: [why they pushed this]
+- End users: [teams/roles, headcount]
+- Skeptic / risk: [name, role] — concern: [what could stall this]
+
+## Why they bought
+- Trigger event: [what made them act now]
+- Compared against: [competitors / status quo / build-vs-buy]
+- Primary driver: [the one thing]
+
+## Promised scope & commitments (anything said in the cycle)
+- [ ] [Integration / custom work / timeline / discount / SLA promised]
+- [ ] [...]
+
+## Success criteria the buyer is measuring you on
+- [ ] [Metric or outcome, with target if stated]
+
+## Known risks
+- [ ] [Politics / hard go-live date / competing tool still in place]
+
+## Constraints & dates
+- Contract start: [date]   Hard deadlines: [date]   Blackout windows: [...]
+```
+
+## 2. Welcome-packet contents
+
+Send before the kickoff call so nobody walks in cold.
+
+- The 30/60/90 plan (Section 5 below).
+- The RACI (Section 4).
+- Who-to-contact card: CSM, support channel, escalation path.
+- Setup prerequisites the customer must complete before kickoff.
+- The kickoff agenda (Section 3) with date, time, duration, join link.
+
+## 3. Kickoff-call agenda script (45 minutes, high-touch)
+
+```text
+00:00–00:05  Introductions — names, roles, both sides
+00:05–00:12  Project overview — restate the goal in the buyer's words (from handoff)
+00:12–00:22  Roles & responsibilities — walk the RACI; confirm each owner agrees
+00:22–00:30  Communication plan — cadence, channel, escalation, status-report format
+00:30–00:40  Action items / next steps — every item gets an owner and a date
+00:40–00:45  Q&A — surface blockers now, not in week 3
+```
+
+Close by restating the day-30 exit milestone and the date of the next check-in.
+
+## 4. Worked RACI matrix
+
+R = does the work · A = accountable (one per row) · C = consulted · I = informed.
+
+```text
+| Task                       | Champion | CSM | Cust. admin | Exec sponsor |
+|----------------------------|----------|-----|-------------|--------------|
+| Provision accounts/seats   |    C     |  A  |      R      |      I       |
+| Import first real dataset  |    A     |  C  |      R      |      I       |
+| Define the success metric  |    A     |  R  |      I      |      C       |
+| Configure first workflow   |    C     |  R  |      A      |      I       |
+| Train end users            |    A     |  R  |      C      |      I       |
+| Sign-off on go-live        |    R     |  A  |      I      |      C       |
+| Day-90 value review        |    C     |  R  |      I      |      A       |
+```
+
+## 5. Filled 30/60/90 success plan
+
+```text
+| Phase    | Goal / focus                  | Owner             | Date   | Exit milestone                              |
+|----------|-------------------------------|-------------------|--------|---------------------------------------------|
+| Day 0    | Kickoff + handoff confirmed   | CSM               | [d0]   | Plan shared; prerequisites assigned         |
+| Day 1–7  | Setup + activation event      | Champion + admin  | [d7]   | Activation event fires (e.g. first dataset) |
+| Day 8–30 | First meaningful outcome      | CSM + champion    | [d30]  | First weekly report / first real output     |
+| Day 31–60| Expand to 2nd use case/team   | CSM               | [d60]  | Milestone review; usage across ≥2 teams     |
+| Day 61–90| Prove value vs. criteria      | CSM → account team| [d90]  | Value review; formal transition to retention|
+```
+
+Front-load: most of the work and the activation event land inside days 1–30.
+
+## 6. Self-serve day-0 → day-14 nudge sequence
+
+Channel: in-app for the doer, email for the absent. Each row: trigger → message
+→ goal. Stop the sequence the moment the activation event fires.
+
+```text
+| Day | Channel | Trigger             | Message                                   | Goal                  |
+|-----|---------|---------------------|-------------------------------------------|-----------------------|
+| 0   | in-app  | signup complete     | Checklist + one-step setup, deep-linked   | Reach first setup step|
+| 0   | email   | welcome             | "Your first win in 3 minutes" + deep link | Start the path        |
+| 1   | email   | no activation yet   | "Do the one thing" — single CTA           | Hit activation event  |
+| 3   | email   | activated           | "You did X — now do Y"                     | Pull to second value  |
+| 3   | in-app  | activated           | Surface the next feature in context       | Deepen usage          |
+| 7   | email   | still not activated | Remove the blocker; offer a call/help doc | Recover at-risk user  |
+| 10  | in-app  | activated, low use  | Nudge toward habit-forming action         | Build the habit       |
+| 14  | email   | trial ending soon   | Convert/upgrade or graduate               | Onboarded exit        |
+```
+
+Keep one CTA per message. Two CTAs halve the odds either gets clicked.
+
+## 7. "Onboarded" exit-gate checklist
+
+Onboarding is done only when every box is checked. Then hand off to `retention`.
+
+```md
+- [ ] Activation event has fired (verifiable in product data, not assumed)
+- [ ] Success plan agreed and shared with the customer
+- [ ] First meaningful outcome delivered against the buyer's success criteria
+- [ ] Communication cadence + escalation path set and confirmed
+- [ ] Health baseline captured: usage, key metric, stakeholder sentiment
+- [ ] Steady-state owner named and introduced to the customer
+- [ ] Open promised-scope items closed or explicitly scheduled
+```