ibrohim1234567881717
UserAI skills for game development: Unreal Engine, Unity, Godot, Roblox, Minecraft modding and web. Stops your AI assistant writing Godot 3 code into a Godot 4 project. 71 skills, 15 agents, Agent Skills standard.
Categories
Indexed Skills (46)
game-architecture
Structuring a game codebase - separating simulation from presentation, choosing between inheritance, composition and ECS, managing game state and scene flow, and deciding what lives in data rather than code. Use when starting a game project, adding a system that touches many others, or when a game codebase has become hard to change. Engine-agnostic; platform skills supply the engine's own idioms.
gameplay-systems
Implementing game mechanics as maintainable systems - state machines, abilities, stats and modifiers, cooldowns, damage pipelines, and the tuning data behind them. Use when building or extending combat, abilities, character state, progression, or any rule-driven mechanic, and when a mechanic has become a tangle of special cases. Engine-agnostic.
input-systems
Structuring player input - separating raw device events from game actions, supporting multiple device types and rebinding, handling context switches between gameplay and UI, and input buffering and responsiveness. Use when setting up input for a project, adding controller or touch support, implementing rebinding, or when controls feel unresponsive or fire in the wrong context.
multiplayer-networking
Designing networked gameplay - authority model, state replication, client prediction and reconciliation, latency compensation, bandwidth budgeting, and handling disconnects. Use when adding multiplayer, when networked movement or combat feels wrong, when players desynchronise, or when deciding between listen server, dedicated server and peer-to-peer.
save-systems
Designing save and load systems that survive shipping - deciding what to persist, choosing a format, versioning the schema and migrating old saves, resisting corruption, and timing autosaves. Use when building or changing persistence, when saves break after an update, when players report lost progress, or when deciding what belongs in a save file at all.
level-design-and-environment
Building levels that play well and run well - blockout before art, readability and player guidance, metrics and scale, modularity and reuse, and the streaming and occlusion structure that keeps a level affordable. Use when creating or revising a level or environment, when players get lost or stuck, or when a level is over budget on frame time or memory.
lighting-design
Lighting a scene for readability and mood while staying within budget - key/fill/rim structure, direct versus indirect light, baked versus dynamic, shadow configuration, and exposure. Use when setting up lighting for a level, when a scene reads poorly or players cannot navigate it, when lighting looks flat or blown out, or when lighting cost is too high.
materials-and-shaders
Authoring materials and shaders that look right and cost what you expect - PBR inputs, texture channel packing, shader variants and permutations, node graphs versus hand-written code, and instancing. Use when creating or debugging materials, writing shader code, when a surface does not respond correctly to light, or when shader cost or build times have grown.
post-processing
Configuring screen-space effects - tonemapping and exposure, colour grading, bloom, ambient occlusion, anti-aliasing, motion blur and depth of field - for look and for cost. Use when setting up a post-processing stack, when the image looks washed out, crushed, over-bloomed or aliased, or when full-screen effects are consuming too much of the frame.
render-debugging
Diagnosing visual artifacts by isolating which stage of the frame produces them - missing or black objects, z-fighting, flickering, wrong colours, shadow acne, sorting errors, and platform-specific visual differences. Use when something looks wrong and it is not obvious why, and before changing settings hoping the artifact disappears.
rendering-fundamentals
The concepts every rendering task depends on - the frame pipeline, colour space and gamma, physically based shading inputs, transparency and sorting, depth and precision, and units and scale. Use before working on lighting, materials, shaders or post-processing, and when diagnosing visuals that look subtly wrong everywhere rather than in one asset.
vfx-and-particles
Authoring visual effects that read clearly and cost what you expect - particle system structure, overdraw and fill rate, timing and readability, pooling and lifetime, and CPU versus GPU simulation. Use when creating effects for abilities, impacts, weather or ambience, when effects tank frame rate, or when an effect does not read at gameplay distance.
performance-profiling-method
The measurement discipline for all performance work - establish a baseline, profile, identify the single dominant bottleneck, fix only that, then re-profile to prove the change. Use whenever anything is described as slow, laggy, stuttering, dropping frames, taking too long to load, or using too much memory, and before accepting any optimisation suggestion.
bug-triage
Turning a stream of reports into a ranked, actionable queue - writing reports that can be acted on, reproducing and confirming, assessing severity by impact rather than annoyance, and deciding what will not be fixed. Use when handling incoming bug reports, preparing a release, or when a backlog has grown unmanageable.
testing-strategy
Deciding what to test, at which level, and what a test must prove to be worth its maintenance cost. Use when adding tests to new work, when a bug escapes to production, when a suite is slow or flaky, or when deciding whether something is testable at all. Covers the test levels, testing behaviour rather than implementation, testing game and interactive systems, and flake control.
version-control-workflow
Working with version control on projects that include large binary assets - branching, commit hygiene, merge conflict handling, LFS and file locking, and what belongs in the repository. Use when setting up a repository, when merges keep destroying work, when the repository has grown unmanageably large, or when deciding what to commit in an engine project.
api-design
Designing interfaces others depend on - naming, parameters, error signalling, invariants, and versioning without breaking callers. Use when adding a public function, module, service or plugin interface, when an API is confusing or misused, or when a change would break existing callers. Covers making correct use easy and incorrect use hard.
code-review-method
Adversarial review that tries to find real defects in a change rather than confirming it looks fine. Use when reviewing a diff, pull request, or generated code before accepting it, and as the independent final pass over any work an agent produced. Covers what to read first, the defect classes worth hunting, how to rank findings by severity, and how to report them so they can be acted on.
dependency-analysis
Understanding and controlling what a codebase depends on - internal module coupling and cycles, and external package risk, versions, and upgrade cost. Use before adding a dependency, when an upgrade breaks things, when build times or binary sizes grow, when modules cannot be built or tested in isolation, and when auditing a project you did not write.
refactoring-safely
Changing code structure without changing behaviour - establishing a safety net first, making small reversible steps, and verifying equivalence at each one. Use when code is hard to change or test, before adding a feature to a tangled area, or when cleaning up after a fix. Distinguishes refactoring from rewriting and from behaviour change, which need different handling.
root-cause-debugging
Evidence-driven debugging that finds the actual cause of a defect instead of changing code until symptoms disappear. Use when something crashes, throws, returns wrong results, behaves inconsistently, works on one machine but not another, or fails intermittently. Also use to review a proposed fix that has no stated cause.
software-architecture
Designing system structure - module boundaries, dependency direction, layering, and the decisions that are expensive to reverse later. Use before implementing a feature that spans more than one system, when a codebase has become hard to change, when deciding where new code belongs, or when reviewing a design. Covers coupling and cohesion, dependency inversion, choosing what to make extensible, and recording decisions.
client-server-trust
The trust boundary rule for any system where code runs on hardware someone else controls - game clients, browsers, mobile apps, mod clients. Use when designing or auditing anything involving player actions, currency, items, scores, purchases, matchmaking, or multiplayer state, and whenever deciding which side of a connection computes a result. Covers server authority, input validation, rate limiting, information disclosure, and the difference between authentication and authorization.
secure-coding
Implementation-level defensive practice - validating input at boundaries, handling secrets, avoiding injection, safe error handling, dependency hygiene, and safe defaults. Use while writing or reviewing code that parses external input, builds queries or commands, handles credentials or tokens, serialises data, or manages permissions. Complements threat-modeling, which decides what to defend, by covering how to implement the defence.
threat-modeling
Structured analysis of what an attacker would target in a system and which defences are worth building. Use before designing a feature that handles money, accounts, player data, user content, or competitive state, when scoping a security review, or when deciding whether a reported weakness matters. Produces a ranked list of threats with concrete mitigations rather than a generic security checklist.
godot-character-controllers
Building and debugging character movement in Godot with CharacterBody2D and CharacterBody3D - move_and_slide, floor detection, slopes and steps, movement state machines, and the frame-rate and collision bugs that controllers commonly have. Use when creating a player controller, when movement feels wrong, or when a character sticks, slides, jitters or falls through geometry.
godot-csharp-integration
Using C# in Godot 4 - the .NET editor build, partial classes and source generators, the Export, Signal, GlobalClass and Tool attributes, Variant marshalling cost across the engine boundary, calling between C# and GDScript, and the platform export limits that C# imposes. Use when a project has a .csproj beside project.godot, when deciding whether a system is worth writing in C# rather than GDScript, or when diagnosing build, marshalling or export failures specific to the .NET build.
godot-gdscript-patterns
Idiomatic GDScript 2.0 for Godot 4 - static typing, the @export, @onready and @tool annotations, node lifecycle callbacks, signals as first-class objects, await, class_name registration, lambdas and typed collections. Use when writing or reviewing .gd files, when porting Godot 3 GDScript, or when deciding between get_node, @onready and dependency injection. Explicitly separates Godot 4 syntax from the Godot 3 forms that look similar and fail.
godot-performance-profiling
Measuring performance in Godot - the profiler, the monitors, frame time breakdown, draw calls, physics cost, GDScript hot paths and memory. Use when a Godot project drops frames, stutters, takes too long to load, or uses too much memory, and before proposing any optimisation. Supplies Godot's tooling for the measurement loop; the loop itself is in performance-profiling-method.
godot-project-conventions
Entry point for any Godot task. Establishes which Godot major version a project targets by reading config_version in project.godot (5 means Godot 4.x, 4 means Godot 3.x), then covers res:// and user:// paths, autoload singletons, folder layout, .import and .uid sidecar files, and what belongs in version control. Load this before writing any GDScript, C#, scene or shader for an unfamiliar Godot project, because Godot 3 and Godot 4 share a name and almost no API.
godot-scene-composition
Designing Godot scene trees - scenes as reusable components, instancing with PackedScene and instantiate, composition over inheritance, node ownership and the owner property, scene-unique names, editable children and inherited scenes, and how a node should reach its collaborators. Use when adding nodes or scenes, when a scene tree has grown deep and brittle, when deciding between an inherited scene and a component node, or when runtime-built subtrees fail to save or serialise.
godot-signals-events
Godot signals as first-class objects - declaring custom signals, connect and emit in Godot 4, Callable binding, connection flags, editor connections stored in the .tscn, awaiting a signal, and when an event bus autoload helps versus when it hides the call graph. Use when wiring nodes together, when a handler fires twice or never, when connections leak across scene reloads, or when a codebase has become impossible to trace because everything talks through a global bus.
minecraft-blocks-items
Adding blocks and items to a Minecraft mod on Fabric or NeoForge. Covers registration order, block state properties, block entities and their ticking, item data components and properties, creative tab insertion, the blockstate/model/texture JSON chain, and translation keys. Use when adding or debugging a block, an item, a block entity, a missing texture, a purple-and-black model or an item that will not appear in the creative menu.
minecraft-entities-mobs
Adding entities and mobs to a Minecraft mod on Fabric or NeoForge. Covers EntityType registration and dimensions, attribute registration, goal-based and brain-based AI, natural spawn rules and spawn eggs, entity data synchronisation to clients, and the client-side renderer and model layer split. Use when adding a mob, projectile or vehicle, or when an entity is invisible, immediately dies, never spawns, or crashes the dedicated server.
minecraft-mod-architecture
How a Minecraft mod is structured on Fabric and on NeoForge. Covers entrypoints, the registration architecture and its timing rules, deferred and lazy registration, the hard separation between common and client code that keeps dedicated servers alive, package structure and mod id discipline. Use when creating a mod skeleton, adding a new registry, or diagnosing a crash that happens at mod load or only on a dedicated server.
minecraft-networking
Custom packets between client and server in a Minecraft mod, on Fabric or NeoForge. Covers the CustomPacketPayload model, payload registration and stream codecs per loader, the threading rule that handlers must schedule work back onto the main thread, and validating every client-sent packet because the client is an attacker. Use when adding a packet, syncing state to clients, handling a GUI button server-side, or diagnosing a ConcurrentModificationException or a client-triggered exploit.
minecraft-project-conventions
Entry skill for every Minecraft mod task. Forces resolution of the mod loader, the Minecraft version and the mappings from gradle.properties, fabric.mod.json and META-INF/neoforge.mods.toml before any code is written, then explains the Gradle layout, source sets, resource layout, run configurations and where mod metadata lives on each loader. Load this first whenever a repository looks like a Minecraft mod.
minecraft-recipes-datagen
Producing recipes, loot tables, tags, advancements and models through Minecraft data generation instead of hand-written JSON, on Fabric or NeoForge. Covers the datagen entrypoint per loader, provider classes, generated resource roots, tag conventions across loaders, and custom recipe serializers. Use when adding a recipe or loot table, when data pack JSON silently fails to load, or when setting up runDatagen/runData for a mod.
minecraft-worldgen
Adding biomes, features, ore placement, structures and dimensions to a Minecraft mod on Fabric or NeoForge. Covers the data-driven worldgen registry model, configured versus placed features, placement modifiers, structure sets, biome modification per loader, datapack registry bootstrap in datagen, and how to debug worldgen that does not appear. Use when adding ore generation, a custom biome, a structure or a dimension, or when generated content is missing from new chunks.
roblox-client-server-architecture
Structuring the client-server boundary in Roblox - RemoteEvents, RemoteFunctions, UnreliableRemoteEvents and BindableEvents, what replicates automatically and what does not, request-response patterns, ownership of state, and network ownership of parts. Use when designing any feature where the client and server must both participate, when replication behaves unexpectedly, or when deciding which side computes a result.
roblox-datastore-persistence
Saving player data in Roblox without losing or duplicating it - UpdateAsync versus SetAsync, session locking, request budgets and throttling, retries with backoff, schema versioning and migration, MemoryStoreService for cross-server state, and BindToClose. Use when building or fixing persistence, when players report lost progress, or when investigating item duplication.
roblox-luau-patterns
Writing idiomatic typed Luau for Roblox. Use when creating or refactoring any .luau module, adding type annotations, deciding between a plain table module and a metatable class, or fixing luau-lsp diagnostics. Covers --!strict and the language modes, type aliases and exported types, generics and type packs, the metatable class idiom with correct self typing, Instance typing and the nil-safety that strict mode forces, the differences between Luau and Lua 5.1 that break copied code (continue, compound assignment, string interpolation, no goto, no setfenv, bit32 instead of bitwise operators), and the performance-relevant idioms around allocation, iteration and the task library.
roblox-monetization
Handling Robux purchases correctly - developer products, game passes, subscriptions, ProcessReceipt and its exactly-once semantics, MarketplaceService checks, and granting items without duplicating or losing them. Use when implementing or auditing any purchase flow, when players report paying without receiving, or when investigating duplicated purchased items.
roblox-project-conventions
Entry skill for any Roblox Studio codebase. Establishes whether the project is a Rojo filesystem project or a Studio-only place (which decides whether writing .luau files produces usable work at all), where code belongs across ServerScriptService, ServerStorage, ReplicatedStorage, ReplicatedFirst and StarterPlayer, when to use a Script, a LocalScript or a ModuleScript, and how the rokit and wally toolchain is wired. Use this before writing any Roblox code, before deciding where a new file goes, and before adding a dependency.
roblox-security
Entry skill and audit procedure for Roblox exploit resistance. Use when reviewing or writing any code that crosses the client-server boundary, grants currency or items, persists player data, or handles purchases. Gives a concrete walkthrough for auditing every RemoteEvent and RemoteFunction for type, range, ownership, rate and business-rule validation, for finding client-authoritative decisions, duplication exploits caused by non-atomic DataStore access, missing session locks and non-idempotent ProcessReceipt handlers, plus a checklist to walk a codebase against and a format for reporting findings. The governing rule is that the client is a rendering and input surface, never a source of truth.
unity-animation
Drive characters and objects with Unity's animation stack - Animator controllers and state machines, blend trees, layers and avatar masks, humanoid retargeting, root motion versus scripted motion, Timeline and the Playables API, and animation performance including culling and transform hierarchy optimisation. Use when a state will not transition or feels unresponsive, when Write Defaults produces inconsistent poses, when root motion and a character controller fight each other, when authoring cutscenes, or when Animator.Update dominates the profiler.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.