RandallLiuXin/GodotMaker

Problem The art pipeline refactor is complete. Skills under skills/assets/ (tileset, ui-kit, character-bundle, background-map, fx-bundle, scene-prop-set, platform-strip, card-kit, compact-prop-pack, screen-reference) are standalone, reusable Godot skills that fill in Godot's non-AI-native areas. Developers who don't use the full GodotMaker automation should be able to install only these skills into their own Godot project. Today tools/publish.py only supports publishing the full skill set (core + reviewer + assets) via shell/publish.sh / shell/publish.ps1. There is no way to package and publish only the asset skills subset together with their runtime dependencies as a standalone unit. Proposed Solution Add a subset mode to the publish pipeline: Extend tools/publish.py with an option such as --subset assets (or add a dedicated entry script) that publishes only skills/assets/* plus the required runtime dependencies (shared asset runtime, provider references, codex_image_claim, and any n

Problem The standalone asset skills under skills/assets/ (tileset, ui-kit, character-bundle, background-map, fx-bundle, …) are currently verified only against Claude Code, Codex, OpenCode, and Pi. Trae is not covered, so Trae users cannot yet benefit from the Godot AI-native supplement skills. Proposed Solution Adapt and end-to-end test the asset skills on Trae: Research how Trae discovers and installs skills (config files, project conventions) and document the findings. Extend the publish/runtime layer (tools/agent_runtime.py, tools/publish.py, agent-runtimes/) so the asset skills can be published and run under Trae. Run a full end-to-end asset generation flow on Trae and confirm the produced asset imports cleanly into Godot. Acceptance Criteria Research findings on Trae's skill mechanism are reported in the issue/PR. At least one asset skill (e.g. tileset) is generated end-to-end under Trae and imports cleanly into a Godot project. The PR must include actual run screenshots of t

Problem The standalone asset skills under skills/assets/ (tileset, ui-kit, character-bundle, background-map, fx-bundle, …) are currently verified only against Claude Code, Codex, OpenCode, and Pi. WorkBuddy is not covered, so WorkBuddy users cannot yet benefit from the Godot AI-native supplement skills. Proposed Solution Adapt and end-to-end test the asset skills on WorkBuddy: Research how WorkBuddy discovers and installs skills (config files, project conventions) and document the findings. Extend the publish/runtime layer (tools/agent_runtime.py, tools/publish.py, agent-runtimes/) so the asset skills can be published and run under WorkBuddy. Run a full end-to-end asset generation flow on WorkBuddy and confirm the produced asset imports cleanly into Godot. Acceptance Criteria Research findings on WorkBuddy's skill mechanism are reported in the issue/PR. At least one asset skill (e.g. tileset) is generated end-to-end under WorkBuddy and imports cleanly into a Godot project. The PR

Problem Roadmap item R-057 tracks support for Beehave, a behavior-tree AI addon for Godot. Generated games often need enemy AI, NPC routines, or boss behaviors. GodotMaker does not yet have plugin-specific guidance for when a behavior tree is a better fit than simple scripted logic. Proposed Solution Add a Beehave plugin skill focused on practical behavior-tree usage in generated projects. Suggested scope: Add a new plugin skill or supporting skill entry for Beehave. Document common use cases: enemy patrol/chase/attack, NPC routines, boss phases, and simple decision trees. Include minimal Godot 4 examples and agent-facing decision guidance. Clarify when plain script logic or a simple state machine is enough. Update docs so contributors/users can discover the plugin skill. Acceptance Criteria The new skill has a clear SKILL.md and any needed reference files. The guidance includes examples, non-goals, and decision criteria. The skill stays independent from unrelated plugin integration

Problem Roadmap item R-056 tracks support for GodotSteam, a Steam platform integration for Godot. This integration is valuable, but it is heavier than most plugin skills because it may involve SDK setup, platform-specific configuration, exports, and account/runtime requirements. The first step should define a safe plugin-skill scope rather than promising full Steam publishing support immediately. Proposed Solution Add a focused GodotSteam plugin skill spike that documents a minimal, agent-usable integration path. Suggested scope: Add or draft a plugin skill for GodotSteam. Document supported use cases that are reasonable for generated projects, such as achievements or basic Steam API checks. Clearly document setup assumptions and environment requirements. Mark unsupported or out-of-scope areas, such as store publishing automation or account-specific configuration. Update docs so contributors/users can discover the plugin skill status. Acceptance Criteria The skill or spike document