m4bwav/minewright

Check a Minecraft Bedrock add-on without the game before saying a change is done: one script (mw_check.py) checks that every pack JSON parses (comments allowed), the manifests (format_version 2, unique UUIDs, versions, dependencies, script entry, beta modules flagged), identifiers (one namespace, client entities, textures, geometry, render controllers exist), entity components valid for their format_version, then tsc, ESLint, npm test and optional Creator Tools validation, in one JSON report. Use whenever the user asks to 'check my add-on', 'validate the behavior pack', 'why is my entity invisible', 'missing texture', 'does my manifest look right', 'lint the Minecraft scripts', 'run the tests', 'checks were skipped, is it verified', after the agent edits pack JSON or Script API code, or says 'refresh minewright-checks'. Running the add-on on a real server is minewright-server; project setup and packaging are minewright-project.

Put information on a Minecraft Bedrock player's screen from an add-on: titles, subtitles and the actionbar from the Script API (the stable, always-working layer), HUD element visibility, and resource-pack JSON UI on top (hud_screen.json, the Preserve Title Texts pattern, title-prefix markers, anim_type offset and alpha animations for a popup that slides into a timer, string-to-number conversion, vanilla item textures by path) with the risks: Ore UI is replacing JSON UI, custom glyphs are unofficial, no item-render-by-id, server-ui forms are dialogs, not a HUD. Always ships a plain title and actionbar fallback. Use whenever the user asks for 'a timer on screen', 'show the item in the middle of the screen', 'custom HUD', 'JSON UI', 'hud_screen.json', 'animate the title', 'a menu or form', 'hide the hotbar', or says 'refresh minewright-hud'. Game rules are minewright-workflow; pack layout is minewright-project.

Set up and package a Minecraft Bedrock add-on project: behavior pack and resource pack folders, manifest.json format_version 2 with fresh UUIDs, min_engine_version, script module dependencies on @minecraft/server and @minecraft/server-ui by version string, a TypeScript build with esbuild or core-build-tasks, .mcaddon packaging, and install on Windows (GDK com.mojang folder, import-while-running bug), mobile, and consoles through a Realm. Use whenever the user asks to 'start a Bedrock add-on', 'make a behavior pack', 'set up TypeScript for Minecraft scripts', 'what version of @minecraft/server', 'build the mcaddon', 'how do I install this add-on', 'where is com.mojang', 'my add-on won't import', 'get it on Xbox or Switch', or 'refresh minewright-project'. Design and Script API code are minewright-workflow; checks are minewright-checks; live server tests are minewright-server. Bedrock only, not Java (Paper, Spigot, Fabric).

Test a Minecraft Bedrock add-on (not Java Edition: no Spigot or Paper) live on Bedrock Dedicated Server (BDS): one script (bds_run.py) caches BDS (--download only once the user accepts the Minecraft EULA), builds a throwaway world with the packs active, starts the server, sends console commands such as /scriptevent ns:selftest, reads [MWTEST] PASS/FAIL markers and script errors, stops the server and prints one JSON report. Also: why not GameTest (Beta APIs), server.properties, the module allowlist, the script debugger, joining a local BDS from Windows (loopback exemption). Use whenever the user asks to 'test my add-on on a server', 'run the self-test', 'does it actually load', 'set up a Bedrock dedicated server', 'run GameTest', 'my scripts don't run on the server', 'connect to my local server', or says 'refresh minewright-server'. Static checks are minewright-checks; writing the self-test is minewright-workflow.

Designing and writing Minecraft Bedrock add-ons: a one-pager and one config file before code (every duration in one place, a test mode), APIs looked up on Microsoft Learn and npm, not recalled, stable modules only (Beta APIs make a world experimental for good), patterns that hold up (one runInterval loop, state in world dynamic properties, entity properties for rendering, the unloaded-chunk trap, inventory diffs to find who dropped an item), fair rules for young players, a playtest checklist. Use whenever the agent plans, writes or reviews Bedrock add-on code, or on 'make a Minecraft add-on', 'design my Bedrock mod', 'add a custom mob that...', 'write the script for my add-on', 'is this API real or current', 'what should we playtest', or 'refresh minewright-workflow'. Pack layout, builds and .mcaddon are minewright-project; static checks are minewright-checks; running it on a server is minewright-server; HUD and UI are minewright-hud.