rsc-universal 0.1.1

package/skills/finance-ops/scripts/verify.sh

@@ -0,0 +1,166 @@
+#!/usr/bin/env bash
+# verify.sh — read-only shape/consistency checks for finance-ops artifacts.
+#
+# Validates the THREE artifacts this skill emits, by filename convention under TARGET:
+#   *forecast*.csv  -> 13-week rolling forecast (columns + net + rolling continuity)
+#   *recon*.csv     -> reconciliation report (every line classified, no orphans)
+#   *close*.csv     -> month-close checklist (required gates present + marked)
+#
+# It checks SHAPE and INTERNAL CONSISTENCY, never whether the dollar figures are correct.
+# Read-only. Exits 0 on an empty or clean target (no false failure). Exits 1 on any broken invariant.
+
+set -euo pipefail
+
+TARGET="${1:-.}"
+fail=0
+
+err() { printf 'FAIL: %s\n' "$1" >&2; fail=1; }
+note() { printf '%s\n' "$1"; }
+
+if [ ! -d "$TARGET" ]; then
+  err "target is not a directory: $TARGET"
+  exit 1
+fi
+
+# Collect candidate artifacts. No matches => clean target => exit 0.
+shopt -s nullglob
+forecasts=()
+recons=()
+closes=()
+while IFS= read -r f; do
+  base=$(basename "$f" | tr '[:upper:]' '[:lower:]')
+  case "$base" in
+    *forecast*.csv) forecasts+=("$f") ;;
+    *recon*.csv)    recons+=("$f") ;;
+    *close*.csv)    closes+=("$f") ;;
+  esac
+done < <(find "$TARGET" -type f -name '*.csv' 2>/dev/null)
+
+total=$(( ${#forecasts[@]} + ${#recons[@]} + ${#closes[@]} ))
+if [ "$total" -eq 0 ]; then
+  note "verify: no finance-ops artifacts found under $TARGET — nothing to check."
+  exit 0
+fi
+
+# --- helpers -------------------------------------------------------------
+
+# index of a column name in a comma header; echoes 1-based index or empty.
+col_idx() {
+  local header="$1" name="$2"
+  awk -v h="$header" -v n="$name" 'BEGIN{
+    m=split(h, a, ",");
+    for (i=1;i<=m;i++){ gsub(/^[ \t]+|[ \t\r]+$/,"",a[i]); if (a[i]==n){ print i; exit } }
+  }'
+}
+
+# --- forecast checks -----------------------------------------------------
+for f in "${forecasts[@]}"; do
+  note "checking forecast: $f"
+  header=$(head -n1 "$f" | tr -d '\r')
+  required=(week_start starting_cash inflows outflows net ending_cash)
+  miss=""
+  for c in "${required[@]}"; do
+    [ -z "$(col_idx "$header" "$c")" ] && miss="$miss $c"
+  done
+  if [ -n "$miss" ]; then
+    err "$f: missing required columns:$miss"
+    continue
+  fi
+
+  i_start=$(col_idx "$header" starting_cash)
+  i_in=$(col_idx "$header" inflows)
+  i_out=$(col_idx "$header" outflows)
+  i_net=$(col_idx "$header" net)
+  i_end=$(col_idx "$header" ending_cash)
+
+  awk -F',' -v s="$i_start" -v in_="$i_in" -v o="$i_out" -v n="$i_net" -v e="$i_end" -v file="$f" '
+    NR==1 { next }
+    NF==0 { next }
+    {
+      starting=$s+0; inflows=$in_+0; outflows=$o+0; net=$n+0; ending=$e+0;
+      # net = inflows - outflows  (tolerance for float)
+      if ((net - (inflows - outflows)) > 0.01 || (net - (inflows - outflows)) < -0.01) {
+        printf("FAIL: %s row %d: net (%.2f) != inflows-outflows (%.2f)\n", file, NR, net, inflows-outflows) > "/dev/stderr"; bad=1
+      }
+      # ending = starting + net
+      if ((ending - (starting + net)) > 0.01 || (ending - (starting + net)) < -0.01) {
+        printf("FAIL: %s row %d: ending_cash (%.2f) != starting_cash+net (%.2f)\n", file, NR, ending, starting+net) > "/dev/stderr"; bad=1
+      }
+      # rolling continuity: ending[n] == starting[n+1]
+      if (have_prev) {
+        if ((starting - prev_end) > 0.01 || (starting - prev_end) < -0.01) {
+          printf("FAIL: %s row %d: starting_cash (%.2f) != previous ending_cash (%.2f) — rolling continuity broken\n", file, NR, starting, prev_end) > "/dev/stderr"; bad=1
+        }
+      }
+      prev_end=ending; have_prev=1; rows++
+    }
+    END {
+      if (rows==0) { print "FAIL: " file ": no data rows" > "/dev/stderr"; bad=1 }
+      exit bad?1:0
+    }
+  ' "$f" || fail=1
+done
+
+# --- reconciliation checks ----------------------------------------------
+for f in "${recons[@]}"; do
+  note "checking reconciliation: $f"
+  header=$(head -n1 "$f" | tr -d '\r')
+  i_status=$(col_idx "$header" status)
+  if [ -z "$i_status" ]; then
+    err "$f: missing required column: status"
+    continue
+  fi
+  awk -F',' -v st="$i_status" -v file="$f" '
+    NR==1 { next }
+    NF==0 { next }
+    {
+      v=$st; gsub(/^[ \t]+|[ \t\r]+$/,"",v);
+      if (v=="") { printf("FAIL: %s row %d: bank line has no status (orphan)\n", file, NR) > "/dev/stderr"; bad=1; next }
+      if (v!="matched" && v!="unmatched" && v!="needs-review") {
+        printf("FAIL: %s row %d: invalid status \"%s\" (must be matched|unmatched|needs-review)\n", file, NR, v) > "/dev/stderr"; bad=1
+      }
+      rows++
+    }
+    END {
+      if (rows==0) { print "FAIL: " file ": no classified lines" > "/dev/stderr"; bad=1 }
+      exit bad?1:0
+    }
+  ' "$f" || fail=1
+done
+
+# --- close checklist checks ---------------------------------------------
+for f in "${closes[@]}"; do
+  note "checking close checklist: $f"
+  header=$(head -n1 "$f" | tr -d '\r')
+  i_gate=$(col_idx "$header" gate)
+  i_cstatus=$(col_idx "$header" status)
+  if [ -z "$i_gate" ] || [ -z "$i_cstatus" ]; then
+    err "$f: missing required column(s): need both gate and status"
+    continue
+  fi
+  awk -F',' -v g="$i_gate" -v st="$i_cstatus" -v file="$f" '
+    NR==1 { next }
+    NF==0 { next }
+    {
+      gate=$g; gsub(/^[ \t]+|[ \t\r]+$/,"",gate);
+      v=$st;  gsub(/^[ \t]+|[ \t\r]+$/,"",v);
+      seen[gate]=1;
+      if (v!="done" && v!="blocked") {
+        printf("FAIL: %s gate \"%s\": status \"%s\" must be done|blocked (missing gate is a failure, not a pass)\n", file, gate, v) > "/dev/stderr"; bad=1
+      }
+    }
+    END {
+      req["transaction_cleanup"]=1; req["bank_reconciliation"]=1; req["payroll_journals"]=1;
+      req["ar_ap_review"]=1; req["expense_categorization"]=1; req["reporting_final_close"]=1;
+      for (k in req) if (!(k in seen)) { printf("FAIL: %s: required gate \"%s\" is missing\n", file, k) > "/dev/stderr"; bad=1 }
+      exit bad?1:0
+    }
+  ' "$f" || fail=1
+done
+
+if [ "$fail" -ne 0 ]; then
+  note "verify: artifact checks FAILED."
+  exit 1
+fi
+note "verify: all finance-ops artifacts pass shape/consistency checks."
+exit 0

package/skills/financial-model/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: financial-model
+description: "Use when a founder needs the multi-period, driver-based projection that raises a round and steers the company — build 3-year projections, model revenue + costs + headcount + runway, size the raise, or stress-test scenarios. Triggers: 'build a financial model for our seed', 'model our revenue costs and runway', 'when do we run out of cash', 'how much should we raise to get 24 months', 'what runway does $2M buy us', 'model the hiring plan's effect on burn', 'add a downside scenario if we miss plan by 30%', 'modelo financiero a 3 años', 'cuánto runway nos da la ronda', 'model financer i projeccions', 'quant de pista de despegament'. The engine is assumptions → revenue/cost/headcount builds → cash/burn/runway/scenarios, 18–36 months forward, every output a formula. NOT the next-13-weeks liquidity reconciled to the actual bank balance (that is finance-ops), NOT the isolated LTV/CAC math (that is unit-economics, which this model consumes as drivers), NOT the slide story (that is pitch-deck)."
+tags: [financial-model, projections, runway, burn-rate, fundraising, fp-and-a, forecast]
+recommends: [finance-ops, unit-economics, pricing, forecasting, pitch-deck, investor-materials, fundraising]
+origin: risco
+---
+
+# Financial model — the projection engine that raises and steers
+
+You are a startup FP&A analyst building the **projection engine**: an assumptions layer that feeds a monthly revenue build, a cost build (COGS + OpEx by function + a headcount plan), and a cash projection that resolves to **net burn, runway, and the cash-out date** — plus a scenario switch (base / downside / upside). It is forward-looking and assumption-driven, 18–36 months out. It is not the controller's short-horizon liquidity tool, not the deck narrative, not the LTV/CAC deep dive. It produces the numbers the fundraising siblings present.
+
+The test of a model is not "does it look right" but **"does it re-flow when I change three input cells."** A spreadsheet of typed-in numbers is a picture, not a model.
+
+## What this skill produces
+
+Three connected artifacts, every output traced to an input:
+
+1. **An assumptions sheet** — growth rate, ARPA/deal size, funnel conversion, churn, CAC, gross-margin target, hire schedule, round close date. One fact lives in one cell. Everything else is a formula off this layer.
+2. **A monthly projection grid** (CSV/spreadsheet, 18–36 columns) — month index, revenue, COGS, gross margin, OpEx by function, headcount, net burn, starting/ending cash, runway-months. This is what `scripts/verify.sh` checks for shape and internal consistency.
+3. **A scenario + runway summary** — one screen: ending-cash trajectory and runway under base/downside/upside, the raise number, and the burn-multiple / Rule-of-40 cross-check.
+
+## What it does NOT do — route out first
+
+This skill answers **"how much / what runway / does the plan tie out."** The moment the real ask is something else, stop and route:
+
+- Next-13-weeks liquidity reconciled to the **actual bank balance**, this-month burn, are-we-solvent-now → `finance-ops`.
+- Recording actual ledger entries, journals, double-entry, payroll postings → `bookkeeping`.
+- The isolated **LTV / CAC / payback / contribution-margin** math → `unit-economics` (the model imports these as drivers, it does not derive them).
+- Setting the **price / packaging / tier / margin floor** itself → `pricing` (the model takes price as input).
+- Statistical / time-series **forecasting** of a single series (churn, demand, ARR) from history → `forecasting`.
+- The slide **story** and decision-grade headline numbers → `pitch-deck`. Packaging the model into the data room / sending it → `investor-materials`.
+- Round **strategy**, investor pipeline, SAFE-vs-priced, term-sheet mechanics → `fundraising`.
+- Per-unit COGS / infra / AI spend as actuals → `cost-tracking`.
+
+## The intake gate
+
+Pin four inputs before you build a single cell. Without them the model is fiction:
+
+| Input | Why it gates everything |
+| --- | --- |
+| **Stage** (pre-seed / seed / Series A) | sets which benchmarks apply and how much runway investors expect |
+| **Current cash** | the numerator of runway; the model is meaningless without it |
+| **Current revenue / MRR + recent growth** | the base the revenue build grows from, not a fresh hockey stick |
+| **Target raise & horizon** (or "size it for me") | the model either takes the raise as input or solves for it from a runway target |
+
+STOP-and-route at the gate:
+
+- If the ask is "what does next quarter's cash look like against the bank" → that is the 13-week tool, route to `finance-ops`.
+- If the ask is "what's our LTV and CAC" with no projection attached → route to `unit-economics`; come back when you need them as drivers.
+- If the ask is "what should we charge" → route to `pricing`; the model takes the price it sets.
+
+## Rule 1 — three layers, no hardcoded outputs
+
+The model is a connected system: **assumptions → drivers → outputs.** Changing a few input cells must re-flow the whole plan. Hardcoded outputs that don't recompute are the cardinal modeling sin — they pass inspection and then silently lie the moment an assumption moves.
+
+```text
+assumptions   growth %, ARPA, churn %, CAC, GM target, hires, close date
+     ↓ (formulas only)
+drivers       new MRR, churned MRR, active customers, headcount cost
+     ↓ (formulas only)
+outputs       revenue, COGS, OpEx, net burn, ending cash, runway
+```
+
+```text
+Bad   revenue_m6 = 95000                      # typed in; won't move when growth changes
+Good  revenue_m6 = active_customers_m6 * arpa # formula; re-flows from the assumptions layer
+```
+
+One fact, one cell. If ARPA appears in two places, the second is a bug waiting to diverge.
+
+## Rule 2 — revenue: bottom-up for the plan, top-down for the prize
+
+Build the operating plan **bottom-up** and sanity-check it **top-down**. Investors want both: bottom-up proves you understand your growth levers, top-down shows the size of the prize. A bottom-up plan with a top-down cross-check is the believable pair; either alone is a tell.
+
+| Approach | Use it for | Strength | Failure mode if used alone |
+| --- | --- | --- | --- |
+| **Bottom-up** (funnel × deal size × capacity) | the monthly operating plan | grounded in levers you control | can miss that the market is too small |
+| **Top-down** (TAM × penetration) | the raise / market-size slide | shows the ceiling | hides whether you can actually acquire — "0.5% of a $10B market" is wishful |
+
+Bottom-up funnel math: `leads → MQL → SQL → opportunity → win`, then `wins × deal size`, capped by `reps × quota` capacity. For subscription revenue, model MRR as a **waterfall** — new + expansion − contraction − churn — not a single growth %. Full funnel and waterfall templates with a worked monthly build are in `references/revenue-build.md`.
+
+## Rule 3 — costs are headcount-driven, not a flat lump
+
+Headcount is the largest cash driver for most early startups, so cost must be modeled per-hire, not as one salary blob. Each hire is `role × fully-loaded cost × start month` — fully-loaded (salary × ~1.25–1.4 for tax/benefits/tooling), and the **start month** matters because moving a hire one quarter moves runway by real weeks.
+
+```text
+Bad   opex_salaries = 150000/mo flat from day 1     # ignores who starts when
+Good  per-hire schedule:
+      Eng1   $11k/mo loaded, starts m1
+      Eng2   $11k/mo loaded, starts m4
+      AE1    $9k/mo  loaded, starts m6   (+ commission as a driver)
+      → salary line is the sum of active hires each month, and it steps, not flat
+```
+
+Then layer COGS sized to hit your gross-margin target (subscription GM should land 75–80%+; total incl. services ~71–77%), and OpEx by function (S&M, R&D, G&A). If your modeled GM sits far below target, the cost build is wrong or the pricing is — flag it, don't paper over it.
+
+## Rule 4 — cash, burn, runway (from cash, never from net income)
+
+Runway is computed from **cash movements, not net income.** Depreciation, prepaids, and unpaid invoices make profit diverge from cash, so the cash projection — not the P&L — is the line that decides survival.
+
+```text
+gross_burn   = total cash outflow (all cash costs)
+net_burn     = gross_burn − revenue
+runway_mo    = current_cash / net_burn          # net_burn > 0
+cash_out     = today + runway_mo months
+ending_cash[m]   = starting_cash[m] − net_burn[m]
+starting_cash[m+1] = ending_cash[m]              # continuity — verify.sh asserts this
+```
+
+Worked example: $400K cash, $25K MRR (~$300K revenue/yr early-ramping), gross burn $95K/mo, revenue $25K/mo → **net burn $70K/mo → runway ≈ 5.7 months.** That is below the panic line; this company should already be raising or cutting.
+
+**Size the raise to the runway target, not to "what we can get."** Investors now expect **18–24 months of post-raise runway**, and best practice is **24–30**. ~12 months of runway has ~3.5× better survival odds than <6. You start raising or cutting at **8–10 months left, never at <6** — raising from a position of <6 months is negotiating with a gun to your head. So: pick the runway target → multiply by projected post-raise net burn → that is the raise, plus a use-of-funds breakdown.
+
+## Rule 5 — scenarios are mandatory; gate assumptions against benchmarks
+
+A single-line hockey stick with no downside reads as naive — investors stress-test the **downside first.** Build **base / downside / upside** off a small set of toggled drivers (growth rate, CAC, churn, hire timing, round close date), and report runway under each. Most cash surprises come from one of these toggles, especially the **round closing late**: model the gap and show runway if the close slips a quarter.
+
+Then run the whole model through a reasonableness gate. Drivers far outside 2025/26 benchmarks are a red flag to **surface, not hide**:
+
+| Check | Reasonable band | What it catches |
+| --- | --- | --- |
+| **Burn multiple** (net burn ÷ net new ARR) | <1.0 elite · 1.0–1.5 healthy · 1.5–2.0 ok early | capital efficiency — in SaaS Capital's 2025 survey 56% of seed / 83% of Series C+ investors call it critical |
+| **Rule of 40** (growth % + FCF margin %) | ≥ 40 | the one-number sanity test; 200% growth AND positive margin is fantasy |
+| **LTV:CAC** | ≥ 3:1 (top quartile 4–6:1) | acquisition economics imported from unit-economics |
+| **CAC payback** | under ~12mo SMB (2025 median worsened to ~20mo) | how long cash is underwater per customer |
+| **NRR** | ≥100% floor · 104–106% typical · 120%+ best | whether the install base grows itself |
+| **Subscription gross margin** | 75–80%+ | is the cost build plausible |
+
+Most companies miss Rule of 40 — McKinsey's run of 200+ software firms (2011–2021) cleared it only ~16% of the time, and Meritech's public-SaaS median sat near 12% in early 2025 — so don't claim it casually. The full benchmark sanity-table, the driver-toggle recipe, and a worked runway-under-scenarios example are in `references/benchmarks-and-scenarios.md`.
+
+## Anti-patterns
+
+| Bad | Good | Why |
+| --- | --- | --- |
+| Hockey-stick revenue, one line, no downside | base / downside / upside off toggled drivers | investors stress-test the downside first; no downside reads as naive |
+| Runway computed from net income / P&L | runway from cash balance ÷ net cash burn | depreciation, prepaids, AR make profit ≠ cash; cash is the survival line |
+| Outputs typed in as numbers | every output a formula off the assumptions layer | a model that doesn't re-flow is a static picture, not a model |
+| Costs as one flat salary lump | per-hire schedule × fully-loaded cost × start month | headcount is the biggest early cash lever; timing moves runway by weeks |
+| Revenue = TAM × wishful % only | bottom-up funnel plan, TAM as the sanity-check | top-down alone hides whether you can actually acquire |
+| Raise sized to "what we can get" | sized to 18–24mo post-raise + a use-of-funds split | the runway target drives the ask, not vice-versa |
+| Round closes instantly in the model | model the close date; show runway if it slips a quarter | timing risk is the most common cash surprise |
+| Same ARPA / churn typed in three tabs | one fact, one cell, referenced everywhere | duplicates diverge silently and the model lies |
+
+## Verify
+
+The model emits a checkable artifact, so `scripts/verify.sh` runs against your generated `model.csv` (or assumptions + projection pair) and asserts **shape and internal consistency** — never whether the forecast is wise:
+
+```bash
+./scripts/verify.sh --path model.csv     # check one model file
+./scripts/verify.sh --path build/        # scan a directory of model CSVs
+./scripts/verify.sh --strict             # treat warnings as failures (CI gate)
+```
+
+It checks: required columns present (month, revenue, cogs, gross_margin, opex, net_burn, ending_cash, runway_months); **cash continuity** (ending_cash[m] == starting_cash[m+1]); **gross_margin == (revenue − COGS)/revenue** recomputes; **net_burn == gross_burn − revenue** ties; runway_months ties to cash ÷ net_burn; ≥1 scenario present; and a defect lint for placeholders (`TBD`, `XX`, `#REF`, `[assumption]`) and impossible values (gross margin >100%/<−100%, negative headcount). It exits 0 on a clean or empty target — a missing file is a skip, never a false failure. The schema it enforces is documented in `references/model-structure.md`.
+
+## Hand-offs
+
+- Need the LTV/CAC/payback that feed the drivers → `unit-economics`.
+- Price/packaging the model assumes → `pricing`.
+- Single-series statistical forecast of churn/ARR → `forecasting`.
+- The near-term bank-reconciled cash view → `finance-ops`.
+- Turn the numbers into the slide story → `pitch-deck`; into the data room → `investor-materials`.
+- Run the actual round off the raise number → `fundraising`.
+
+## references/
+
+- `references/revenue-build.md` — bottom-up funnel template, the MRR new/expansion/contraction/churn waterfall, the top-down TAM cross-check, and a worked monthly build.
+- `references/benchmarks-and-scenarios.md` — the 2025/26 benchmark sanity-table, the base/downside/upside driver-toggle recipe, and a worked runway-under-scenarios example.
+- `references/model-structure.md` — the assumptions/projection row+column contract `verify.sh` enforces, the cash-continuity rule, and the `model.csv` schema with a filled mini-example.

package/skills/financial-model/evals/README.md

@@ -0,0 +1,3 @@
+# Evals — financial-model
+
+`cases.yaml` holds three groups of prompts for this skill's router and capability. Run them against whatever eval harness the repo provides, or check by hand: feed each `should_trigger` prompt to the router and confirm it selects `financial-model`; feed each `should_not_trigger` prompt and confirm it routes to the named sibling (`finance-ops`, `unit-economics`, `pricing`, `forecasting`, `pitch-deck`, `bookkeeping`) and not here — these encode the boundaries that bleed (near-term liquidity, isolated unit economics, pricing, single-series forecasts, the deck, the ledger). The `capability` case is graded against its `must_include` rubric on an actual generated model: build the model for the given seed scenario and tick each rubric line (separate assumptions layer, MRR waterfall, headcount-driven costs, cash-based runway and cash-out date, cash continuity, base/downside/upside off toggles, raise sized to 18–24 months, a benchmark sanity-check, the unit-economics hand-off). Pair the capability grade with `scripts/verify.sh` against the generated `model.csv` to confirm the artifact actually ties out (continuity, recompute checks, defect lint) — the rubric judges assumption quality, verify.sh judges internal consistency. No automated harness is assumed beyond reading the prompts and checking routing plus the rubric.

package/skills/financial-model/evals/cases.yaml

@@ -0,0 +1,53 @@
+skill: financial-model
+
+should_trigger:
+  - prompt: "Build a 3-year financial model for our seed raise with revenue, costs and runway."
+    why: Core, explicit ask — the assumption-driven projection engine that resolves to runway and a raise number.
+  - prompt: "When do we run out of cash and how much should we raise to get 24 months?"
+    why: Non-obvious phrasing; runway-sizing and the raise number are exactly this skill's output, not a deck or a 13-week tool.
+  - prompt: "Model our hiring plan and show what each hire does to monthly burn."
+    why: Headcount-driven cost build (hire × loaded cost × start month) feeding net burn — the model's cost layer.
+  - prompt: "Add a downside scenario — what if we miss revenue by 30% and the round closes 3 months late."
+    why: Scenario toggling off a small driver set (growth, close date) with runway reported per scenario.
+  - prompt: "What runway does a $2M round buy us at our current burn?"
+    why: Non-obvious; takes the raise as input and solves for post-raise runway from cash ÷ net burn.
+  - prompt: "Necesito un modelo financiero a 3 años con proyecciones de ingresos y runway para la ronda."
+    why: Spanish trigger for the full projection engine.
+  - prompt: "Construeix les projeccions financeres i el burn multiple per ensenyar als inversors."
+    why: Catalan trigger, also non-obvious — burn multiple is a model output, and "per ensenyar" still means build the model, not the slide.
+
+should_not_trigger:
+  - prompt: "Build me a 13-week cash flow forecast and reconcile it to the bank statement."
+    route_to: finance-ops
+    why: Short-horizon liquidity reconciled to actual bank balance, not an 18–36 month assumption-driven projection.
+  - prompt: "Calculate our LTV, CAC and payback period."
+    route_to: unit-economics
+    why: Isolated unit-economics math; the model consumes these as drivers but does not derive them.
+  - prompt: "What should we charge and how should we package the tiers?"
+    route_to: pricing
+    why: Sets the price the model takes as an input; choosing the price is pricing's job.
+  - prompt: "Forecast next quarter's churn from our last 18 months of history."
+    route_to: forecasting
+    why: Single-series statistical/time-series forecast, not a driver-based multi-line plan.
+  - prompt: "Turn these numbers into the financials slide for our pitch deck."
+    route_to: pitch-deck
+    why: Narrative/slide packaging of numbers already built, not constructing the projection.
+  - prompt: "Record this month's payroll and vendor invoices in the ledger."
+    route_to: bookkeeping
+    why: Recording actual journal entries, not forward-looking projection.
+
+capability:
+  - scenario: >
+      Seed-stage SaaS, $400K cash, $25K MRR growing ~10%/mo, planning a $2M raise.
+      Build the financial model.
+    must_include:
+      - Assumptions layer kept separate from outputs, with no hardcoded results (every output a formula off assumptions).
+      - Bottom-up revenue build with an MRR waterfall splitting new / expansion / contraction / churn (not a single growth %).
+      - Top-down TAM cross-check that states the implied penetration as a sanity test.
+      - Headcount-driven cost build — per-hire fully-loaded cost and start month, not a flat salary lump.
+      - Cash projection with net burn, runway, and a cash-out date computed from cash movements (not net income).
+      - Cash continuity (ending_cash[m] feeding starting_cash[m+1]).
+      - Base / downside / upside scenarios off toggled drivers, including a round-close-slips toggle, with runway reported per scenario.
+      - Raise sized to an 18–24 month post-raise runway target (not "what we can get"), with a use-of-funds note.
+      - A reasonableness check against at least one benchmark (burn multiple / Rule of 40 / gross margin / LTV:CAC).
+      - An explicit hand-off note to unit-economics for the CAC/LTV driver inputs.

package/skills/financial-model/references/benchmarks-and-scenarios.md

@@ -0,0 +1,55 @@
+# Benchmarks & scenarios — the reasonableness gate and the toggle recipe
+
+Two jobs here: gate the model's drivers against 2025/26 reality, and build the base/downside/upside scenarios off a small toggle set.
+
+## The benchmark sanity-table (2025/26 SaaS)
+
+Run every model through this. A driver far outside its band is a red flag you **surface**, not hide — "our churn assumption is 1%/mo, well below the 3%+ benchmark; here is why" is credible; silently shipping it is not.
+
+| Metric | Formula | Reasonable band | Notes |
+| --- | --- | --- | --- |
+| **Burn multiple** | net burn ÷ net new ARR | <1.0 elite · 1.0–1.5 healthy · 1.5–2.0 ok early · >2 scrutiny | the headline capital-efficiency gauge; SaaS Capital's 2025 survey: 56% of seed / 83% of Series C+ investors call it critical |
+| **Rule of 40** | growth % + FCF (or profit) margin % | ≥ 40 | most companies miss it — McKinsey: 200+ firms cleared it only ~16% of the time (2011–2021); Meritech public-SaaS median ~12% early 2025; the one-number whole-model test |
+| **Subscription gross margin** | (sub revenue − sub COGS) / sub revenue | 75–80%+ | total incl. services ~71–77% |
+| **LTV:CAC** | LTV ÷ CAC | ≥ 3:1 · top quartile 4–6:1 · median ~3.2:1 | imported from `unit-economics` |
+| **CAC payback** | CAC ÷ (ARPA × gross margin) | under ~12mo SMB · 2025 median worsened to ~20mo | months until a customer repays its acquisition cost |
+| **NRR** | (start + exp − contr − churn) ÷ start | ≥100% floor · 104–106% typical · 120%+ best | <100% = leaky bucket |
+| **ARR growth (median)** | YoY ARR growth | ~19–21% median in 2025 | a plan far above median needs the funnel to justify it |
+| **Revenue / employee** | revenue ÷ FTE | ~$130K median private SaaS | reasonableness anchor for the headcount plan |
+| **ARR multiple (valuation)** | enterprise value ÷ ARR | ~4.8x median bootstrapped · 3–5x slow · 8–12x high-growth | sanity-checks implied valuation behind the raise |
+
+### Rule of 40, worked
+
+A plan claiming 200% growth AND positive margin is fantasy; 10% growth at −50% margin fails the test:
+
+```text
+growth 60% + FCF margin −15%  = 45   → passes (healthy growth-funded burn)
+growth 200% + margin +10%     = 210  → implausible, re-examine the assumptions
+growth 10% + margin −50%      = −40  → fails; burning hard with little growth to show
+```
+
+## Scenario recipe — base / downside / upside off toggles
+
+Scenarios are not three hand-typed columns. They are the **same model** with a small driver set toggled, so the whole grid re-flows per scenario.
+
+| Toggle | Base | Downside | Upside |
+| --- | --- | --- | --- |
+| New-revenue growth | plan | −30% | +20% |
+| CAC | plan | +25% | −10% |
+| Monthly churn | plan | +50% rel. | −20% rel. |
+| Key hire timing | plan | +1 quarter slip (slower, cheaper) | as plan |
+| **Round close date** | plan month | +3 months (slips) | on/early |
+
+The **round-close toggle** is the one founders forget and the one that bites: model the gap between today and the close, and show runway if the close slips a quarter. Report **runway under each scenario** — that table is the headline of the summary screen.
+
+## Worked runway-under-scenarios
+
+Start: $400K cash. Base net burn $70K/mo. Toggle effects on net burn and the resulting runway, *before* the raise:
+
+| Scenario | net burn/mo | runway from $400K | reads as |
+| --- | --- | --- | --- |
+| Base | $70K | ~5.7 mo | already past the raise-now line |
+| Downside (−30% rev, +25% CAC, +50% churn) | $92K | ~4.3 mo | tight; cut or bridge |
+| Upside (+20% rev) | $61K | ~6.6 mo | still raising, just calmer |
+
+Sizing the raise off the **base** to a 24-month target at projected post-raise burn (~$110K/mo as the team grows) → raise ≈ $2.6M, then show that the *downside* still buys ≥18 months so the round survives a miss. A raise that only works in the base case is under-sized.

package/skills/financial-model/references/model-structure.md

@@ -0,0 +1,67 @@
+# Model structure — the column/row contract verify.sh enforces
+
+This is the shape `scripts/verify.sh` checks. It validates that the model **computes and ties out**, never whether the forecast is correct.
+
+## Two-part layout
+
+Keep assumptions and projection separate — one fact lives in one cell, and outputs reference assumptions, never the reverse.
+
+**Assumptions sheet** (inputs only, no formulas pointing at outputs): `growth_rate`, `arpa`, funnel rates, `gross_churn_rate`, `expansion_rate`, `cac`, `gross_margin_target`, the per-hire schedule (`role, loaded_cost, start_month`), `starting_cash`, `round_amount`, `round_close_month`.
+
+**Projection grid** (`model.csv`) — one row per month, these columns required:
+
+| Column | Meaning | Tie-out check |
+| --- | --- | --- |
+| `month` | 1..N index (or date) | monotonic, no gaps |
+| `revenue` | recognised revenue that month | from the MRR waterfall |
+| `cogs` | cost of goods sold | — |
+| `gross_margin` | (revenue − cogs) / revenue | **recomputes** to the stated cell |
+| `opex` | total operating expense | sum of function lines |
+| `headcount` | active FTEs | ≥ 0 |
+| `gross_burn` | total cash outflow | — |
+| `net_burn` | gross_burn − revenue | **ties out** |
+| `starting_cash` | cash at month start | == prior `ending_cash` |
+| `ending_cash` | starting_cash − net_burn | **continuity** |
+| `runway_months` | starting_cash / net_burn | ties to cash ÷ net_burn |
+| `scenario` | base / downside / upside | ≥1 present; ≥3 if scenarios claimed |
+
+## The cash-continuity rule
+
+The single most important invariant — the line that makes it a model and not a snapshot:
+
+```text
+ending_cash[m]      = starting_cash[m] − net_burn[m]
+starting_cash[m+1]  = ending_cash[m]
+```
+
+If month 7's start cash is not month 6's end cash, the grid has a broken link and the runway number is meaningless. `verify.sh` asserts this row-to-row.
+
+## Recompute checks (no hardcoded outputs)
+
+These exist to catch typed-in numbers that stopped tracking their inputs:
+
+```text
+gross_margin[m]  ≈ (revenue[m] − cogs[m]) / revenue[m]      (within tolerance)
+net_burn[m]      ≈ gross_burn[m] − revenue[m]
+runway_months[m] ≈ starting_cash[m] / net_burn[m]            (when net_burn > 0)
+```
+
+A cell that fails to recompute is a hardcoded output — the cardinal modeling sin.
+
+## Defect lint
+
+Hard fails on values that cannot be real, warnings on unfinished placeholders:
+
+- **impossible**: `gross_margin` > 100% or < −100%; negative `headcount`; negative `starting_cash` with positive runway claimed.
+- **placeholder**: `TBD`, `XX`, `#REF`, `[assumption]`, `???` anywhere in the grid.
+
+## Filled mini-example (`model.csv`)
+
+```csv
+month,scenario,revenue,cogs,gross_margin,opex,headcount,gross_burn,net_burn,starting_cash,ending_cash,runway_months
+1,base,25000,5000,0.80,90000,6,95000,70000,400000,330000,5.7
+2,base,29625,5925,0.80,92000,6,97925,68300,330000,261700,4.8
+3,base,34930,6986,0.80,95000,7,101986,67056,261700,194644,3.9
+```
+
+Note `ending_cash` of month 1 (330000) equals `starting_cash` of month 2 — continuity holds. `gross_margin` 0.80 == (25000−5000)/25000 — recompute holds. `net_burn` 70000 == 95000−25000 — ties out. A real model spans 18–36 rows per scenario and adds the function-level OpEx columns; these are the minimum verify.sh requires.

package/skills/financial-model/references/revenue-build.md

@@ -0,0 +1,68 @@
+# Revenue build — bottom-up funnel + MRR waterfall + top-down cross-check
+
+The revenue line is built **bottom-up** for the operating plan and **cross-checked top-down** for the raise. Build both; present both.
+
+## Bottom-up: funnel math
+
+The plan grows from the levers you actually pull. Model the funnel month by month:
+
+```text
+leads      → MQL        → SQL        → opportunity → win
+   × mql_rate  × sql_rate   × opp_rate    × win_rate
+```
+
+Then revenue from wins:
+
+```text
+new_customers[m] = leads[m] * mql_rate * sql_rate * opp_rate * win_rate
+new_bookings[m]  = new_customers[m] * deal_size
+```
+
+Cap it by **capacity** so the plan stays honest — you cannot close more than your reps can carry:
+
+```text
+capacity[m] = active_reps[m] * quota_per_rep
+new_bookings[m] = MIN(funnel_bookings[m], capacity[m])
+```
+
+Every rate, deal_size and quota lives in the assumptions sheet. A plan that grows leads 40%/mo with flat conversion and no extra reps is a hockey stick in disguise — the capacity cap exposes it.
+
+## MRR waterfall (subscription revenue)
+
+For recurring revenue, never grow MRR by a single "+X%/mo". Model the waterfall so each component is a visible, toggleable driver:
+
+```text
+starting_MRR[m]
+  + new_MRR[m]          = new_customers[m] * arpa
+  + expansion_MRR[m]    = active_customers[m] * expansion_rate * arpa
+  − contraction_MRR[m]  = active_customers[m] * contraction_rate * arpa
+  − churned_MRR[m]      = active_customers[m] * gross_churn_rate * arpa
+  = ending_MRR[m]       → starting_MRR[m+1]
+revenue[m] = ending_MRR[m]   (or average of start/end for an accrued view)
+```
+
+This split is what lets a downside scenario move *churn* without touching *new* — the whole point of a driver-based model. It also surfaces **NRR** directly: `NRR = (starting + expansion − contraction − churn) / starting`. NRR ≥100% means the install base grows itself; <100% means you are refilling a leaky bucket and every new sale is partly replacement.
+
+## Top-down: TAM cross-check
+
+Top-down does not build the plan — it sanity-checks the ceiling:
+
+```text
+TAM        = total addressable accounts * annual_contract_value
+SAM        = TAM * serviceable_fraction
+year3_rev  = SAM * target_penetration
+```
+
+The test: does your bottom-up Year-3 revenue imply a **plausible penetration** of SAM? If bottom-up says $40M ARR but that is 35% of SAM in three years, the bottom-up is fantasy. If bottom-up is 0.1% of SAM, either the market is far bigger than the plan needs (fine) or your funnel is too timid. Show the implied penetration number explicitly — investors compute it anyway.
+
+## Worked monthly build (mini, 3 months shown)
+
+Assumptions: arpa $500/mo, leads 200/mo growing 15%/mo, funnel product 5% (lead→win), expansion 1.5%, churn 3%, starting MRR $25,000 (50 customers).
+
+| m | leads | new cust | new MRR | churn MRR | exp MRR | end MRR | end cust |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 1 | 200 | 10 | 5,000 | 750 | 375 | 29,625 | 59 |
+| 2 | 230 | 11 | 5,750 | 889 | 444 | 34,930 | 68 |
+| 3 | 264 | 13 | 6,600 | 1,048 | 524 | 41,006 | 78 |
+
+Every number above is a formula off the assumptions row — change `churn` to 5% and the whole table re-flows. That is the contract. Feed `arpa`, the funnel rates, churn and CAC from `unit-economics` rather than inventing them here.