Reference for SIR+ command aliases, admin controls, provider override state, and addon permissions.

Main command and aliases

SIR+ keeps sir as the main command, but declares these extra aliases in plugin.yml:

sir-plus
sir+
sirplus
sirp

All of them route to the same admin command tree.

Admin permission tree

SIR+ keeps the normal admin nodes from base SIR and adds addon administration:

Permission	What it unlocks
`sir.admin`	Root `/sir` access
`sir.admin.*`	Full admin tree
`sir.admin.modules`	Module state management
`sir.admin.addons`	Addon state management
`sir.admin.about`	Plugin and runtime info
`sir.admin.reload`	Reload flow
`sir.admin.help`	Help output
`sir.admin.commands`	Provider state and override management
`sir.admin.support`	Support link
`sir.admin.migrate`	Migration commands

Admin subcommands exposed by `MainCommand`

Command	Purpose
`/sir modules`	GUI or CLI module control
`/sir addons`	GUI or CLI addon control
`/sir commands`	GUI or CLI provider control
`/sir reload`	Reload runtime state and language files
`/sir about`	Version and runtime info
`/sir support`	Support link
`/sir migrate [Essentials/SIR/CMI]`	Migration entrypoint

Provider management modes

SIR+ expands provider administration into two different modes:

Mode	Command	What it changes
Provider enabled state	`/sir commands [provider] enabled [state]`	Enables or disables the whole provider
Per-command override state	`/sir commands [provider] override [command] [state]`	Enables or disables override behavior for one command inside that provider

This is the biggest command-management difference between base SIR and SIR+.

Built-in player-facing commands

SIR+ ships the same built-in command set as Modern SIR:

Command	Source	Base permission
`/announce`	`announcements` module	`sir.announce`
`/chat-view`	`channels` module	No explicit shipped node in the module YAML
`/clear-chat`	`clear-chat` provider	`sir.clear-chat`
`/chat-color`	`color` provider	`sir.color`
`/ignore`	`ignore` provider	`sir.ignore`
`/message`	`message` provider	`sir.message`
`/reply`	`message` provider	`sir.reply`
`/mute`	`mute` provider	`sir.mute`
`/tempmute`	`mute` provider	`sir.temp-mute`
`/unmute`	`mute` provider	`sir.unmute`
`/check-mute`	`mute` provider	`sir.check-mute`
`/nick`	`nick` provider	`sir.nick`
`/print`	`print` provider	`sir.print`
`/chat-settings`	`settings` provider	`sir.chat-settings`

Addon-provided commands can join this same ecosystem if the addon implements CommandProvider and ships its own commands.yml.

State files

Provider state and overrides

SIR+ persists provider state inside commands/states.yml:

providers:
  mute:
    enabled: true
    commands:
      mute: true
      tempmute: true

That file controls two things at once:

whether the provider is enabled
whether a specific command inside that provider should be treated as overriding an existing command registration

Addon state

Addon enable state lives in addons/states.yml:

addons:
  example-addon:
    enabled: true

This file is what /sir addons [addon] [enable/disable/toggle] ultimately persists.

Permission planning notes

SIR+ changes staff planning in three practical ways:

staff members who manage addons need sir.admin.addons
staff members who manage provider overrides need sir.admin.commands
addon-provided commands bring their own permission nodes from the addon's commands.yml

That means your final permission model is no longer just "base SIR permissions". It is base SIR permissions plus any addon-defined command permissions.

Recommended setup

For production:

reserve sir.admin.* for trusted operators
grant player-facing command nodes individually
document any addon-defined permissions next to the addon jar you ship
keep a copy of commands/states.yml and addons/states.yml in your deployment backups

If you need the descriptor and lifecycle side of addons, continue with Addon Runtime.

Detailed provider reference

If you need the actual behavior of each built-in command family, continue with Built-in Command Providers.

Commands & Permissions