Talking to the Business: Built-in Actions

Everything so far — variables, loops, functions — is the grammar of Skript. This chapter is the vocabulary: the built-in actions that reach out of the program and into your business. In the simulator they print what they would do; in production they do it.

reply — answer the person in front of you

reply messages whoever triggered the event — the lead who arrived, the sender of the message. Its channel defaults to WhatsApp, and the message can sit inline or, when it deserves its own line, indented underneath:

when a new lead arrives
  reply on whatsapp "Quick hello, {name}!"
  reply on email
    "A longer note deserves its own line."
    "Each quoted line becomes one line of the message."

▶ example.skript — Skode Skript · local simulation

  ● event: lead.created                → name: Ada · phone: +1 555 0100 · email: [email protected]
  ✉ reply on whatsapp                  → "Quick hello, Ada!"
  ✉ reply on email                     → "A longer note deserves its own line.\nEach quoted line becomes one line of the message."

  ✔ done in 2.1ms — 2 messages

The indented-string form is unique to reply: write the message as one or more quoted lines beneath it, and they join into a single multi-line message. Notice in the trace where the reply went: the simulator picked the lead's phone for WhatsApp — the subject's contact details travel with the event.

send — message anyone, on any channel

Where reply answers the event's subject, send names its own target:

when a new lead arrives
  send email to "[email protected]" "Hot inbound: {name}, budget {budget}"
  send slack "New lead {name} just landed"

▶ example.skript — Skode Skript · local simulation

  ● event: lead.created                → name: Ada · phone: +1 555 0100 · email: [email protected]
  ✉ send email to "[email protected]"      → "Hot inbound: Ada, budget 5000"
  ✉ send slack                         → "New lead Ada just landed"

  ✔ done in 2.1ms — 2 messages

The channel comes first, an optional to "address" next, the message last. Skript knows six channels: whatsapp, email, sms, instagram, webchat, slack. Naming any other channel is a parse error that lists the six — no silent guessing about where a message might go.

assign, add tag — route and label

when a new lead arrives
  assign to "Maya"
  add tag "inbound" and add tag "priority"

▶ example.skript — Skode Skript · local simulation

  ● event: lead.created                → name: Ada · phone: +1 555 0100 · email: [email protected]
  → assign to "Maya"                   → lead assigned
  ⚑ add tag "inbound"                  → tagged
  ⚑ add tag "priority"                 → tagged

  ✔ done in 2.1ms — assigned to Maya · tags: inbound, priority

assign to "Maya" hands the event's subject to a teammate (assign it to "Maya" reads better in some sentences and is identical). add tag labels the record; tags accumulate, and the run summary counts them. These two are the bread and butter of routing rules — most production skripts are, at heart, a decision followed by an assign and a couple of tags.

create task — leave work for a human

Some follow-ups should not be automated. create task puts an item on a teammate's list, with the title interpolated like any string:

when a new lead arrives
  create task "Call {name} back today" for "Maya"
  create task "Update the forecast"

▶ example.skript — Skode Skript · local simulation

  ● event: lead.created                → name: Ada · phone: +1 555 0100 · email: [email protected]
  ☑ create task "Call {name} back today" → created
  ☑ create task "Update the forecast"  → created

  ✔ done in 2.1ms — 2 tasks

The for "Name" part is optional — without it the task lands unassigned, for whoever triages the queue.

wait — patience as a step

wait pauses the automation: wait 10 minutes, wait 2 hours, wait 3 days (seconds work too). In the simulator it is instant and says so; in production it genuinely schedules the continuation, which is what makes drip sequences possible:

when a new lead arrives
  reply on email "Welcome aboard, {name}!"
  wait 2 days
  reply on email "How is it going so far?"

▶ example.skript — Skode Skript · local simulation

  ● event: lead.created                → name: Ada · phone: +1 555 0100 · email: [email protected]
  ✉ reply on email                     → "Welcome aboard, Ada!"
  ◌ wait 2 days                        → (simulated — instant here, real delay in Skode)
  ✉ reply on email                     → "How is it going so far?"

  ✔ done in 2.1ms — 2 messages

This is the one action whose local and production behaviours meaningfully differ, so the trace flags it loudly. Design consequence worth absorbing: everything after a wait runs later, against the world as it will be then — keep the steps after a long wait simple and self-contained.

log and say — notes to the trace

You know log; say is its exact synonym for when a sentence reads better out loud. Neither touches the outside world in any environment — they exist for the humans reading the trace, and seasoned skript-writers sprinkle them at decision points as running commentary. A rule that narrates itself is a rule nobody has to debug.

The whole toolbox, one table

Nine actions. With the grammar chapters behind you, you now know — in the strictest sense — the entire language except one action. That action gets its own chapter, because it is the one with a mind of its own.