Skip to main content
Actions let a custom command perform real operations. They reuse slug’s native moderation pipeline, so hierarchy checks, immunity, and case logging all apply.

Anatomy

  • Arguments inside an action are separated by &&.
  • The action tag is removed from the rendered message once it runs, so surrounding text stays visible.
  • Actions run near the end of the pipeline, after variables and database tags.
Warned @wanderer — case #104.

Naming a target

Anywhere an action expects a member you may pass: Roles accept a role mention, a role ID, or an exact role name. Durations accept combined units — 30s, 10m, 1h30m, 7d, 2w. Timeouts and {mod:role.temp} are capped at 28 days (Discord’s timeout limit); {mod:role.persist} durations are not capped.

Moderation actions

{mod:mute} and {mod:unmute} are aliases for timeout and untimeout. Every one of these writes a moderation case and fills the {punishment.*} variables.
If the target is immune under your moderation settings, the action is skipped silently and no case is logged. Role actions also refuse roles that sit above slug or carry Administrator. Per command, {nohierarchy} skips the author-vs-target hierarchy check — permissions and slug’s own hierarchy still apply.

Persistent roles

Discord strips a member’s roles when they leave, so a restriction role on its own is easy to dodge by rejoining. {mod:role.persist ...} adds the role and records it, so slug re-applies it whenever the member rejoins.
🔇 @wanderer can no longer join the Gaming VC.
  • The duration is optional. If the first word after the role parses as a duration (30m, 1d, 2w, …) it becomes an expiry; otherwise the whole tail is treated as the reason and the role is permanent. So both ;gamingvcban @wanderer and ;gamingvcban @wanderer ban evasion are permanent.
  • A timed persistent role is auto-removed when it expires and is not re-applied if the member rejoins after it has expired.
  • Removing the role clears the memory. {mod:role.remove ...}, {mod:role.toggle ...} when it turns the role off, and the normal ;role remove command all forget the persisted role, so it will not return on rejoin.
  • Re-running the action refreshes the timer and reason, exactly like {mod:role.temp}.
Persistence also covers {mod:role.temp}: while a temporary role is still inside its duration, slug re-applies it on rejoin.

Economy actions (removed)

{econ:add}, {econ:remove}, {econ:set}, and {econ:transfer} no longer exist. slug’s economy is global — one balance per user across every server — so a Manage Server holder in any guild could have minted unlimited currency for themselves. Writing {econ:add ...} in a script now does nothing; the tag is left in the message as plain text.
The read-only economy variables are unaffected: {econ.balance}, {econ.wallet}, {econ.bank}, {target.econ.balance}, and the rest still work everywhere. See Economy data.

Custom database actions

These are the permission-gated, write-only form. To read a value, or to read back something you just wrote in the same response, use the inline database tags instead — those resolve earlier in the pipeline and render their result in place.

Permission gating

1

When you save the command

;cc set scans the script, works out which permissions its actions need, and refuses to save unless you hold every one of them.
2

When someone runs it

The invoker must hold those same permissions — unless a user or role allow entry covers them, which bypasses the action permission check.
An allowed channel does not bypass permissions. Only user and role allow entries do.
A misspelled operation such as {mod:bam ...} maps to no permission, so it is neither gated nor executed. If it is the only action in the script the tag is left in the message as literal text; alongside a valid action it is silently dropped. Either way, run ;cc preview before publishing.
Actions can also be attached to buttons and dropdown options; see Embeds and components.