name: mcc-chatbot-authoring
description: Create, modify, repair, and wire Minecraft Console Client ChatBots and standalone /script bots. Use this whenever the user wants an MCC bot, C# script bot, chat or event handlers, periodic automation, movement logic, inventory logic, plugin-channel handling, or asks to fix or port an existing bot; default to standalone //MCCScript bots unless the user explicitly asks for a built-in MCC bot or repo wiring.
MCC ChatBot Authoring
Implement MCC chat bots against the bundled MCC authoring reference. Do not invent methods, lifecycle hooks, or registration steps.
Always read:
references/authoring-reference.md
Load only as needed:
references/pattern-cookbook.mdfor concrete standalone examplesassets/script-chatbot-template.csfor the default standalone/scriptpathassets/builtin-chatbot-template.csonly when the user explicitly requests a built-in bot
If the current workspace contains an MCC checkout, verify final names and signatures against local sources before editing. The skill should still work without those files. If there is no MCC checkout available, rely on the bundled reference and cookbook as the full source of truth for authoring patterns.
Choose the bot type first
- Default to a standalone script bot loaded with
/script. - Only choose a built-in bot when the user explicitly asks for a compiled MCC bot, repo wiring, automatic config loading, or changes under the built-in bot system.
- If the prompt is ambiguous, infer the likely target from commands, requested output files, or phrasing, state the assumption briefly, and proceed.
- If a user says only "make a bot", do not create a built-in bot.
Source priority
When the local MCC checkout is available, prefer these sources in this order:
MinecraftClient/Scripting/ChatBot.csand current files underMinecraftClient/ChatBots/- the bundled
references/authoring-reference.md - the bundled
references/pattern-cookbook.md - older
MinecraftClient/config/sample bots only for ideas, not as the default scaffold
If an older sample conflicts with the current built-in bots, follow the current built-in bots. If the local checkout is not available, do not block on missing repo files. Use the bundled references directly.
Hard rules
- Only use lifecycle hooks and helpers documented in the bundled reference or verified in the target codebase.
- Do not send chat from
Initialize(). UseAfterGameJoined()once the session can send messages. - Prefer the current Brigadier command-registration pattern for built-in bots. Do not introduce
ChatBotCommandunless the surrounding code already uses it. - For message parsing, normalize with
GetVerbatim(text)beforeIsChatMessage(...)orIsPrivateMessage(...). - Clean up everything you register or start: commands, plugin channels, threads, timers, and movement locks.
- If a built-in bot or long-running automation controls movement, follow a movement-lock pattern and release it on every stop path. Do not add
BotMovementLockto a simple standalone/scriptbot unless the prompt or surrounding code explicitly needs shared movement coordination. - For built-in bots, follow the host codebase's localization and config-comment conventions instead of scattering hardcoded user-facing text.
- For new code, prefer
Initialize()over constructors for prerequisite checks and unload decisions. - In this repo, built-in bot wiring usually means edits in
MinecraftClient/Settings.csandMinecraftClient/McClient.csin addition to the bot class. - For repair tasks, preserve the existing bot type and file layout unless the user explicitly asks for a conversion or restructure.
Standalone script bots
Use the exact MCC metadata format from the bundled reference. This is the default path for new work.
The script should usually:
- keep
Initialize()for cheap setup only - use
GetText(...),AfterGameJoined(), and other event hooks for live behavior - log with
LogToConsole(...) - send server chat or commands with
SendText(...) - use
PerformInternalCommand(...)only for MCC internal commands - add
//using MinecraftClient.Inventoryin metadata when the script uses inventory types explicitly - reuse the standalone snippets in
references/pattern-cookbook.mdbefore inventing new scaffolding - keep load instructions explicit, usually
/script FileName.cs
Built-in bots
Built-in bots usually need three pieces:
- the bot class itself
- config wiring in the chat-bot config model
- bot registration in the load flow
If the codebase exposes commands, follow the built-in command and unload pattern from the bundled reference. If it exposes new settings or status text, follow the codebase's localization and config-comment patterns.
When working in this checkout, built-in bot delivery usually needs:
- a new file under
MinecraftClient/ChatBots/ - a config property inside
Settings.ChatBotConfigHealper.ChatBotConfig - a
BotLoad(new YourBot())line insideMcClient.RegisterBots(...) - literal code snippets or patch hunks for the
Settings.csproperty and theMcClient.csregistration line, not only prose notes
Repair flow
When the user asks to fix or debug a bot:
- identify whether it is standalone or built-in and keep that shape unless told otherwise
- remove the broken pattern first, then preserve the intended behavior
- check especially for these regressions:
SendText(...)inInitialize(), raw formatted chat parsing, inventory snapshot mutation, missing command unregister, missing plugin-channel unregister, and unreleased movement locks - reuse the local repo's modern pattern instead of patching around a legacy helper when the helper is no longer current
Delivery checklist
Before finishing, verify:
- the class inherits
ChatBot - the chosen overrides exist in the MCC ChatBot API
- standalone script metadata is exact if this is a
/scriptbot - built-in bots are fully wired into config and registration if needed
- all command registrations, background work, and movement locks are released
- files and namespaces match the surrounding codebase
Output
When you implement or modify a bot:
- state whether it is a standalone script bot or built-in bot
- list the files you changed
- mention any required config keys or the MCC command used to load it
- when built-in wiring is involved, show the exact inserted code lines or patch hunks for
Settings.csandMcClient.cs - call out assumptions briefly if the user did not specify bot type or trigger behavior