agentleFS
vl4dtvl4dt/godot-skills/skills/godot-code-review/SKILL.md

godot-code-review

Skill8 starsChanged 5 months agoMITView on GitHub

Reviews Godot projects for common pitfalls, performance issues, memory leaks, and anti-patterns. Provides a performance checklist, code style guidelines, and memory management review. Use when reviewing Godot GDScript or C# code.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 8 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use 4-space indentation (not tabs)

    line 107
  2. Distinctive:

    Follow GDScript Style Guide

    line 108
  3. Very specific:

    Use @export for inspector-exposed variables

    line 109
  4. Very specific:

    Use @onready for node paths

    line 110
  5. Very specific:

    Use const for compile-time constants

    line 112
  6. Distinctive:

    Use PascalCase for class names, camelCase for members

    line 116
  7. Very specific:

    Use Godot's [Export] attributes for inspector properties

    line 117
  8. Distinctive:

    Prefer structs for small value types to avoid GC pressure

    line 119
  9. Distinctive:

    Check for HDR rendering configuration in project settings

    line 144
  10. Distinctive:

    Verify VirtualJoystick is used instead of custom implementations on mobile

    line 146
  11. Distinctive:

    Check that tween_await() replaces nested callback patterns where applicable

    line 147
  12. Distinctive:

    When the MCP bridge is running (Phase 2), these tools enhance code review:

    line 167

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Godot Code Review

Systematic review patterns for Godot game development projects.

Common Pitfalls & Anti-Patterns

_process() Abuse

# BAD: Using _process for everything
func _process(delta):
    # Movement that could be in _physics_process
    position += velocity * delta
    # Animation updates
    update_animation()

# GOOD: Use the right callback
func _physics_process(delta):
    # Physics-related movement
    position += velocity * delta

func _process(delta):
    # Non-physics updates (UI, animations)
    update_animation()

Hardcoded Paths

# BAD
var sprite = get_node("Character/Sprite2D")

# GOOD
@onready var sprite = $Sprite2D as Sprite2D

Signal Leaks

# BAD: Forgetting to disconnect signals
func _ready():
    EventBus.some_signal.connect(on_some_signal)
    # If this node is freed, the callback still holds a reference

# GOOD: Auto-disconnect when using method references
func _ready():
    EventBus.some_signal.connect(on_some_signal)  # Godot auto-handles method refs

# GOOD: Manual disconnect for lambdas
func _ready():
    var callback = func(): handle_event()
    EventBus.some_signal.connect(callback)

func _exit_tree():
    EventBus.some_signal.disconnect(callback)

Performance Review Checklist

Callback Selection

Use CaseCorrect CallbackWhy
Physics movement_physics_processFixed timestep, syncs with physics server
Non-physics updates_processFrame-rate dependent, for UI/rendering
One-time setup_readyCalled once when node enters tree
Frame before ready_enter_treeCalled before _ready, even if tree paused
Cleanup_exit_treeCalled when node is removed from tree
Physics tick (input)_physics_input_eventFor character body input handling

Memory Management

  • All queue_free() calls have corresponding signal disconnections
  • No circular references between nodes
  • Large resources (textures, audio) unloaded when no longer needed
  • Scene instances properly freed after use
  • Autoload nodes don't hold unnecessary references

Code Style Guidelines

GDScript Style

  • Use 4-space indentation (not tabs)
  • Follow GDScript Style Guide
  • Use @export for inspector-exposed variables
  • Use @onready for node paths
  • Type annotations on function parameters and return values
  • Use const for compile-time constants

C# Style

  • Use PascalCase for class names, camelCase for members
  • Use Godot's [Export] attributes for inspector properties
  • Implement _ExitTree() for cleanup of event subscriptions
  • Prefer structs for small value types to avoid GC pressure

Memory Management Patterns

# Proper node lifecycle
func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    add_child(enemy)
    # Enemy manages its own cleanup via queue_free() on death

func load_level(level_path: String):
    # Unload previous level
    if current_level:
        current_level.queue_free()
        current_level = null

    # Load new level
    var scene = load(level_path)
    current_level = scene.instantiate()
    add_child(current_level)

Godot 4.7 Code Review Notes

  • Check for HDR rendering configuration in project settings
  • Review AreaLight3D usage for new 4.7 features (modes, intensity profiles)
  • Verify VirtualJoystick is used instead of custom implementations on mobile
  • Check that tween_await() replaces nested callback patterns where applicable

Quick Review Commands

# Find all _process calls that might be physics-related
grep -rn "_process" --include="*.gd" scripts/

# Find hardcoded get_node calls (should use @onready)
grep -rn "get_node(" --include="*.gd" scripts/

# Find potential signal leaks (connect without disconnect pattern)
grep -rn "\.connect(" --include="*.gd" scripts/

# Find queue_free usage to verify cleanup
grep -rn "queue_free" --include="*.gd" scripts/

MCP Bridge Tools (Optional — Live Editor Integration)

When the MCP bridge is running (Phase 2), these tools enhance code review:

  • script_read — Read any script file for review without opening the editor
  • script_validate — Run syntax validation with checkDeprecated: true and suggestTweenAwait: true
  • file_search — Search across all project files for patterns (e.g., queue_free, signal leaks)
  • file_browse — List project directories to verify structure
  • class_db_info — Verify methods/properties exist before flagging issues

Note: MCP tools require the Godot editor to be running with the MCP plugin enabled. Skills work independently without the bridge.

References

  • GDScript Style Guide
  • Performance Optimization Guide
  • Memory Management Patterns

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.