Modern command-provider reference

Modern SIR stores player-facing command families under command/* and extracts them into plugins/SIR/commands/.

Every provider normally owns:

• commands.yml for registration, aliases, and permission metadata
• lang.yml for feedback text
• optional state or menu files such as data.yml, menu.yml, or settings.yml

The important difference from Legacy is that these are no longer random folders inside one command umbrella. They are real feature units with their own lifecycle and state.

---

Clear Chat

The clear-chat provider is the dedicated moderation tool for wiping public chat.

Files

• commands.yml
• lang.yml

Main command

• /clear-chat

Common aliases

• clearchat
• cc
• clear

Base permission

• sir.clear-chat

What it owns

• command registration
• help and success feedback
• the stock moderation-facing chat-clear action

Migration from Legacy

This is the renamed successor to /clearchat with sir.clearchat. The behavior is familiar, but the label and node name are not.

---

Color

The color provider owns the chat color and style workflow.

Files

• commands.yml
• data.yml
• lang.yml
• menu.yml

Main command

• /chat-color

Common aliases

• chatcolor
• color

Base permission

• sir.color

Typical derived permissions

• sir.color.black
• sir.color.bold
• sir.color.gradient
• sir.color.reset

What it owns

• per-player color selections
• the selector UI in menu.yml
• language feedback
• permission-gated access to colors and styles

Why data.yml matters

This provider is one of the clearest examples of Modern SIR separating player data from feature config. The command family owns the interaction flow, while the persisted result lands in normalized user-oriented storage during runtime and migration.

Migration from Legacy

This replaces the old /chatcolor family and renames the base node from sir.chatcolor to sir.color.

---

Ignore

The ignore provider owns personal ignore-list management.

Files

• commands.yml
• data.yml
• lang.yml

Main command

• /ignore

Alias

• ig

Base permission

• sir.ignore

What it owns

• add and remove ignore relationships
• persisted ignore state
• language feedback for list management

Why it is operationally important

It may look simple, but it directly affects player-to-player messaging and chat expectations. If ignore behavior breaks, players feel it immediately.

---

Message

The message provider owns stock private messaging.

Files

• commands.yml
• lang.yml

Commands

• /message
• /reply

Aliases

• /message: m, msg, tell
• /reply: r

Base permissions

• sir.message
• sir.reply

What it owns

• player-to-player private messages
• reply continuity
• formatting and feedback for direct communication

Dependency note

reply is not a completely independent family. It depends on the message workflow existing correctly.

Migration from Legacy

Conceptually this replaces the old msg-reply.yml model with a cleaner provider layout.

---

Mute

The mute provider owns the core mute administration workflow.

Files

• commands.yml
• data.yml
• lang.yml

Commands

• /mute
• /tempmute
• /unmute
• /check-mute

Base permissions

• sir.mute
• sir.temp-mute
• sir.unmute
• sir.check-mute

What it owns

• permanent mutes
• timed mutes
• mute removal
• mute lookup
• persisted mute data

Why it matters in migration

This is one of the places where admins most often forget to rename permission nodes. If your permissions plugin still contains sir.mute.perm or sir.checkmute, staff will suddenly lose commands after the upgrade.

---

Nick

The nick provider owns nickname changes.

Files

• commands.yml
• lang.yml

Main command

• /nick

Alias

• nickname

Main permissions

• sir.nick
• sir.nick.other

What it owns

• changing your own nickname
• changing someone else's nickname when staff have the extra permission
• user-facing feedback around nick changes

Why it stands out

This provider often feels new to Legacy operators because there is no equally clear standalone shipped family in the old branch.

---

Print

The print provider is the modern raw-output tool for staff.

Files

• commands.yml
• lang.yml

Main command

• /print

Common aliases

• raw-message
• raw-msg
• rawmsg

Base permission

• sir.print

Typical derived permissions

• sir.print.targets
• sir.print.chat
• sir.print.action-bar
• sir.print.title

What it owns

• raw formatted output to supported surfaces
• target handling
• feedback text for staff tooling

Migration note

Legacy operators often used extra selector or webhook-style behavior with this family. Audit your actual usage before assuming the modern provider is identical.

---

Settings

The settings provider owns player-side communication preferences.

Files

• commands.yml
• lang.yml
• settings.yml

Main command

• /chat-settings

Common aliases

• settings
• chatsettings
• csettings
• c-settings

Base permission

• sir.chat-settings

What it owns

• communication-related user toggles
• the metadata for those toggles in settings.yml
• a clean player-facing preferences surface separate from admin commands

Why it matters

This provider is where the plugin stops being only an admin toolkit and becomes a player UX system.

---

Provider audit checklist

When reviewing a Modern SIR command family:

1. read commands.yml for registration and permissions
2. read lang.yml for user-facing expectations
3. inspect data.yml, menu.yml, or settings.yml if the provider persists state
4. compare old Legacy node names before you update your permissions plugin
5. test provider state through commands/states.yml before assuming the config is wrong