New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Scene Organization

by jame581 in jame581/GodotPrompter

A skill your agent uses when designing scene tree structure — composition vs inheritance, when to split scenes, node hierarchy patterns

MITAuto-check passedGame Development

Install Scene Organization

skills CLI
$ npx skills add jame581/GodotPrompter --skill scene-organization -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install jame581/GodotPrompter scene-organization --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/jame581/GodotPrompter.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/scene-organization .claude/skills/scene-organization && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
scene-organization
GitHub stars
805
Token cost
~2.5k tokens
SKILL.md length
676 words
Files
1
Skills in repo
58
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when designing scene tree structure — composition vs inheritance, when to split scenes, node hierarchy patterns

  • Works in 6 steps: Core Principle → Composition Over Inheritance → Scene Splitting Rules → …
  • Designing scene tree structure — composition vs inheritance
  • SKILL.md covers 1. Core Principle, 2. Composition Over Inheritance, 3. Scene Splitting Rules and 4. Node Communication Patterns, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Scene Organization is an agent skill from jame581/GodotPrompter. Use when designing scene tree structure — composition vs inheritance, when to split scenes, node hierarchy patterns

Its SKILL.md is about 2.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Game Development, covering Game development. It works with Godot. The repository describes itself as: Agentic skills framework for Godot 4.x. Domain-specific skills for AI coding agents (Claude Code, Copilot, Antigravity, Cursor). The licence is MIT.

When your agent uses it

  • Designing scene tree structure — composition vs inheritance
  • To split scenes
  • Node hierarchy patterns

Example prompts

  • “/scene-organization”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Core Principle
  2. Composition Over Inheritance
  3. Scene Splitting Rules
  4. Node Communication Patterns
  5. Scene Tree Patterns
  6. Checklist

What it can do on your machine

Read from SKILL.md and the folder at commit 1e7d79d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are gdscript and csharp).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Scene Organization loads about 2.5k tokens when it runs. Until then it costs about 34 tokens; SKILL.md has 676 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~34
When it runs · the whole SKILL.md, loaded when a task matches
~2.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from jame581/GodotPrompter at commit 1e7d79d, republished under its MIT licence (© jame581). 676 words, ~2,533 tokens.

