agentleFS
jammyfujammyfu/open-game-skills/skills/disciplines/asset-runtime/SKILL.md

asset-runtime

Skill12 starsChanged 23 days agoMITView on GitHub

Use when assets load twice, stale callbacks resurrect objects, shared textures disappear on scene exit, or repeated scene changes leak memory or block interaction.

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
  1. Distinctive:

    Keep fetch/decode readiness separate from instantiation, GPU upload and gameplay activation.

    line 25

≈ “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

Asset runtime

Scope

Own resource acquisition, sharing and release, not model authoring, atlas packing or deciding which world cells should exist. Inspect the loader/engine version and current asset manager before adding another. Model pipeline owns export; performance-budget owns target limits.

Modes

ModeLifetime
scene-ownedhandles end when the owning scene ends
shared-cacheresources outlive one scene through explicit leases
staged-loadrequest, fetch, decode/upload and activation are distinct gates

Procedure

  1. Publish stable asset IDs and a versioned manifest: content identity, type, dependencies, estimated budgets and failure fallback. Resolve dependencies and detect cycles before activation. A filename is not a stable gameplay ID.
  2. Deduplicate in-flight loads by asset identity/version, but give each consumer its own lease. Record owner and epoch. Releasing one consumer must not cancel another consumer's shared request or dispose its texture. Dispose only when ownership and the explicit cache policy permit it.
  3. Publish request states: pending, ready, failed, cancelled and released. Cancel underlying work only when supported and unneeded; always guard result delivery with consumer epoch/liveness. Clean up an orphan result without attaching it to an obsolete scene. Bound retry/backoff and distinguish a missing optional decoration from a required collision asset.
  4. Keep fetch/decode readiness separate from instantiation, GPU upload and gameplay activation. Do not block the interaction thread waiting for a pending result. In Godot, check threaded-load status before retrieving a resource that must not block. Respect the engine's main-thread requirements.
  5. Release listeners, workers, audio and GPU handles as well as scene nodes. In Three.js, removing a node does not dispose its geometry/material/texture. Track shared texture ownership independently. Context/device loss needs an explicit reload policy, not a promise that disposed resources survive.

Outputs

Adapt the resource contract: manifest, lease/epoch table, loading state machine, failure policy, disposal inventory and measured load/churn trace. A cache budget and eviction policy must name the target device; examples are not measurements.

Acceptance

Two scenes share one texture: unload one and the other still renders. Leave during a pending load and check that no stale actor appears. Repeat the cycle with failed loads, cancelled consumers and a cache version change. Compare live handles and memory after warm-up and reclamation against a declared tolerance, not an expectation that all caches instantly return to zero. Cases are not-run until executed on the named adapter/device.

References

Three.js cleanup documents explicit GPU-resource disposal. Godot background loading explains why retrieving a pending threaded resource can still block. These APIs are adapter details, not an engine-neutral implementation supplied by this skill.

Context/device recovery

Use the recovery protocol for black screens after graphics loss: separate logical leases from GPU generations, coalesce/bound recovery, and test late uploads plus scene exit. game-state-flow owns resume/pause/rejoin policy; restored rendering cannot replay settlement. This protocol adds no untested universal GPU recovery implementation.

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.