agentleFS
MRCalderon3DMRCalderon3D/everything-game-dev-code/skills/art-audio-content/placeholder-asset-pipeline/SKILL.md

placeholder-asset-pipeline

Skill105 starsChanged 8 months agoMITView on GitHub

Define creation, naming, and replacement rules for placeholder assets so the game is testable before final art exists.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    place placeholders in the same folder path and with the same file name that final assets will use

    line 28
  2. Distinctive:

    document the replacement checklist — what to swap, where, and how to validate after swapping

    line 30
  3. Distinctive:

    every placeholder uses the exact name and path that the final asset will use — zero code changes on swap

    line 39
  4. Distinctive:

    Keep this skill aligned with the relevant rules layer and current project documentation.

    line 69
  5. Distinctive:

    If engine-specific constraints materially change the workflow, hand off to the matching engine skill or engine-specific reviewer.

    line 70
  6. Very specific:

    If placeholders are later replaced with generated raster art, hand off to generated-raster-asset-pipeline before acceptance so transparency …

    line 75

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

Placeholder Asset Pipeline

Purpose

Define creation, naming, and replacement rules for placeholder assets so the game is visually testable and gameplay-verifiable before final art, audio, or VFX assets are produced.

Use When

  • core systems are implemented but no final assets exist yet
  • the game needs to be runnable for playtesting or QA before art delivery
  • new entities are added and need immediate visual representation for testing
  • final assets are being swapped in and the drop-in replacement path needs validation

Inputs

  • entity list from the GDD or milestone plan (player, enemies, collectibles, environment, UI)
  • gameplay scale and collision requirements per entity
  • folder structure and naming convention from the art bible or project setup
  • target platform constraints (resolution, texture budget)

Process

  1. inventory all entities that need visual representation for the current milestone
  2. generate placeholder assets (colored sprites for 2D, flat-color 3D primitives for 3D, procedural audio for sounds) at correct gameplay scale
  3. place placeholders in the same folder path and with the same file name that final assets will use
  4. wire placeholders into prefabs or scenes so the game is immediately playable
  5. document the replacement checklist — what to swap, where, and how to validate after swapping

Outputs

  • placeholder assets for all milestone entities (sprites or 3D primitives, prefabs/scenes, procedurally generated audio clips)
  • drop-in replacement guide (file paths, naming, validation steps)
  • scene or prefab configuration with placeholders wired and playable
  • replacement validation checklist

Quality Bar

  • every placeholder uses the exact name and path that the final asset will use — zero code changes on swap
  • placeholder scale matches gameplay requirements — colliders and physics work correctly
  • the game is fully playable with placeholders alone — no missing references or null errors
  • the replacement guide is complete enough that a non-programmer can swap assets

Common Failure Modes

  • placeholder names that do not match the final asset convention, causing rework on swap
  • incorrect scale that makes gameplay testing unreliable
  • missing placeholder for an entity that blocks testing of a system
  • placeholders wired into code by reference rather than by name, breaking the drop-in path

Related Agents

  • 2d-artist
  • technical-artist
  • unity-reviewer
  • godot-reviewer
  • web-reviewer

Related Commands

  • unity-placeholders
  • godot-placeholders
  • web-placeholders
  • scene-bootstrap
  • art-2d-pass

Related Skills

  • generated-raster-asset-pipeline
  • ai-asset-generation

Notes

  • Keep this skill aligned with the relevant rules layer and current project documentation.
  • If engine-specific constraints materially change the workflow, hand off to the matching engine skill or engine-specific reviewer.
  • This skill is engine-neutral. Engine-specific placeholder commands (e.g. /unity-placeholders) implement the concrete generation step using this skill's standards.
  • Tracked asymmetry: Unity, Godot, and web have concrete placeholder generation commands (/unity-placeholders plus /scene-bootstrap, /godot-placeholders, /web-placeholders), each covering 2D sprites, 3D primitives, and procedural audio. An Unreal equivalent is a deliberate pending decision, not an oversight — until it exists, apply this skill's standards manually there.
  • 3D placeholders are procedural primitives (box, sphere, capsule, plane) with one flat-color material per entity category, at correct gameplay scale with matching collision so physics, navigation, and camera framing are testable before final models exist.
  • Audio placeholders should be procedurally generated (sine waves, square waves, noise, pitch sweeps) — not silent stubs. A placeholder sound that represents the intended audio event (e.g. a rising tone for a coin collect, a short burst for a jump) makes gameplay testing far more effective than silence.
  • If placeholders are later replaced with generated raster art, hand off to generated-raster-asset-pipeline before acceptance so transparency and runtime-size issues are caught during the swap.
  • This placeholder pipeline is the DEFAULT and always-available asset path. AI generation (ai-asset-generation + /generate-assets) is an optional upgrade that only applies when a provider API key is present; when it is absent, this pipeline is the complete workflow, unchanged. Generated assets, when used, drop onto the exact names and paths produced here.

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.