What custom commands do (short)

Custom commands let staff create trigger phrases (plain text, not slash commands) that the bot watches for and automatically replies with a stored response. Use them for canned replies, FAQ answers, role instructions, or small automation flows without building a full bot module.

Important implementation notes (how triggers work)

• Normalization: triggers are normalized before storage and matching — the system lowercases, trims, and strips non-alphanumeric characters. This makes matching predictable and prevents duplicate triggers that only differ by punctuation or case. (If you create !hello the trigger is normalized to hello.)

• Uniqueness: normalization is used to detect existing triggers; trying to create a trigger whose normalized form already exists will fail with a “already exists” message. The bot upserts commands by normalized trigger.

• Persistence: custom commands are persisted to your server store (MongoDB) and served through a small service that caches results for performance. This means custom commands survive restarts and are available to the whole server.

• Access control: creating/editing/deleting commands requires dashboard access for rocket-custom-commands (the API enforces requireAccess). In practice, that maps to staff/managers configured via the Command Permissions dashboard page.

Commands (purpose, syntax, examples, tips)

/custom create <name> <response>

Purpose — Create a new message trigger and its response (enabled by default).
Syntax

/custom create name:<trigger> response:"Your response text"

Example

/custom create name:rules response:"Please read #rules and accept the verification button."

Notes / tips

• name is the human trigger phrase. The system normalizes it (lowercase, remove punctuation) so choose a short phrase with letters/numbers. The service rejects empty/invalid triggers.

• If the normalized trigger already exists, creation will fail with a “already exists” confirmation. The service uses an upsert when adding commands.

/custom delete <name>

Purpose — Remove a custom trigger from the server.
Syntax

/custom delete name:<trigger>

Example

/custom delete name:rules

Notes / tips

• Deletion removes the persisted command and clears the cache for that server. The command requires the trigger (normalized form) to exist.

/custom edit <name> <new_response>

Purpose — Replace the stored response text for an existing trigger.
Syntax

/custom edit name:<trigger> new_response:"New reply text"

Example

/custom edit name:rules new_response:"Please read #rules, then press Verify."

Notes / tips

• Edit will fail if the trigger doesn’t exist. It upserts the updated record and enables it by default.

/custom list

Purpose — Show all custom triggers for the server (includes enabled/disabled state).
Syntax

/custom list

Example

/custom list

Notes / tips

• The response lists - \trigge - Enabled|Disabled for each command. Use this to audit or find exact trigger text.

/custom show <name>

Purpose — Display the stored response for a specific trigger.
Syntax

/custom show name:<trigger>

Example

/custom show name:rules

Notes / tips

• Useful to quickly preview what the bot replies for a trigger before enabling/disabling or editing.

/custom enable <name> / /custom disable <name>

Purpose — Re-enable or temporarily disable a custom trigger without deleting it.
Syntax

/custom enable name:<trigger>
/custom disable name:<trigger>

Examples

/custom disable name:rules
/custom enable name:rules

Notes / tips

• The system stores the enabled flag and the listing commands can include disabled entries when requested. Use disable for maintenance or seasonal responses.

/custom variables

Purpose — Shows supported template variables you can use inside a response.
Syntax

/custom variables

Output

Supported variables:
- {user} mentions the user
- {channel} mentions the channel

Notes / tips

• At present the service documents {user} and {channel} as supported placeholders — they are substituted when the bot posts the response. (If you expected {args} or other placeholders, note those are not returned by the current variables listing.)

Who can run these commands

• The API/service requires dashboard access for rocket-custom-commands (i.e., staff or managers who have been granted dashboard Command Permissions). Use the Dashboard → Command Permissions UI to grant Manager or Custom access to your team. The API enforces access checks before listing or changing commands.

Troubleshooting & gotchas

• Command not firing in chat

  • Confirm the trigger is enabled (/custom list shows it as Enabled).

  • Remember triggers are normalized — punctuation and casing are removed before matching. If your trigger uses punctuation, create the phrase without it (or check how it’s normalized).

• “Already exists” when creating

  • That means the normalized version of the trigger exists. Pick a different trigger or delete/rename the existing one.

• Responses don’t substitute placeholders

  • Supported placeholders are {user} and {channel}; anything else won’t be expanded. Use /custom variables to confirm what’s available.

• Permission or access errors

  • The server’s Command Permissions and dashboard access control the ability to manage custom commands. If the API returns an access error, check that the staff member has the Rocket dashboard permission scope for custom commands.

Best practices

• Pick short, unique trigger phrases. Avoid extremely generic words that will accidentally fire during normal conversation.

• Keep responses focused. Use placeholders ({user}, {channel}) to personalize replies without making templates brittle.

• Use disable for temporary changes. Disable instead of delete when you plan to re-enable a response (keeps history and makes reactivation easy).

• Audit with /custom list regularly. Remove old or duplicate triggers to avoid confusion.

Quick cheat-sheet

/custom create name:<trigger> response:"Your response"
/custom delete name:<trigger>
/custom edit name:<trigger> new_response:"Updated text"
/custom list
/custom show name:<trigger>
/custom enable name:<trigger>
/custom disable name:<trigger>
/custom variables