Share ideas for new features

[jame581]

What features would you like to see in GodotPrompter?

Got an idea for a new skill category, a missing Godot 4 topic, or a workflow improvement? Share it here!
A few prompts to get you thinking:

• Are there Godot systems where AI still gives you bad/outdated code?
• Any skill categories you wish existed (networking, shaders, audio, etc.)?
• Workflow or tooling improvements for Claude Code / Cursor / Copilot integration?

All ideas welcome no matter if big or small.

[jame581]

Idea 1: GDExtension / Native Extensions

One area I haven't covered yet is GDExtension. Writing native extensions in C++, Rust, or Swift that plug into Godot 4. It's a niche topic but when you need it, AI output tends to be completely wrong (mostly hallucinated GDNative from Godot 3). Would a gdextension skill be useful to anyone here?

[jame581]

GDExtension skill was added in v1.9.0.

[jame581]

Idea 2: Mobile-specific skill

There's responsive-ui for multi-resolution, but mobile platforms have their own set of pain points like touch input beyond basics, accelerometer, in-app purchases, Android/iOS permissions, battery/performance constraints. Worth a dedicated mobile-development skill, or should this fold into existing skills?

[jame581]

Mobile-specific skill was added in v1.9.0.

[wavebit]

1. Third-party AI library support. It would be awesome to add dedicated skills and best practices for popular third-party AI plugins like LimboAI or Beehave.
2. Antigravity IDE support.
3. Separate C# and GDScript code. Having both in the same skill file consumes too much context window and can cause the AI to lose focus.

[jame581]

1 Third-party AI library support

Thanks for raising this. It's a great idea and something I've been thinking about too (I'm using Limbo AI in my projects). The ai-navigation skill already covers Godot's built-in NavigationAgent2D/3D and has a lightweight custom behavior tree concept (the references/behavior-trees.md sub-file). But there's nothing LimboAI- or Beehave-specific, and those plugins are popular enough to deserve proper coverage.

My hesitation with dedicated standalone skills is maintenance: both plugins update independently, and if their APIs change between GodotPrompter releases, the skill becomes a source of exactly the kind of hallucinated/outdated code the project is trying to prevent. I'd rather get this right than ship it fast.

The approach I'm leaning toward: add references/limboai.md and references/beehave.md as sub-files under ai-navigation, covering setup, the key node types, and a canonical usage pattern. The core skill stays stable; the references get updated when the plugins do.

Would you be interested in contributing one? If you use either plugin regularly, you'd have much better hands-on knowledge of the sharp edges than I do. Happy to review a PR.

[jame581]

2 Antigravity IDE support

Thanks for the suggestion! I'm not familiar with Antigravity IDE. I primarily use Claude Code and Cowork, and I'm using GitHub Copilot and the new Copilot App (in the preview). Both these tools are working. The repo currently supports Claude Code, Cursor, GitHub Copilot, Gemini CLI, OpenCode, and Codex. Adding a new platform is definitely on the table if there's a clear integration path.

I can take a look and get a bit more context about Antigravity IDE. Once I know what format it expects (agent folder structure, instruction file conventions, etc.), I can evaluate whether it fits the current platform model.

[jame581]

3 Separate C# and GDScript code

This is an intentional design decision, so I want to explain the reasoning rather than just close the issue.
GodotPrompter keeps GDScript and C# together in the same skill file. GDScript block first, C# immediately after in the same section. The entire v1.5.0–v1.8.0 work was built around this: a full C# parity initiative that closed 33 deferred sections across 13 skills so every GDScript example has a matching C# counterpart in the same place.

The context window concern is real, but it's solved differently here. Skills have a 16 KB budget enforced by the validator, and anything over that gets restructured using Pattern X: a lean core SKILL.md plus references/<topic>.md sub-files that agents load on demand. Splitting by language would mean maintaining two copies of every skill with no mechanism to keep them in sync and the parity debt would come back immediately.

If you're hitting context issues with a specific skill, the right fix is to flag it for a Pattern X restructure. Happy to take a look if you have one in mind.

[jame581]

4 Gameplay Ability System

Love that idea. It's a genuine gap in the catalog.
Right now resource-pattern covers ability definitions as Resource subclasses, and component-system has stat components, but there's nothing that ties abilities + cooldowns + buff stacks + stat modifiers into a coherent architecture. That's exactly the kind of thing that causes AI agents to improvise wildly, which is the whole problem GodotPrompter exists to solve.

I'm adding this to the backlog for a future release. The skill would sit in the Architecture category alongside state-machine and component-system, and would cover things like: ability data vs ability execution separation, cooldown tracking, buff/debuff stacking with duration and priority, stat modifier chains, and how to wire it all together without creating a spaghetti mess.

If anyone wants to draft a skill outline or prototype the content, I'd happily review it, because this one would benefit from real-world usage experience with ability-heavy games.

[jame581]

5 Game Feel / Combat Juice

Really good call. This is one of the most-searched Godot topics and the coverage in GodotPrompter is currently scattered across four different skills with no single place to look. Screen shake lives in camera-system, hit flash shows up informally in trial project scripts, tween easing is in tween-animation, knockback touches player-controller. None of that is wrong, but an agent asked to "add game feel" has no clean skill to load.

A dedicated game-feel skill would pull these into one place as a coherent system: Engine.time_scale for slow-mo and hitstop, trauma-based camera shake, hit flash via shader or modulate, knockback curves with Tween, and combo feedback patterns. The source skills would stay intact, this would just be the unified entry point.

Adding this to the backlog alongside the GAS idea. If you want to take a shot at an outline, I'd welcome it.