Download SKILL.mdSave it as .claude/skills/scene-organization/SKILL.md (or your agent's skills folder).
name
scene-organization
description
Use when designing scene tree structure — composition vs inheritance, when to split scenes, node hierarchy patterns

Scene Organization

A guide for structuring Godot 4.3+ scene trees: when to split, when to compose, and how nodes should communicate.

Related skills: component-system for composition patterns, event-bus for decoupled communication, godot-brainstorming for scene tree planning, 2d-essentials for TileMapLayer and CanvasLayer organization.

1. Core Principle

Scenes are building blocks. Each scene encapsulates exactly one concept — a player, an enemy, a health bar, a weapon. A scene should be understandable in isolation, reusable without modification, and replaceable without breaking its neighbors.

One scene = one responsibility. If you struggle to name a scene in two words or fewer, it is probably doing too much.

2. Composition Over Inheritance

Player Scene — Composed from Reusable Parts
Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
├── HealthComponent
├── HitboxComponent
├── StateMachine
└── AnimationPlayer

HealthComponent, HitboxComponent, and StateMachine are separate .tscn files instantiated as child scenes. Any entity that needs health — enemy, destructible crate, boss — can include HealthComponent without duplicating logic.

HealthComponent — Full Example

GDScript

gdscript
# health_component.gd
class_name HealthComponent
extends Node

signal health_changed(old_value: int, new_value: int)
signal died

@export var max_health: int = 100

var current_health: int

func _ready() -> void:
    current_health = max_health

func take_damage(amount: int) -> void:
    if amount <= 0:
        return
    var old_health := current_health
    current_health = max(0, current_health - amount)
    health_changed.emit(old_health, current_health)
    if current_health == 0:
        died.emit()

func heal(amount: int) -> void:
    if amount <= 0:
        return
    var old_health := current_health
    current_health = min(max_health, current_health + amount)
    health_changed.emit(old_health, current_health)

func is_alive() -> bool:
    return current_health > 0

C#

csharp
// HealthComponent.cs
using Godot;

[GlobalClass]
public partial class HealthComponent : Node
{
    [Signal]
    public delegate void HealthChangedEventHandler(int oldValue, int newValue);

    [Signal]
    public delegate void DiedEventHandler();

    [Export]
    public int MaxHealth { get; set; } = 100;

    public int CurrentHealth { get; private set; }

    public override void _Ready()
    {
        CurrentHealth = MaxHealth;
    }

    public void TakeDamage(int amount)
    {
        if (amount <= 0)
            return;
        int oldHealth = CurrentHealth;
        CurrentHealth = Mathf.Max(0, CurrentHealth - amount);
        EmitSignal(SignalName.HealthChanged, oldHealth, CurrentHealth);
        if (CurrentHealth == 0)
            EmitSignal(SignalName.Died);
    }

    public void Heal(int amount)
    {
        if (amount <= 0)
            return;
        int oldHealth = CurrentHealth;
        CurrentHealth = Mathf.Min(MaxHealth, CurrentHealth + amount);
        EmitSignal(SignalName.HealthChanged, oldHealth, CurrentHealth);
    }

    public bool IsAlive() => CurrentHealth > 0;
}
When to Use Inheritance Instead

Inheritance suits cases where scenes share structure, not just behavior — when child scenes are variations of the same thing with identical node layout and only a few exported properties differ.

Good candidates:

  • Enemy → Orc, Goblin — same bones (Sprite2D, CollisionShape2D, HealthComponent, AI), different stats and art
  • Weapon → Sword, Bow — same slot attachment logic, different animations and damage type
  • Pickup → HealthPickup, AmmoPickup — same Area2D + CollisionShape2D + animation, different effect on collection
Rule of Thumb
ScenarioPattern
You would copy-paste the entire scene and change a few exported propertiesInheritance
You want to mix and match a subset of nodes across different entity typesComposition

3. Scene Splitting Rules

Split a scene when:
  • Reuse — the sub-scene is needed in more than one parent scene
  • Complexity — the scene exceeds roughly 15 nodes; it is carrying more than one concern
  • Independence — the sub-scene can be tested, previewed, or modified without opening its parent
  • Team — separate scenes reduce merge conflicts when multiple people work on the same feature
Keep nodes together when:
  • Nodes are tightly coupled — splitting them would require excessive signal wiring just to replicate what a direct node reference handles cleanly
  • The grouping is small and used only once — a two-node helper that exists in a single scene does not warrant its own .tscn file
  • Splitting would create simple-operation overhead — if a parent must wire three signals just to tell a child "you were hit", the split is not paying for itself

4. Node Communication Patterns

        [Parent]
        /      \
  [Child A]  [Child B]
       \
     [Child C]
Show full SKILL.md (286 more words)Show less
Signals travel up (child → parent)

A child node announces that something happened. The parent — or any node that has connected to the signal — decides what to do about it. This keeps children ignorant of their context and fully reusable.

gdscript
# Child emits; it does not know who is listening
health_component.died.connect(_on_player_died)
Method calls travel down (parent → child)

A parent drives its children by calling their methods directly. The parent owns the reference; the child exposes a clean API and does not need to know about its parent.

gdscript
# Parent calls into child
$HealthComponent.take_damage(10)
$AnimationPlayer.play("hurt")
EventBus travels sideways (peer → peer)

For communication between scenes that have no ancestor–descendant relationship — e.g., an enemy notifying the HUD — use an Autoload event bus. Emitting on the bus decouples sender from receiver entirely.

gdscript
# Autoload: EventBus.gd
signal enemy_killed(enemy: Enemy)

# Enemy scene
EventBus.enemy_killed.emit(self)

# HUD scene
EventBus.enemy_killed.connect(_on_enemy_killed)

C#

csharp
// Pattern 1: Signals travel up (child → parent)
// Child emits; it does not know who is listening.
public partial class Player : CharacterBody2D
{
    public override void _Ready()
    {
        var health = GetNode<HealthComponent>("HealthComponent");
        health.Died += OnPlayerDied;
    }

    private void OnPlayerDied()
    {
        // Parent reacts — child HealthComponent stays ignorant of context
    }
}

// Pattern 2: Method calls travel down (parent → child)
// Parent drives children by calling their methods directly.
public partial class Level : Node2D
{
    public override void _Ready()
    {
        var health = GetNode<HealthComponent>("Player/HealthComponent");
        health.TakeDamage(10);

        var anim = GetNode<AnimationPlayer>("Player/AnimationPlayer");
        anim.Play("hurt");
    }
}

// Pattern 3: EventBus travels sideways (peer → peer)
// EventBus.cs — registered as an Autoload singleton named "EventBus"
public partial class EventBus : Node
{
    [Signal] public delegate void EnemyKilledEventHandler(Enemy enemy);
}

// Enemy scene — emits on the bus; does not reference HUD
public partial class Enemy : CharacterBody2D
{
    private void Die()
    {
        var bus = GetNode<EventBus>("/root/EventBus");
        bus.EmitSignal(EventBus.SignalName.EnemyKilled, this);
        QueueFree();
    }
}

// HUD scene — subscribes on the bus; does not reference Enemy
public partial class Hud : CanvasLayer
{
    public override void _Ready()
    {
        var bus = GetNode<EventBus>("/root/EventBus");
        bus.EnemyKilled += OnEnemyKilled;
    }

    private void OnEnemyKilled(Enemy enemy)
    {
        // Update kill counter, score, etc.
    }
}

5. Scene Tree Patterns

Entity-Component Pattern
Enemy (CharacterBody2D)
├── Visuals
│   ├── Sprite2D
│   └── AnimationPlayer
├── Collision
│   └── CollisionShape2D
├── Components
│   ├── HealthComponent
│   └── HitboxComponent
└── AI
    ├── NavigationAgent2D
    └── StateMachine

Group by concern using plain Node containers (Visuals, Collision, Components, AI). Each sub-group can be collapsed in the editor and worked on independently.

UI Scene Pattern
HUD (CanvasLayer)
├── MarginContainer
│   ├── TopBar
│   │   ├── HealthBar
│   │   └── ResourceBar
│   └── BottomBar
│       ├── Hotbar
│       └── MiniMap
└── PauseMenu

CanvasLayer ensures HUD elements are always rendered on top. MarginContainer handles safe-area padding. TopBar, BottomBar, and PauseMenu are separate instantiated scenes so each can be edited without opening the root HUD scene.

Level Scene Pattern
Level01 (Node2D)
├── TileMapLayer
├── Entities
│   ├── Player (instance)
│   └── Enemies (Node2D)
│       ├── Orc (instance)
│       └── Goblin (instance)
├── Pickups (Node2D)
├── Navigation
│   └── NavigationRegion2D
└── Camera2D

The level scene is a composition root — it owns the layout and spawns instances, but contains no gameplay logic itself. Entities, Pickups, and Navigation are plain Node2D containers used for organizational grouping and to simplify get_children() iteration.

6. Checklist

  • Each scene has exactly one responsibility, named in two words or fewer
  • Reusable components (HealthComponent, StateMachine, etc.) are separate .tscn files
  • No scene exceeds ~15 nodes without a documented reason to keep it together
  • Children emit signals upward; parents call methods downward
  • Peer-to-peer communication uses an EventBus Autoload, not get_parent() chains
  • No get_parent().get_parent() or get_node("../../SomeNode") paths in code
  • Nodes are grouped into logical containers (Visuals, Components, AI, etc.) for readability

© jame581, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/scene-organization of jame581/GodotPrompter.

Open the folder on GitHubat commit 1e7d79d

Compare with similar skills

Scene Organization next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Scene Organization compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Scene Organization this skilljame581/GodotPrompter805—~2.5kAutomated safety check: PassMIT
Godot Gdscript Patterns925236118/AlphaAgent10310 repos~5kAutomated safety check: PassMIT
2D Map and Scene Generator0x0funky/agent-sprite-forge4.4k—~2.9kAutomated safety check: PassMIT
Godot UI Integrationzimo-xiao-zheng/godot-ui-integration285—~1.5kAutomated safety check: PassMIT
Godot Wechat Minigame Adaptergodothub/godot-minigame187—~1.5kAutomated safety check: PassMIT
AI Game Art Pipelineybuild-ai/ai-game-art-pipeline-skill297—~1.1kAutomated safety check: PassMIT

Similar skills

  • Godot Gdscript Patterns

    925236118/AlphaAgent

    Master Godot 4 GDScript patterns including signals, scenes, state machines, and optimization.

    103 GitHub starsUsed in 10 repos~5k tokens
    Game DevelopmentAuto-check passed

  • 2D Map and Scene Generator

    0x0funky/agent-sprite-forge

    Plans and builds 2D game maps and scenes, from tilemaps and parallax backgrounds to HD-2D plates, with collision checks, a playable HTML preview and Tiled, Godot or LDtk export.

    4.4k GitHub stars~2.9k tokensUpdated 4 days ago
    Game DevelopmentAuto-check passed

  • Godot UI Integration

    zimo-xiao-zheng/godot-ui-integration

    Build or revise Godot UI from an approved design, separated art, or a visual reference when scene structure, gameplay binding, and runtime visual verification all matter.

    285 GitHub stars~1.5k tokensUpdated 1 mo ago
    Game DevelopmentAuto-check passed

  • Godot Wechat Minigame Adapter

    godothub/godot-minigame

    Apply the bundled self-contained Godot WeChat Mini Game adapter kit to an official Godot checkout.

    187 GitHub stars~1.5k tokensUpdated 25 days ago
    Game DevelopmentAuto-check passed

  • AI Game Art Pipeline

    ybuild-ai/ai-game-art-pipeline-skill

    Provider-neutral open-source skill for planning and producing game-runtime art assets and animation: static props/icons, canonical character sheets, combat sprites, 3D/video motion references…

    297 GitHub stars~1.1k tokensUpdated 3 mo ago
    Game DevelopmentAuto-check passed

  • MCP Driver

    RandallLiuXin/GodotMaker

    Runtime debugging and live project inspection via godot-mcp.

    550 GitHub starsUsed in 1 repo~1.1k tokens
    Game DevelopmentAuto-check passed

More from jame581/GodotPrompter

All 58 skills in this repo

  • Godot 2D Essentials

    jame581/GodotPrompter

    Covers Godot 4.3+ 2D systems with GDScript and C# examples: canvas layers, draw order, TileMaps, parallax, lights and shadows, particles and custom drawing.

    805 GitHub stars~2.3k tokensUpdated yesterday
    Auto-check passed

  • Godot 3D Essentials

    jame581/GodotPrompter

    Covers Godot 4.3+ 3D systems such as materials, lighting, shadows, environment, global illumination, fog, LOD, occlusion culling and decals, with GDScript first and C# second.

    805 GitHub stars~3.7k tokensUpdated yesterday
    Auto-check passed

  • Godot Ability System

    jame581/GodotPrompter

    Builds a data-driven ability system in Godot 4 from Resources and a component node, with cooldowns, buffs, stat modifiers, gameplay tags and HUD binding.

    805 GitHub stars~3k tokensUpdated yesterday
    Auto-check passed

  • Godot Addon Development

    jame581/GodotPrompter

    Covers Godot 4.3+ editor plugins: plugin folders, @tool scripts, the EditorPlugin lifecycle, custom inspectors, dock panels and gizmos, in GDScript and C#.

    805 GitHub stars~3.3k tokensUpdated yesterday
    Auto-check passed

  • Godot AI Navigation

    jame581/GodotPrompter

    Covers pathfinding and enemy movement in Godot 4.3 and later: navigation regions, NavigationAgent nodes, steering, behavior trees and patrol routes.

    805 GitHub stars~3.5k tokensUpdated yesterday
    Auto-check passed

  • Godot Animation System

    jame581/GodotPrompter

    Covers animation in Godot 4.3 and later: AnimationPlayer basics, AnimationTree blend trees and state machines, sprite animation, skeleton IK and code-driven motion.

    805 GitHub stars~3.8k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Scene Organization

What does Scene Organization do?

A skill your agent uses when designing scene tree structure — composition vs inheritance, when to split scenes, node hierarchy patterns. Scene Organization is an agent skill from jame581/GodotPrompter.

When should I use Scene Organization?

Scene Organization fits situations like: designing scene tree structure — composition vs inheritance; to split scenes; Node hierarchy patterns.

How do I install Scene Organization in Claude Code?

Run `npx skills add jame581/GodotPrompter --skill scene-organization -a claude-code`. Or copy the skill folder (skills/scene-organization in jame581/GodotPrompter) into .claude/skills/scene-organization in your project. Claude Code loads it when a task matches its description.

How do I install Scene Organization in Codex?

Run `npx skills add jame581/GodotPrompter --skill scene-organization -a codex`. Or copy the skill folder (skills/scene-organization in jame581/GodotPrompter) into .agents/skills/scene-organization in your project. Codex loads it when a task matches its description.

Can I use Scene Organization in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add jame581/GodotPrompter --skill scene-organization -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/scene-organization, .gemini/skills/scene-organization, .github/skills/scene-organization and .opencode/skills/scene-organization in your project.

What does Scene Organization need to run?

SKILL.md names no scripts, command-line tools or credentials: Scene Organization is instructions for the agent only.

Does Scene Organization access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Scene Organization safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Scene Organization use?

Scene Organization is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Scene Organization use?

About 2.5k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Scene Organization?

Skills that share tags, products or a category with Scene Organization: Godot Gdscript Patterns (925236118/AlphaAgent, 103 stars), 2D Map and Scene Generator (0x0funky/agent-sprite-forge, 4.4k stars), Godot UI Integration (zimo-xiao-zheng/godot-ui-integration, 285 stars) and Godot Wechat Minigame Adapter (godothub/godot-minigame, 187 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Scene Organization?

jame581 (a GitHub user) maintains it in jame581/GodotPrompter, which has 805 GitHub stars. The repository holds 58 skills in this directory. The repository was last updated on October 9, 2026.

Source: jame581/GodotPrompter on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.