Word Filter

• Stops slurs, hate speech, and targeted harassment the moment they are posted.
• Blocks names, phrases, or keywords specific to your community — scam URLs, banned terms, inside-drama topics.
• Lets you escalate severity by package: a ban for hate speech, a delete for mild swears, all in one rule.
• Saves moderator time — most word-filter hits never need a human.

Messages containing any word from the resolved word list: the union of every word in the enabled preset packages plus the rule's custom_words. Matching is case-insensitive by default and uses word boundaries, so ass does not match assassin.

• Words inside embeds, attachment filenames, sticker names, or reactions — only message content is scanned.
• Leetspeak or character-substitution obfuscation (n1gger, f u c k).
• Unicode variants — stylised fonts like ⓕⓤⓒⓚ or fullwidth text are not normalised before matching.

Six curated packages ship with Arkanis. Each package is tagged so per-package action overrides can target it.

By default, every matched word runs the rule's configured action. The optional package_actions map lets you override that on a per-package basis — ban for hate speech, strike for harassment, delete for mild swears.

{
  "package_actions": {
    "hate_speech": {
      "action": "ban",
      "severity": "major",
      "discord_ban": true,
      "reason_text": "Hate speech"
    },
    "profanity_mild": {
      "action": "none"
    }
  }
}

• action can be delete, warn, mute, strike, ban, or none.
• action: "none" degrades to a plain delete — the message is still removed, but no enforcement action follows.
• Severity, reason codes, and mute durations can all be overridden per package.
• Words added to custom_words are tagged custom — target that tag in package_actions to give your own list its own action.

A balanced baseline for most community servers:

{
  "preset_packages": [
    "hate_speech",
    "harassment_threats",
    "sexual_explicit",
    "nsfw_terms",
    "profanity_harsh"
  ],
  "allow_swearing": false,
  "nsfw_server": false,
  "custom_words": []
}

Run with Mode: Log Only, case-insensitive matching, and word boundary on until you have watched the Event Log for a week and tuned anything noisy. Then flip to Live.

• Word-boundary collisions — a word like hell matches inside hellcat only if word boundaries are off, but still inside phrases like hell-yeah because - is a non-word character.
• Medical or educational discussion — anatomical words flagged in every context, including book club threads.
• Quoted slurs in a news story, academic citation, or song lyric — the filter has no concept of context.
• Loanwords from other languages that overlap with English slurs (ass inside Spanish or French words).
• Nicknames and usernames inside the message body — a mention like @somerude is treated as plain content.

• Current behavior: word_filter always deletes the matching message first, even when the configured action is Warn, Mute, Strike, or Ban. The content never stays visible once the rule fires. This is by design — a slur left in channel while the bot issues a warn is the wrong outcome.
• Current behavior: allowlist words apply to content-match triggers only. Word Filter is one of them. If any allowlist word appears anywhere in the message (substring-matched, lowercase), the rule is skipped entirely. A short allowlist entry like hell would accidentally whitelist messages containing hello — use specific phrases rather than common fragments. Volumetric triggers (Mention Spam, Spam Detection, etc.) are not affected by the allowlist.
• Current behavior: the legacy words field is ignored when preset_packages has any entries. Older rules may carry a raw words array — migrate it to custom_words or leave preset_packages empty.
• Current behavior: matching does not normalise Unicode. Stylised fonts (mathematical italic, fullwidth, accented letters) bypass the filter. Add important variants as custom words if coverage matters.
• Current behavior: word boundary follows Python's \b rules. Underscores and digits count as word characters, so shit_ will not match the word shit.
• Current behavior: per-package overrides replace the rule's default action for that package's matches. A rule with default action Warn and a hate_speech override of Ban will ban on slur matches and warn on everything else.

Pair this trigger with any of the five AutoMod actions. Unique to word_filter: the message is always deleted first, even on non-delete actions — a slur should never stay visible while the bot issues a warn or a strike.

• Regex Filter — same content-matching space, different pattern language. Use when literal word lists aren't enough.
• Link Filter — also scans message content. Pair for scam URLs that slip past a word list.
• Invite Filter — related content scan targeting Discord invite links.
• Mention Spam — another content-based trigger on the same message; layer both for harassment-by-ping cases.