Install the "dependency-injection" agent skill from https://github.com/jame581/GodotPrompter/tree/master/skills/dependency-injection into .claude/skills/dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "dependency-injection", then confirm the skill loads.
Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
skills CLI
$ npx skills add jame581/GodotPrompter --skill dependency-injection -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
Install the "dependency-injection" agent skill from https://github.com/jame581/GodotPrompter/tree/master/skills/dependency-injection into .agents/skills/dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "dependency-injection", then confirm the skill loads.
Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add jame581/GodotPrompter --skill dependency-injection -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
Install the "dependency-injection" agent skill from https://github.com/jame581/GodotPrompter/tree/master/skills/dependency-injection into .cursor/skills/dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "dependency-injection", then confirm the skill loads.
Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
skills CLI
$ npx skills add jame581/GodotPrompter --skill dependency-injection -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "dependency-injection" agent skill from https://github.com/jame581/GodotPrompter/tree/master/skills/dependency-injection into .gemini/skills/dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "dependency-injection", then confirm the skill loads.
Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
skills CLI
$ npx skills add jame581/GodotPrompter --skill dependency-injection -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "dependency-injection" agent skill from https://github.com/jame581/GodotPrompter/tree/master/skills/dependency-injection into .github/skills/dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "dependency-injection", then confirm the skill loads.
GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add jame581/GodotPrompter --skill dependency-injection -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "dependency-injection" agent skill from https://github.com/jame581/GodotPrompter/tree/master/skills/dependency-injection into .opencode/skills/dependency-injection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "dependency-injection", then confirm the skill loads.
OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
Skill name
dependency-injection
GitHub stars
795
Token cost
~2.8k tokens
SKILL.md length
663 words
Files
6 (incl. references)
Skills in repo
58
Repo updated
First seen
Licence
MIT
At a glance
A skill your agent uses when managing dependencies between systems — autoloads, service locators, @export injection, and scene injection patterns
Works in 10 steps: The Problem → Approach Comparison → Autoloads as Singletons → …
Managing dependencies between systems — autoloads
SKILL.md covers 1. The Problem, 2. Approach Comparison, 3. Autoloads as Singletons and 4. @export Node Injection, plus 6 more sections
Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
What it does
Dependency Injection is an agent skill from jame581/GodotPrompter. Use when managing dependencies between systems — autoloads, service locators, @export injection, and scene injection patterns
Its SKILL.md is about 2.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 6 other files, including reference files (for example `references/autoloads.md`, `references/export-injection.md` and `references/scene-injection.md`).
It sits in Game Development, covering Design patterns and 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
Managing dependencies between systems — autoloads
Service locators
@export injection
Scene injection patterns
Example prompts
“/dependency-injection”
Workflow steps
10 steps, taken from the step headings in SKILL.md.
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
Dependency Injection loads about 2.8k tokens when it runs, and up to ~6.8k if it reads all its reference files. Until then it costs about 37 tokens; SKILL.md has 663 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~37
When it runs· the whole SKILL.md, loaded when a task matches
~2.8k
With references· SKILL.md plus every file in references/, read only if the agent opens them
~6.8k
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.
Download SKILL.mdSave it as .claude/skills/dependency-injection/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
dependency-injection
description
Use when managing dependencies between systems — autoloads, service locators, @export injection, and scene injection patterns
Dependency Injection in Godot 4.3+
Patterns for wiring dependencies between systems so nodes stay loosely coupled, swappable, and testable. All examples target Godot 4.3+ with no deprecated APIs.
Related skills:godot-testing for test-friendly architecture, event-bus for signal-based decoupling, godot-project-setup for autoload registration.
1. The Problem
Tight coupling makes code hard to test, extend, and swap. The most common form in Godot is reaching directly into a global autoload from everywhere in the codebase.
gdscript
# BAD — tight coupling via direct autoload access scattered everywhere
# player.gd
func take_damage(amount: int) -> void:
health -= amount
AudioManager.play_sfx("hurt") # hard dependency on AudioManager
UIManager.update_health_bar(health) # hard dependency on UIManager
if health <= 0:
GameState.record_death() # hard dependency on GameState
# enemy.gd
func attack() -> void:
AudioManager.play_sfx("attack") # same AudioManager dependency again
csharp
// BAD — tight coupling via direct autoload / global access scattered everywhere
// Player.cs
public partial class Player : CharacterBody3D
{
private int _health = 100;
public void TakeDamage(int amount)
{
_health -= amount;
GetNode<AudioManager>("/root/AudioManager").PlaySfx("hurt"); // hard dependency
GetNode<UIManager>("/root/UIManager").UpdateHealthBar(_health); // hard dependency
if (_health <= 0)
GetNode<GameState>("/root/GameState").RecordDeath(); // hard dependency
}
}
// Enemy.cs
public partial class Enemy : CharacterBody3D
{
public void Attack()
{
GetNode<AudioManager>("/root/AudioManager").PlaySfx("attack"); // same dependency again
}
}
Problems with this approach:
Every node that calls AudioManager directly is coupled to its concrete implementation.
Swapping AudioManager for a different implementation requires changing every caller.
Unit-testing Player in isolation is impossible — AudioManager, UIManager, and GameState must all exist and be valid.
Autoload initialization order bugs silently break behaviour when scenes load.
Hidden dependencies make it hard to see what a class actually needs to function.
2. Approach Comparison
Pattern
Complexity
Testability
Best For
Autoloads
Low
Low
Truly global singletons: audio, settings, platform services
@export Injection
Low
High
Most nodes — wire deps in the editor, no runtime lookup needed
Service Locator
Medium
Medium
Plugins, optional systems, swappable implementations at runtime
Scene Injection
Low
High
Parent-to-child wiring: Level sets up Enemy, HUD sets up sub-panels
3. Autoloads as Singletons
Register a script in Project Settings → Globals → Autoload for global access (AudioManager.play_sfx(...), GameState.score = 100). Best for cross-cutting concerns: audio, save state, event bus, settings. Resist autoloading domain-specific systems (those should be scene-injected).
See references/autoloads.md for the full AudioManager example (SFX + crossfade music) in GDScript + C#.
4. @export Node Injection
Expose collaborator nodes as @export var health_component: HealthComponent, then wire in the Inspector or via parent scene. Lifecycle: @export properties are assigned BEFORE _ready().
A central registry autoload mapping String keys to service instances. Services register themselves at _ready(), deregister at _exit_tree(), consumers call ServiceLocator.get(name). Useful when you want flexible runtime swap of implementations (testing, mods, A/B variants).
Parent scene loads its children, then in _ready() walks the tree assigning dependencies (enemy.player = $Player). Children declare @export properties but the parent — not the Inspector — sets them. Best for game-specific dependencies that change per level.
Injecting fakes / test doubles is what makes nodes testable. For autoloads: mock-replace before the test scene loads. For @export injection: swap the export to a test double. For Service Locator: register a fake under the same key.
Parent scene constructs children and knows their needs
Scene injection
Writing tests for a node with external dependencies
@export or property injection + stubs
Plugin that must work in any project
Service Locator (self-registers, no assumptions)
Two sibling nodes need the same dep
Let their parent hold it and inject downward
Quick decision guide:
Does every scene in the project need it?
YES → Autoload singleton
NO ↓
Is the dependency known at edit-time and wired in the Inspector?
YES → @export injection
NO ↓
Does the dependency need to be swapped at runtime (plugins, A/B testing)?
YES → Service Locator
NO ↓
Does a parent scene own both the consumer and the dependency?
YES → Scene injection
NO → Reconsider — either promote to autoload or restructure ownership
9. Anti-patterns
Autoload for everything
gdscript
# BAD — GameManager, EnemySpawner, InventorySystem, DialogueSystem all as autoloads.
# Every node in the game is coupled to every other system at module level.
# Test one component → must initialise all autoloads.
# GOOD — Only AudioManager, Settings, and SceneTransition are autoloads.
# EnemySpawner is a node in the Level scene, injected into enemies that need it.
csharp
// BAD — GameManager, EnemySpawner, InventorySystem, DialogueSystem all as autoloads.
// Every node in the game is coupled to every other system at module level.
// Test one component → must initialise all autoloads.
// GOOD — Only AudioManager, Settings, and SceneTransition are autoloads.
// EnemySpawner is a node in the Level scene, injected into enemies that need it.
Deep dependency chains
gdscript
# BAD — Player needs HealthComponent, which needs AudioManager,
# which needs SoundBank, which needs FileSystem...
# A change deep in the chain breaks everything above it.
# GOOD — flatten: HealthComponent takes only AudioManager (or a narrow interface).
# Each node declares only immediate dependencies.
csharp
// BAD — Player needs HealthComponent, which needs AudioManager,
// which needs SoundBank, which needs FileSystem...
// A change deep in the chain breaks everything above it.
// GOOD — flatten: HealthComponent takes only AudioManager (or a narrow interface).
// Each node declares only immediate dependencies.
Circular dependencies
gdscript
# BAD
# PlayerController._ready() calls ServiceLocator.get_service("inventory")
# InventorySystem._ready() calls ServiceLocator.get_service("player")
# Neither can fully initialise because the other isn't ready yet.
# GOOD — break the cycle with a signal.
# InventorySystem emits item_used; PlayerController connects to it.
# PlayerController never holds a reference to InventorySystem at all.
csharp
// BAD
// PlayerController._Ready() calls ServiceLocator.GetService("inventory")
// InventorySystem._Ready() calls ServiceLocator.GetService("player")
// Neither can fully initialise because the other isn't ready yet.
// GOOD — break the cycle with a signal.
// InventorySystem emits ItemUsed; PlayerController connects to it.
// PlayerController never holds a reference to InventorySystem at all.
Service Locator as a god object
gdscript
# BAD — everything is registered: enemies, UI panels, individual nodes.
# ServiceLocator becomes a second, untyped scene tree.
# GOOD — only register stable, long-lived services (audio, analytics, save system).
# Short-lived nodes are wired by their parent via scene injection.
csharp
// BAD — everything is registered: enemies, UI panels, individual nodes.
// ServiceLocator becomes a second, untyped scene tree.
// GOOD — only register stable, long-lived services (audio, analytics, save system).
// Short-lived nodes are wired by their parent via scene injection.
Forgetting null checks after injection
gdscript
# BAD — crashes if the @export was never set in the editor
func take_damage(amount: int) -> void:
audio.play_sfx("hurt") # NullReferenceError if audio was not wired
# GOOD — guard or assert clearly
func take_damage(amount: int) -> void:
assert(audio != null, "HealthComponent: audio dependency was not injected")
audio.play_sfx("hurt")
# OR — treat it as optional
func take_damage(amount: int) -> void:
if audio != null:
audio.play_sfx("hurt")
csharp
// BAD — crashes if the [Export] was never set in the editor
public void TakeDamage(int amount)
{
_audio.PlaySfx("hurt"); // NullReferenceException if _audio was not wired
}
// GOOD — guard or assert clearly
public void TakeDamage(int amount)
{
if (_audio == null)
{
GD.PushError("HealthComponent: audio dependency was not injected");
return;
}
_audio.PlaySfx("hurt");
}
// OR — treat it as optional
public void TakeDamage(int amount)
{
_audio?.PlaySfx("hurt");
}
10. Checklist
Autoloads are used only for genuinely global services (audio, settings, platform)
Nodes declare their dependencies explicitly (@export or a public property) rather than calling get_node on distant relatives
@export fields are validated (assert or null check) before use
Service Locator services call unregister in _exit_tree() / _ExitTree()
Scene injection is done in the parent's _ready(), after children are fully initialised
No circular dependencies between services or autoloads
Each node depends only on its immediate collaborators — no deep chains
Test stubs/mocks are plain nodes that implement the same interface as the real service
C# @export ([Export]) dependencies are disconnected / cleared in _ExitTree() if they hold event subscriptions
Service Locator is not used to store scene-specific or short-lived nodes
Dependency Injection 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.
Dependency Injection compared with similar skills
Skill
Stars
Used in
Tokens
Auto-check
Licence
Repo updated
Dependency Injection this skilljame581/GodotPrompter
Expert patterns for Godot AutoLoad (singleton) architecture including global state management, scene transitions, signal-based communication, dependency injection, autoload initialization order, and…
Navigation skill for genre project scaffolds: pick platformer/RPG/FPS (or other genre) then load matching template scripts and route gameplay fill to godot-genre- skills.
Covers Godot 4.3+ 2D systems with GDScript and C# examples: canvas layers, draw order, TileMaps, parallax, lights and shadows, particles and custom drawing.
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.
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.
Covers Godot 4.3+ editor plugins: plugin folders, @tool scripts, the EditorPlugin lifecycle, custom inspectors, dock panels and gizmos, in GDScript and C#.
Covers animation in Godot 4.3 and later: AnimationPlayer basics, AnimationTree blend trees and state machines, sprite animation, skeleton IK and code-driven motion.
A skill your agent uses when managing dependencies between systems — autoloads, service locators, @export injection, and scene injection patterns. Dependency Injection is an agent skill from jame581/GodotPrompter.
When should I use Dependency Injection?
Dependency Injection fits situations like: managing dependencies between systems — autoloads; service locators; @export injection; scene injection patterns.
How do I install Dependency Injection in Claude Code?
Run `npx skills add jame581/GodotPrompter --skill dependency-injection -a claude-code`. Or copy the skill folder (skills/dependency-injection in jame581/GodotPrompter) into .claude/skills/dependency-injection in your project. Claude Code loads it when a task matches its description.
How do I install Dependency Injection in Codex?
Run `npx skills add jame581/GodotPrompter --skill dependency-injection -a codex`. Or copy the skill folder (skills/dependency-injection in jame581/GodotPrompter) into .agents/skills/dependency-injection in your project. Codex loads it when a task matches its description.
Can I use Dependency Injection 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 dependency-injection -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/dependency-injection, .gemini/skills/dependency-injection, .github/skills/dependency-injection and .opencode/skills/dependency-injection in your project.
What does Dependency Injection need to run?
SKILL.md names no scripts, command-line tools or credentials: Dependency Injection is instructions for the agent only.
Does Dependency Injection 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 Dependency Injection 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 Dependency Injection use?
Dependency Injection 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 Dependency Injection use?
About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 4k tokens, read only when the agent opens those files.
What are the alternatives to Dependency Injection?
Skills that share tags, products or a category with Dependency Injection: Godot Autoload Architecture (thedivergentai/GD-Agentic-Skills, 809 stars), Godot Composition (thedivergentai/GD-Agentic-Skills, 809 stars), Godot Composition Apps (thedivergentai/GD-Agentic-Skills, 809 stars) and Godot Performance Optimization (thedivergentai/GD-Agentic-Skills, 809 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Dependency Injection?
jame581 (a GitHub user) maintains it in jame581/GodotPrompter, which has 795 GitHub stars. The repository holds 58 skills in this directory. The repository was last updated on October 6, 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.