| name | prefab-authoring |
| description | Use when creating reusable gameplay objects or scene presets so prefabs stay declarative, configurable, and ready for future tooling such as previews and scanned catalogs. |
Prefab Authoring
Use this skill when adding reusable scene objects, pickups, obstacles, props, spawnable entities, or authored content presets.
Read First
docs/prefab-authoring.md
docs/generated/project-structure.md
docs/generated/state-and-rendering.md if the prefab introduces hot runtime behavior
Contract Rule
A prefab should be a reusable content unit, not a hidden pile of gameplay logic.
Keep the prefab definition declarative and stable enough that future tooling can:
- scan it
- render a preview
- expose safe config
- instantiate it consistently
Structure Rules
- place prefab code under
src/game/prefabs/
- keep metadata, schema, and runtime component clearly separated
- put pure behavior in domain/system modules when it outgrows the prefab itself
- avoid coupling prefab definitions directly to scene-global mutable state
- keep scene-population, spawn, and pooling layers outside
src/game/prefabs/
Config Rules
- expose explicit defaults
- keep config serializable where practical
- use stable ids, labels, categories, and tags
- avoid hidden magic props or implicit scene dependencies
Anti-Patterns
- one-off scene objects masquerading as reusable prefabs
- prefab files that bury behavior, metadata, and config in one component
- prefab placement rules that depend on trial-and-error offsets
- prefab contracts that are too ad hoc for future scanning or preview generation
- plural runtime mappers like
Ships or Collectibles living in src/game/prefabs/ when they are actually population layers over state