One sentence in Skript carries more machinery than all the others combined:
score it with ai
In production this hands the event's subject — the lead, the submission, the message — to Skode's AI, which reads everything known about it and produces two values: score, a number from 0 to 100, and heat, a band derived from it. From that moment both names are available to conditions and interpolation, and score is hot becomes the most consequential five letters in your rule.
| heat | when |
|---|---|
hot | score 75 and above |
warm | 45 – 74 |
cold | below 45 |
The simulator's stand-in
Locally there is no production AI, so the interpreter simulates one — and it does so honestly rather than randomly. The simulated scorer reads the same signals a real one would consider — is there a phone number? an email? a meaningful budget? a warm source? intent words like "pricing" in the text? — and builds the score from them, plus a small deterministic wobble. Same input, same score, every time:
when a new lead arrives score it with ai log "scored {score}, {heat}"
▶ example.skript — Skode Skript · local simulation ● event: lead.created → name: Ada Lovelace · phone: +1 555 0100 · email: [email protected] ⚡ score it with ai → score 79 · HOT (simulated ai — signals: phone, email, budget, source) • log → scored 79, hot ✔ done in 2.1ms
The trace's score line lists which signals fired, so a surprising score always explains itself. Strip the demo lead of its signals and the score collapses accordingly:
when a new lead arrives score it with ai log "scored {score}, {heat}"
▶ example.skript — Skode Skript · local simulation ● event: lead.created → name: Mystery · phone: · email: ⚡ score it with ai → score 24 · COLD (simulated ai) • log → scored 24, cold ✔ done in 2.1ms
Two runs, two honest scores — a fully-qualified lead runs hot, an anonymous one runs cold, and nothing about it is magic. But remember the caveat that matters: the simulated score is a development aid. It approximates the shape of real scoring so your branches exercise realistically; it does not predict what production AI will say about a particular lead.
Pinning the score
Which raises the real question: how do you test the hot branch, the cold branch, and the boundary, deliberately? With --score, which overrides the simulation entirely:
when a new lead arrives score it with ai if score is hot then log "hot path taken" otherwise log "cold path taken"
▶ example.skript — Skode Skript · local simulation ● event: lead.created → name: Ada Lovelace · phone: +1 555 0100 · email: [email protected] ⚡ score it with ai → score 75 · HOT ✓ if score is hot → yes • log → hot path taken ✔ done in 2.1ms
75 is exactly the hot boundary — and the trace shows it lands hot, pinning down an off-by-one you would otherwise wonder about. A disciplined habit: any rule that branches on heat gets run at least three times before deploying — --score 90, --score 60, --score 10 — and Chapter 14 makes that a one-liner each.
Guardrails, as always
Asking score is hot before any score it with ai has run is not a silent false — it is a specific error, because it is always a genuine mistake:
when a new lead arrives if score is hot then stop
✗ line 2: "score is hot" needs "score it with ai" first
Score as a number
heat covers most routing, but score is an ordinary number and the comparison conditions all apply — useful when your thresholds differ from the built-in bands:
when a new lead arrives score it with ai if score is at least 80 then assign to "Maya" and add tag "priority" if score is above 95 then create task "White-glove this one" for "Maya"
▶ example.skript — Skode Skript · local simulation ● event: lead.created → name: Ada Lovelace · phone: +1 555 0100 · email: [email protected] ⚡ score it with ai → score 82 · HOT ✓ if score at least 80 → yes → assign to "Maya" → lead assigned ⚑ add tag "priority" → tagged ✗ if score above 95 → no ✔ done in 2.1ms — assigned to Maya · tags: priority
Both conditions read the same score; one passed, one did not, and the trace shows each verdict separately. This — scoring once, branching several ways — is the backbone of every triage skript you will ever write, and you now have all of its parts.