godot-code-review
Skill870 starsChanged 21 days agoMITView on GitHub
Use when reviewing GDScript or C# Godot code — checklist of best practices, common anti-patterns, and Godot-specific pitfalls. Triggers on "review this script", "check my code", "any issues with this", "what's wrong with this code", including a short pasted snippet.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- vl4dt/godot-skillstheir own version, first seen Jun 21, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- vl4dt/godot-skills★ 8same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository62 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- authoring-godot-prompter-skillsSkill
- releasing-godot-prompterSkill
- 2d-essentialsSkill
- 3d-essentialsSkill
- ability-systemSkill
- addon-developmentSkill
- ai-navigationSkill
- animation-systemSkill
- assets-pipelineSkill
- audio-systemSkill
- beehaveSkill
- camera-systemSkill
- component-systemSkill
- csharp-godotSkill
- csharp-signalsSkill
- dedicated-serverSkill
- dependency-injectionSkill
- dialogue-managerSkill
- dialogue-systemSkill
- event-busSkill
- export-pipelineSkill
- gdextensionSkill
- gdscript-advancedSkill
- gdscript-patternsSkill
- godot-brainstormingSkill
- godot-debuggingSkill
- godot-grillSkill
- godot-mentorSkill
- godot-optimizationSkill
- godot-project-setupSkill
- godot-testingSkill
- godot-uiSkill
- hud-systemSkill
- input-handlingSkill
- inventory-systemSkill
- limboaiSkill
- localizationSkill
- math-essentialsSkill
- mobile-developmentSkill
- multiplayer-basicsSkill
- multiplayer-syncSkill
- multithreadingSkill
- particles-vfxSkill
- phantom-cameraSkill
- physics-systemSkill
- player-controllerSkill
- popochiuSkill
- procedural-generationSkill
- rendering-pipelineSkill
- resource-patternSkill
- responsive-uiSkill
- save-loadSkill
- scene-organizationSkill
- shader-basicsSkill
- state-machineSkill
- tween-animationSkill
- using-godot-prompterSkill
- web-exportSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 456
Use this template when delivering a review:
≈ “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.
Files
Godot Code Review
A structured review guide for Godot 4.3+ projects covering GDScript and C#. Work through each checklist section, then produce a review summary using the output template at the end.
Related skills: godot-testing for TDD and test coverage, scene-organization for scene tree best practices, godot-optimization for performance review.
1. Node & Scene Architecture
- Each scene has a single, clear responsibility (player, enemy, UI widget, etc.)
- Inheritance chains are shallow — prefer composition via child nodes over deep
extendshierarchies - Autoloads (singletons) are used sparingly; only truly global state belongs there
- Node references traverse only to direct children — no
get_parent()chains @onready(GDScript) orGetNode<T>()(C#) targets direct children or named paths within the same scene
Anti-pattern — get_parent() chain
# BAD: tight coupling, breaks if the tree changes
func take_damage(amount: int) -> void:
get_parent().get_parent().get_node("HUD").update_health(health)// BAD: tight coupling, breaks if the tree changes
public void TakeDamage(int amount)
{
GetParent().GetParent().GetNode("HUD").Call("UpdateHealth", _health);
}Fix — emit a signal instead
# GOOD: parent/ancestor listens; child stays decoupled
signal health_changed(new_health: int)
func take_damage(amount: int) -> void:
health -= amount
health_changed.emit(health)// GOOD: parent/ancestor listens; child stays decoupled
[Signal]
public delegate void HealthChangedEventHandler(int newHealth);
public void TakeDamage(int amount)
{
_health -= amount;
EmitSignal(SignalName.HealthChanged, _health);
}2. GDScript Style
- Variables and functions use
snake_case - Class names declared with
class_nameusePascalCase - Constants use
SCREAMING_SNAKE_CASE - All function parameters and return types carry type hints
@exportvariables include an explicit type- Signal declarations appear at the top of the file, before variables
Bad — untyped
var speed = 200
var health = 100
func move(direction):
position += direction * speed
func heal(amount):
health += amount
return health// BAD: no explicit types, weak contracts
float speed = 200;
int health = 100;
public void Move(object direction)
{
Position += (Vector2)direction * speed;
}
public object Heal(object amount)
{
health += (int)amount;
return health;
}Good — typed
class_name PlayerController
extends CharacterBody2D
signal health_changed(new_health: int)
signal player_died()
const MAX_HEALTH: int = 100
const BASE_SPEED: float = 200.0
@export var speed: float = BASE_SPEED
@export var max_health: int = MAX_HEALTH
var health: int = max_health
func move(direction: Vector2) -> void:
velocity = direction * speed
move_and_slide()
func heal(amount: int) -> int:
health = mini(health + amount, max_health)
health_changed.emit(health)
return health// GOOD: strongly typed, proper C# conventions
public partial class PlayerController : CharacterBody2D
{
[Signal]
public delegate void HealthChangedEventHandler(int newHealth);
[Signal]
public delegate void PlayerDiedEventHandler();
private const int MaxHealth = 100;
private const float BaseSpeed = 200f;
[Export] public float Speed { get; set; } = BaseSpeed;
[Export] public int MaxHp { get; set; } = MaxHealth;
private int _health;
public override void _Ready()
{
_health = MaxHp;
}
public void Move(Vector2 direction)
{
Velocity = direction * Speed;
MoveAndSlide();
}
public int Heal(int amount)
{
_health = Mathf.Min(_health + amount, MaxHp);
EmitSignal(SignalName.HealthChanged, _health);
return _health;
}
}3. C# Style
- Node scripts use
partial classto allow Godot source generators to work - Methods and properties use
PascalCase; local variables usecamelCase [Export]properties usePascalCase[Signal]delegates follow the<EventName>EventHandlernaming patternGetNode<T>()results are null-checked or cached in_Ready()and validated
// GOOD
public partial class PlayerController : CharacterBody2D
{
[Signal]
public delegate void HealthChangedEventHandler(int newHealth);
[Export] public float Speed { get; set; } = 200f;
[Export] public int MaxHealth { get; set; } = 100;
private int _health;
private AnimationPlayer _animationPlayer = null!;
public override void _Ready()
{
_animationPlayer = GetNode<AnimationPlayer>("AnimationPlayer");
// Validate at startup rather than silently failing later
if (_animationPlayer is null)
GD.PushError("AnimationPlayer node not found on PlayerController");
_health = MaxHealth;
}
public void TakeDamage(int amount)
{
_health = Mathf.Max(_health - amount, 0);
EmitSignal(SignalName.HealthChanged, _health);
}
}4. Performance
get_node()/$NodePathis never called inside_process()or_physics_process()— always cache with@onreadyload()is not called in hot paths — usepreload()for compile-time loading or cache the result_process()is disabled (set_process(false)) when the node does not need per-frame updatesStringName(or&"string"literal) is used for comparisons inside_process()or tight loops
Anti-pattern — uncached node lookup in _process()
# BAD: get_node() traverses the tree every frame
func _process(delta: float) -> void:
get_node("HUD/HealthBar").value = health
get_node("HUD/Label").text = str(health)// BAD: GetNode() traverses the tree every frame
public override void _Process(double delta)
{
GetNode<ProgressBar>("HUD/HealthBar").Value = _health;
GetNode<Label>("HUD/Label").Text = _health.ToString();
}Fix — cache with @onready
# GOOD: resolved once at scene load
@onready var _health_bar: ProgressBar = $HUD/HealthBar
@onready var _health_label: Label = $HUD/Label
func _process(delta: float) -> void:
_health_bar.value = health
_health_label.text = str(health)// GOOD: resolved once in _Ready()
private ProgressBar _healthBar = null!;
private Label _healthLabel = null!;
public override void _Ready()
{
_healthBar = GetNode<ProgressBar>("HUD/HealthBar");
_healthLabel = GetNode<Label>("HUD/Label");
}
public override void _Process(double delta)
{
_healthBar.Value = _health;
_healthLabel.Text = _health.ToString();
}StringName in hot paths
# BAD: a String compared to a StringName is compared character by character
if animation_name == "run":
pass
# GOOD: StringName literal — a pointer comparison
if animation_name == &"run":
pass// BAD: allocates a new StringName each frame
if (animationName == "run") { }
// GOOD: cache StringName as a static field
private static readonly StringName RunAnim = new("run");
public override void _Process(double delta)
{
if (animationName == RunAnim) { }
}5. Input Handling
- All actions use Input Map names (Project > Project Settings > Input Map), not hardcoded key constants
_unhandled_input()is preferred over_input()to allow UI controls to consume events first- Continuous movement is driven by
Input.get_vector()/Input.is_action_pressed()inside_physics_process() - Discrete one-shot actions (jump, shoot) are handled in
_unhandled_input()
# Continuous movement — physics process
func _physics_process(delta: float) -> void:
var direction: Vector2 = Input.get_vector(
&"ui_left", &"ui_right", &"ui_up", &"ui_down"
)
velocity = direction * speed
move_and_slide()
# Discrete action — unhandled input
func _unhandled_input(event: InputEvent) -> void:
if event.is_action_pressed(&"jump"):
_jump()// Continuous movement — physics process
public override void _PhysicsProcess(double delta)
{
Vector2 direction = Input.GetVector(
"ui_left", "ui_right", "ui_up", "ui_down"
);
Velocity = direction * Speed;
MoveAndSlide();
}
// Discrete action — unhandled input
public override void _UnhandledInput(InputEvent @event)
{
if (@event.IsActionPressed("jump"))
{
Jump();
}
}6. Signals & Communication
- Signals travel up the tree (child emits, parent/ancestor connects); method calls go down (parent calls child method)
- Connections are established in
_ready()or wired in the editor — not in_process()or one-off callbacks - There are no circular signal dependencies between nodes
- Signal names use past tense to describe what happened
# Good signal names
signal health_changed(new_health: int) # past tense
signal enemy_died() # past tense
signal item_collected(item: ItemData) # past tense
# Bad signal names (present/imperative tense)
# signal update_health(value: int)
# signal die()
# signal collect_item(item: ItemData)// Good signal names — past tense, EventHandler suffix
[Signal]
public delegate void HealthChangedEventHandler(int newHealth);
[Signal]
public delegate void EnemyDiedEventHandler();
[Signal]
public delegate void ItemCollectedEventHandler(ItemData item);
// Bad signal names (present/imperative tense)
// public delegate void UpdateHealthEventHandler(int value);
// public delegate void DieEventHandler();
// public delegate void CollectItemEventHandler(ItemData item);# Parent connects to child signal in _ready()
func _ready() -> void:
$Enemy.enemy_died.connect(_on_enemy_died)
$Player.health_changed.connect(_on_player_health_changed)// Parent connects to child signal in _Ready()
public override void _Ready()
{
GetNode<Enemy>("Enemy").EnemyDied += OnEnemyDied;
GetNode<Player>("Player").HealthChanged += OnPlayerHealthChanged;
}7. Resource Management
preload()is used for resources known at edit time (scenes, textures, audio);load()is used for paths resolved at runtime- Large or level-specific resources loaded at runtime use
ResourceLoader.load_threaded_request()to avoid frame stalls - Dynamically instantiated nodes are freed with
queue_free(), notfree(), to avoid use-after-free crashes
# Compile-time — path is validated by the editor
const BULLET_SCENE: PackedScene = preload("res://scenes/bullet.tscn")
# Runtime — path comes from data
func _load_level(path: String) -> void:
ResourceLoader.load_threaded_request(path)
func _check_load(path: String) -> void:
if ResourceLoader.load_threaded_get_status(path) == ResourceLoader.THREAD_LOAD_LOADED:
var scene: PackedScene = ResourceLoader.load_threaded_get(path)
get_tree().change_scene_to_packed(scene)
# Cleanup
func _on_enemy_died() -> void:
queue_free() # safe — deferred until end of frame// Compile-time equivalent — load once in a static field or _Ready()
private static readonly PackedScene BulletScene =
GD.Load<PackedScene>("res://scenes/bullet.tscn");
// Runtime — path comes from data
private void LoadLevel(string path)
{
ResourceLoader.LoadThreadedRequest(path);
}
private void CheckLoad(string path)
{
if (ResourceLoader.LoadThreadedGetStatus(path) == ResourceLoader.ThreadLoadStatus.Loaded)
{
var scene = ResourceLoader.LoadThreadedGet(path) as PackedScene;
GetTree().ChangeSceneToPacked(scene);
}
}
// Cleanup
private void OnEnemyDied()
{
QueueFree(); // safe — deferred until end of frame
}8. Error-Prone Patterns
| Pattern | Problem | Fix |
await get_tree().create_timer(t).timeout after queue_free() (GDScript) | The freed node's coroutine is dropped silently: no error, and nothing after the await runs, so is_instance_valid(self) there never fires | Do must-run work before queue_free(); re-check other nodes with is_instance_valid() after await; use create_tween() for effects that should die with the node |
Fragile node paths like $A/B/C/D/E | Fails at runtime (Node not found) when the scene tree is reorganized | Refactor to direct children + signals, or export a NodePath |
call_deferred() used everywhere | Defers are appropriate for cross-frame safety, not a general solution; overuse hides real design issues | Only defer when crossing physics/main thread boundaries or breaking a call cycle |
set_physics_process(true) called inside _physics_process() | Redundant call every frame; wastes CPU | Call once at the point you actually want to enable/disable processing |
Directly setting position on a CharacterBody2D | Bypasses collision; teleports the body and can cause tunnelling | Use move_and_slide() with velocity; only set position/global_position for intentional teleports |
9. Review Output Format
Use this template when delivering a review:
## Code Review — <FileName or Feature>
### Critical
Issues that will cause bugs, crashes, or significant performance problems.
- [ ] <node/line> — <issue> — **Suggested fix:** <fix>
### Improvements
Code quality, style, or maintainability concerns that should be addressed.
- [ ] <node/line> — <issue> — **Suggested fix:** <fix>
### Positive
What the code does well — reinforce good patterns.
- <observation>
---
Reviewed against: Godot 4.3+ best practicesExample
## Code Review — PlayerController.gd
### Critical
- [ ] _process() line 42 — `get_node("HUD/HealthBar")` called every frame — **Suggested fix:** Cache with `@onready var _health_bar: ProgressBar = $HUD/HealthBar`
- [ ] take_damage() line 67 — no type hints on parameter or return — **Suggested fix:** `func take_damage(amount: int) -> void:`
### Improvements
- [ ] Line 12 — signal `updateHealth` should be past tense — **Suggested fix:** Rename to `health_changed`
- [ ] Line 8 — `var speed = 200` missing type hint — **Suggested fix:** `var speed: float = 200.0`
### Positive
- Signals are declared at the top of the file
- Constants correctly use SCREAMING_SNAKE_CASE
- `queue_free()` used correctly for cleanup
---
Reviewed against: Godot 4.3+ best practicesDoes 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
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.

