@genex-ai/cli-demo 0.1.0

package/templates/skills/genex-threejs-bloom/references/bloom.md

@@ -0,0 +1,29 @@
+# Bloom
+
+Use this reference for controlled glow in Genex games.
+
+## Signal ownership
+
+- Establish whether bloom comes from HDR thresholding, selection layers, or both.
+- Keep tone mapping after bloom composition.
+- Keep exposure changes from unpredictably destroying bloom intent.
+
+## Selective bloom
+
+- Use layers, masks, or a separate render pass.
+- Restore material state after rendering a selected pass.
+- Avoid duplicate contribution from the same object.
+- Keep selected objects documented.
+
+## Blur levels
+
+- Small radius: sharp energy and UI-like highlights.
+- Medium radius: glow around light sources.
+- Large radius: atmosphere or spectacle.
+- Keep each level inspectable.
+
+## Failure checks
+
+- Bloom cannot carry the silhouette alone.
+- White UI or text should not bloom unless intentionally emissive.
+- Dark scenes should not become foggy because bloom strength is too high.

package/templates/skills/genex-threejs-camera-direction/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: genex-threejs-camera-direction
+description: Design advanced Three.js camera systems for Genex browser games. Use for chase cameras, orbit cameras, side cameras, authored shots, pointer-look controls, scale-aware offsets, collision constraints, camera handoffs, projection ownership, large-world precision, and lifecycle cleanup.
+---
+
+# Genex Three.js Camera Direction
+
+Treat the camera as part of the game design, not a passive viewport. It must
+explain scale, support the player verb, and survive mode changes.
+
+Read [references/camera-rigs.md](references/camera-rigs.md) for concrete rig
+patterns, handoff rules, and browser checks.
+
+## Build order
+
+1. Define subject size, play distance, screen occupancy, lens, near/far planes,
+   input mode, and up-axis convention.
+2. Choose semantic camera frames: player body, vehicle, track, planet normal,
+   arena center, or authored shot marker.
+3. Compute target position and orientation separately, then compose the final
+   camera transform once.
+4. Add orbit, chase, side, or pointer-look constraints around the chosen frame.
+5. Use frame-rate-independent smoothing for follow motion; avoid stacked
+   smoothing during explicit transitions.
+6. Snapshot and restore projection, controls, and ownership when scenes mount or
+   dispose.
+
+## Rules
+
+- Derive distances from subject bounds; do not hard-code one offset for every
+  game object.
+- Use `lerp` for positions and `slerp` for orientations.
+- Re-sync yaw and pitch from the active camera when pointer lock is acquired.
+- Update projection matrices after FOV, near, far, or aspect changes.
+- Keep infinite backgrounds camera-relative in large worlds.
+- Validate resize, pointer-lock recovery, mode transitions, and collision edges.

package/templates/skills/genex-threejs-camera-direction/references/camera-rigs.md

@@ -0,0 +1,38 @@
+# Camera Rigs
+
+Use these patterns when a Genex scene needs authored camera behavior.
+
+## Chase camera
+
+- Base the offset on the controlled object's bounding sphere.
+- Track a target point slightly ahead of the object, not only its origin.
+- Smooth position with an exponential factor based on `deltaTime`.
+- Smooth orientation separately so fast direction changes do not roll the view.
+- Clamp pitch and distance so the player cannot bury the camera in geometry.
+
+## Orbit camera
+
+- Store yaw, pitch, and distance as explicit state.
+- Clamp pitch before deriving the spherical offset.
+- Recompute the target from the game object each frame.
+- Disable or reduce damping during scripted handoffs.
+
+## Side or authored shot
+
+- Define shot anchors in scene space or subject-relative space.
+- Keep screen occupancy stable across subject scale changes.
+- Blend only one transition source at a time.
+- Expose a debug view showing target point, camera point, and frustum.
+
+## Pointer look
+
+- On lock acquisition, derive yaw and pitch from the current camera quaternion.
+- Apply pointer deltas to yaw/pitch state, then rebuild the quaternion.
+- Release cleanly on escape, tab changes, and scene disposal.
+
+## Large worlds
+
+- Use a floating origin or camera-relative background for scenes with very large
+  coordinates.
+- Keep stars, sky domes, and infinite grids from translating in ways that imply
+  false parallax.

package/templates/skills/genex-threejs-exposure-color-grading/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: genex-threejs-exposure-color-grading
+description: Build exposure and color grading for Genex Three.js games. Use for luminance metering, eye adaptation, tone mapping ownership, LUT-style grading, scene-referred color, output color spaces, mood passes, and final image consistency across gameplay lighting.
+---
+
+# Genex Three.js Exposure And Color Grading
+
+Exposure and grading are final image controls. Use them to preserve readability
+across gameplay, not to fix broken lighting.
+
+Read [references/exposure-grading.md](references/exposure-grading.md) for
+metering, tone mapping, LUTs, and validation.
+
+## Build order
+
+1. Confirm render color space, tone-mapping owner, and output transform.
+2. Define target luminance range and adaptation speed.
+3. Meter luminance from an intentionally downsampled or sampled source.
+4. Apply exposure before tone mapping.
+5. Apply grading after tone mapping if using a display-style LUT.
+6. Expose debug views for luminance, exposure, tone map, LUT, and final output.
+
+## Rules
+
+- Use one tone-mapping owner.
+- Keep adaptation asymmetric if bright-to-dark and dark-to-bright need different
+  response.
+- Avoid grading that hides gameplay colors or UI states.
+- Validate bright, dark, indoor, outdoor, and VFX-heavy moments.
+- Document known artistic compromises.

package/templates/skills/genex-threejs-exposure-color-grading/references/exposure-grading.md

@@ -0,0 +1,30 @@
+# Exposure And Color Grading
+
+Use this reference for final image response.
+
+## Metering
+
+- Downsample luminance or sample a stable set of pixels.
+- Use log-average luminance for robust exposure.
+- Ignore or reduce weighting for UI and transient VFX when they should not drive
+  exposure.
+- Clamp exposure range.
+
+## Adaptation
+
+- Use different speeds for brightening and darkening when useful.
+- Smooth by `deltaTime`.
+- Reset or seed exposure intentionally on scene transitions.
+
+## Tone mapping
+
+- Choose one tone mapping stage.
+- Place bloom before tone mapping.
+- Place display grading after tone mapping unless the project has a specific
+  scene-referred grading path.
+
+## Grading
+
+- Keep gameplay-critical colors distinguishable.
+- Provide a neutral grade toggle.
+- Validate captures on multiple scene lighting states.

package/templates/skills/genex-threejs-image-pipeline/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: genex-threejs-image-pipeline
+description: Design the final image pipeline for Genex Three.js games. Use for render-target ownership, depth and normal signals, albedo/history buffers, pass ordering, post-processing composition, AO, bloom, exposure, tone mapping, grading, diagnostics, and avoiding conflicting render effects.
+---
+
+# Genex Three.js Image Pipeline
+
+Own the frame deliberately. Advanced effects fail when every pass invents its
+own depth, color, history, or tone mapping path.
+
+Read [references/image-pipeline.md](references/image-pipeline.md) for pass
+ordering, signal ownership, diagnostics, and cleanup.
+
+## Build order
+
+1. Inventory the frame: scene color, depth, normals, velocity/history, masks,
+   transparency, UI, and output.
+2. Assign one owner for each shared signal.
+3. Order passes from geometry signals to lighting support to final image.
+4. Keep tone mapping and output color at the end.
+5. Add per-pass debug views and no-post baseline.
+6. Dispose render targets and composers on resize or scene teardown.
+
+## Rules
+
+- Do not let each effect render its own incompatible depth or normal pass.
+- Keep UI composition separate from world post-processing unless intentional.
+- Make DPR and resize behavior explicit.
+- Track render-target count, resolution, and memory.
+- Validate pass order by toggling each effect.

package/templates/skills/genex-threejs-image-pipeline/references/image-pipeline.md

@@ -0,0 +1,39 @@
+# Image Pipeline
+
+Use this reference when a Genex game has multiple render passes.
+
+## Typical pass order
+
+1. Main scene signals: color, depth, normals, masks.
+2. Lighting support: shadows, AO, reflections, volumetrics.
+3. Screen-space effects: refraction, temporal masks, distortion.
+4. HDR effects: bloom and other emission-based contributions.
+5. Exposure and tone mapping.
+6. Color grading.
+7. UI and presentation overlays.
+
+## Shared signals
+
+- Depth: document projection and encoding.
+- Normals: document space and packing.
+- Color: document linear/HDR/display state.
+- History: document reset and reprojection rules.
+- Masks: document semantic meaning and lifetime.
+
+## Diagnostics
+
+Provide a pass inspector or simple toggles for:
+
+- no-post scene;
+- depth;
+- normals;
+- masks;
+- AO;
+- bloom source and result;
+- exposure;
+- final output.
+
+## Cleanup
+
+Resize render targets on canvas changes. Dispose render targets, materials,
+geometries, and composers when leaving the scene.

package/templates/skills/genex-threejs-procedural-animation/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: genex-threejs-procedural-animation
+description: Build procedural animation systems for Genex Three.js games. Use for analytic timelines, launch arcs, loops, staging, docking, springs, vehicle lag, rotating frames, debris motion, transform phases, quaternion alignment, and frame-rate-independent motion.
+---
+
+# Genex Three.js Procedural Animation
+
+Use deterministic motion systems that can be replayed, tuned, and synchronized.
+Animation should support gameplay clarity before it adds spectacle.
+
+Read [references/procedural-motion.md](references/procedural-motion.md) for
+timeline, spring, rotating-frame, and debris patterns.
+
+## Build order
+
+1. Define the motion contract: start/end state, duration, loop policy, gameplay
+   meaning, and interrupt behavior.
+2. Use analytic time or explicit simulation state; avoid hidden wall-clock
+   dependencies.
+3. Split position, orientation, scale, and material animation into named phases.
+4. Use quaternion alignment for moving frames and docking-style orientation.
+5. Use damped springs only where inertia is intended.
+6. Expose debug controls for pause, time scale, phase, seed, and loop reset.
+
+## Rules
+
+- Advance animation with `deltaTime`; never assume a fixed frame rate.
+- Keep random variation seeded and reproducible.
+- Prefer one clear motion cause over several unrelated noise offsets.
+- Make restart, pause, scene disposal, and replay deterministic.
+- Keep gameplay-critical state separate from purely visual offsets.

package/templates/skills/genex-threejs-procedural-animation/references/procedural-motion.md

@@ -0,0 +1,33 @@
+# Procedural Motion
+
+Use this reference for authored real-time motion in Genex games.
+
+## Analytic timelines
+
+- Normalize timeline progress to `t` in `[0, 1]`.
+- Apply named easing functions per phase.
+- Derive all animated properties from the same normalized phase when they must
+  stay synchronized.
+- Record phase names in debug output so screenshots can be interpreted.
+
+## Springs
+
+- Use springs for pursuit, vehicle lag, recoil, camera follow, or UI-like
+  physical response.
+- Keep spring constants in named parameters.
+- Clamp extreme `deltaTime` after tab resumes.
+- Snap to target when distance and velocity fall below a threshold.
+
+## Rotating frames
+
+- For docking, orbit, or planet-relative scenes, define the moving frame first.
+- Convert local target axes to world axes each frame.
+- Slerp orientation toward the target quaternion.
+- Avoid mixing Euler interpolation with quaternion alignment.
+
+## Debris and secondary motion
+
+- Generate seeded velocity, angular velocity, lifetime, and drag.
+- Use object pools for many particles or fragments.
+- Remove or recycle expired fragments deterministically.
+- Keep collision or damage state separate from decorative debris.

package/templates/skills/genex-threejs-procedural-architecture/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: genex-threejs-procedural-architecture
+description: Create procedural architecture for Genex Three.js games. Use for buildings, modular kits, facade grammars, exposed-edge analysis, bay systems, roofs, arches, ornaments, city blocks, collision proxies, material-slot compilation, and readable architecture at gameplay distance.
+---
+
+# Genex Three.js Procedural Architecture
+
+Architecture should communicate function, scale, traversal, and affordance. Use
+grammars that emit semantic parts rather than arbitrary boxes.
+
+Read [references/architecture-systems.md](references/architecture-systems.md)
+for massing, facade rules, module compilation, and gameplay checks.
+
+## Build order
+
+1. Define gameplay role: backdrop, obstacle, climbable surface, interior shell,
+   landmark, cover, or arena boundary.
+2. Build massing volumes and exposed edges.
+3. Apply facade grammar by face orientation, floor band, corner, and entrance.
+4. Emit material slots and collision proxies separately from decorative meshes.
+5. Add detail only where camera distance supports it.
+6. Expose debug views for modules, floors, entrances, collision, and LOD.
+
+## Rules
+
+- Keep doors, ledges, stairs, and openings aligned with player scale.
+- Use repeated modules deliberately; break repetition with semantic variation.
+- Do not spend triangle budget on invisible internal faces.
+- Keep material slots stable so generated variants can share assets.
+- Validate collision and navigation against the visual promise.

package/templates/skills/genex-threejs-procedural-architecture/references/architecture-systems.md

@@ -0,0 +1,31 @@
+# Architecture Systems
+
+Use this guide for authored procedural buildings and city pieces.
+
+## Massing
+
+- Start with readable volumes.
+- Mark exposed faces and hidden faces.
+- Identify corners, roof lines, ground contact, entrances, and traversal edges.
+- Keep player scale visible through doors, windows, railings, or props.
+
+## Facade grammar
+
+- Split faces into floor bands and bay columns.
+- Assign modules by semantic role: entrance, window, blank wall, balcony, trim,
+  corner, roof, and service detail.
+- Compile repeated modules into shared geometry where possible.
+- Keep material groups stable across variants.
+
+## Gameplay
+
+- Generate simple collision proxies.
+- Keep navigable gaps wide enough for the controller.
+- Avoid decorative protrusions that snag movement unless they are intentional.
+- Expose landmarks and silhouettes for orientation.
+
+## Budgets
+
+- Use instancing for repeated windows, trims, and panels.
+- Collapse background buildings to simpler facades.
+- Add close-up ornaments only where inspection distance requires them.

package/templates/skills/genex-threejs-procedural-fields/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: genex-threejs-procedural-fields
+description: Create coherent procedural scalar and vector fields for Genex Three.js games. Use for terrain, masks, biome maps, water influence, cloud density, material variation, displacement, wear, normals, domain warping, and visuals where multiple channels need a shared cause.
+---
+
+# Genex Three.js Procedural Fields
+
+Use fields to make generated visuals feel caused rather than layered. A field
+can drive geometry, materials, particles, sound hooks, and gameplay affordances.
+
+Read [references/field-systems.md](references/field-systems.md) for field
+stacks, masks, warping, and diagnostics.
+
+## Build order
+
+1. Define the domain: world, object, planet, UV, screen, or simulation space.
+2. Choose base fields with named frequency bands.
+3. Add domain warping only after the unwarped structure reads.
+4. Derive masks, normals, roughness, color, density, and displacement from
+   shared field causes.
+5. Expose debug views for each important field and mask.
+6. Keep seed, scale, amplitude, and thresholds explicit.
+
+## Rules
+
+- Do not stack unrelated noise until the result looks detailed.
+- Keep units stable across camera distance and object scale.
+- Derive normals from the same height or density field used for displacement.
+- Use causal masks: wetness should follow water, scorch should follow impact,
+  and snow should follow slope/exposure.
+- Clamp, remap, and document field ranges before feeding shaders.

package/templates/skills/genex-threejs-procedural-fields/references/field-systems.md

@@ -0,0 +1,35 @@
+# Field Systems
+
+Use this guide to build reusable fields for Genex scenes.
+
+## Field stack
+
+- `base`: low-frequency silhouette or terrain structure.
+- `detail`: mid-frequency material and shape variation.
+- `micro`: high-frequency normals or roughness, filtered by distance.
+- `mask`: semantic influence such as water, biome, damage, snow, or wear.
+- `flow`: vector direction for wind, particles, waves, or erosion.
+
+## Domain rules
+
+- World-space fields should not swim when objects move.
+- Object-space fields should travel with the mesh.
+- UV-space fields should be reserved for authored assets or atlases.
+- Screen-space fields should never drive persistent world identity.
+
+## Diagnostics
+
+Expose a way to render:
+
+- raw field values;
+- threshold masks;
+- gradient or normal direction;
+- warped versus unwarped domains;
+- seed variations;
+- near and far camera views.
+
+## Performance
+
+- Share field functions between CPU generation and shader paths when possible.
+- Cache generated textures that do not change every frame.
+- Use lower resolution or fewer octaves for far-distance fields.

package/templates/skills/genex-threejs-procedural-geometry/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: genex-threejs-procedural-geometry
+description: Build procedural mesh systems for Genex Three.js games. Use for mesh writers, profile sweeps, rails, branches, frames, collision-aware shapes, UV density, custom normals, material groups, instancing decisions, and geometry that must hold up to close gameplay inspection.
+---
+
+# Genex Three.js Procedural Geometry
+
+Procedural geometry should have semantic structure, stable normals, and a clear
+budget. Build mesh writers that explain what they emit.
+
+Read [references/mesh-systems.md](references/mesh-systems.md) for profile
+sweeps, mesh writers, normals, UVs, and validation.
+
+## Build order
+
+1. Define semantic parts and gameplay purpose before vertices.
+2. Choose topology: instanced primitives, merged mesh, skinned mesh, or custom
+   buffer geometry.
+3. Emit positions, normals, UVs, indices, material groups, and bounds together.
+4. Keep resolution tied to screen distance or gameplay importance.
+5. Generate collision/proxy geometry separately when needed.
+6. Add debug modes for wireframe, normals, groups, UV density, and bounds.
+
+## Rules
+
+- Avoid procedural meshes with unnamed arrays and no semantic parts.
+- Keep winding, normals, and tangent expectations consistent.
+- Use material groups deliberately; do not create one material per tiny piece.
+- Recompute bounds after generated changes.
+- Dispose old geometries and materials on regeneration.

package/templates/skills/genex-threejs-procedural-geometry/references/mesh-systems.md

@@ -0,0 +1,36 @@
+# Mesh Systems
+
+Use this guide for reusable procedural mesh writers.
+
+## Mesh writer contract
+
+A mesh writer should declare:
+
+- input seed and parameters;
+- emitted semantic parts;
+- vertex and triangle budget;
+- material slots;
+- UV convention;
+- bounds and collision proxy behavior;
+- regeneration and disposal policy.
+
+## Profile sweeps
+
+- Define a 2D profile with named control points.
+- Sweep along a path with stable tangent, normal, and binormal frames.
+- Add caps intentionally.
+- Keep UV length proportional to world distance.
+- Expose cross-section debug lines.
+
+## Normals and UVs
+
+- Use smooth normals for organic forms and split normals for hard surfaces.
+- Avoid accidental smoothing across material or silhouette seams.
+- Keep UV density consistent across parts that share a material.
+- Validate mirrored or repeated UV islands against normal maps.
+
+## Instancing
+
+Use instancing when many pieces share geometry and material. Avoid instancing
+when each piece needs unique topology, unique material state, or separate
+collision behavior that dominates the cost.

package/templates/skills/genex-threejs-procedural-materials/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: genex-threejs-procedural-materials
+description: Author production procedural materials for Genex Three.js games. Use for PBR identity, terrain materials, atlas filtering, specular anti-aliasing, wetness, biome surfaces, dissolves, procedural normals, roughness variation, and readable materials across gameplay distances.
+---
+
+# Genex Three.js Procedural Materials
+
+Materials should communicate object identity, state, and gameplay affordance.
+Build them from shared fields and inspectable parameters.
+
+Read [references/material-systems.md](references/material-systems.md) for PBR
+roles, filtering, masks, and shader handoff patterns.
+
+## Build order
+
+1. Define material identity: base color family, metalness, roughness, normal
+   scale, edge wear, and gameplay state.
+2. Choose field causes for variation before writing shader code.
+3. Derive color, roughness, normals, wetness, and emission from named masks.
+4. Add distance-aware filtering for micro detail.
+5. Keep a no-post preview where the material still reads.
+6. Expose debug toggles for albedo, roughness, normals, masks, and emission.
+
+## Rules
+
+- Do not rely on bloom or grading to make a weak material interesting.
+- Keep roughness variation physically plausible for the object.
+- Filter high-frequency normals and atlas lookups to reduce shimmer.
+- Treat emission as authored signal, not a blanket glow.
+- Make damage, wetness, heat, or dissolve follow a stable mask.

package/templates/skills/genex-threejs-procedural-materials/references/material-systems.md

@@ -0,0 +1,31 @@
+# Material Systems
+
+Use this reference when building procedural materials for Genex games.
+
+## PBR roles
+
+- Base color carries identity and broad variation.
+- Roughness controls highlight size and material age.
+- Metalness should usually be binary or near-binary by surface type.
+- Normals add shape detail but should not replace silhouette.
+- Emission should have a scene-relative intensity hierarchy.
+
+## Filtering
+
+- Fade micro normals with distance.
+- Use mip-aware texture sampling for generated atlases.
+- Reduce specular aliasing on tiny bright details.
+- Avoid unbounded high-frequency noise in motion.
+
+## Common masks
+
+- Wetness: driven by water height, splash, or exposed low points.
+- Wear: driven by edges, contact, pathing, or gameplay interaction.
+- Heat: driven by event timelines and cooling curves.
+- Dissolve: driven by a stable object-space or authored field.
+- Biome: driven by altitude, slope, latitude, moisture, or gameplay zones.
+
+## Debug views
+
+Provide direct views of base color, roughness, normals, mask values, emission,
+and final lit material before post-processing.

package/templates/skills/genex-threejs-procedural-planets/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: genex-threejs-procedural-planets
+description: Author procedural planets for Genex Three.js games. Use for spherical terrain, continents, ridges, craters, biome masks, coastlines, altitude detail, orbit-to-surface transitions, planet-relative cameras, material variation, and playable planetary bodies.
+---
+
+# Genex Three.js Procedural Planets
+
+Planets must hold up across extreme scale changes. Build shared terrain,
+material, atmosphere, and camera rules around one planet contract.
+
+Read [references/planet-systems.md](references/planet-systems.md) for terrain
+fields, LOD, materials, and orbit-to-surface checks.
+
+## Build order
+
+1. Define radius, gravity/up convention, playable altitude range, camera envelope,
+   and target quality tiers.
+2. Build low-frequency continent and elevation fields.
+3. Add ridges, craters, erosion bands, biome masks, and coastline rules.
+4. Derive normals, material masks, and gameplay zones from the same fields.
+5. Add atmosphere and clouds only after terrain readability is stable.
+6. Expose debug views for elevation, slope, biome, coast, normal, and LOD.
+
+## Rules
+
+- Use planet-relative up vectors for cameras, actors, and placement.
+- Keep procedural detail stable between orbit and close approach.
+- Filter altitude detail by camera distance and surface scale.
+- Avoid unrelated noise layers that break geological cause.
+- Make spawn points, traversal zones, and hazards serializable by seed.

package/templates/skills/genex-threejs-procedural-planets/references/planet-systems.md

@@ -0,0 +1,30 @@
+# Planet Systems
+
+Use this reference for spherical worlds in Genex games.
+
+## Terrain fields
+
+- Base elevation: continents, basins, and major silhouettes.
+- Structural detail: ridges, faults, crater rims, erosion lines.
+- Surface masks: water, snow, biome, rock, sand, city, hazard.
+- Normals: derived from the elevation field, not unrelated texture noise.
+
+## Orbit-to-surface LOD
+
+- Use lower-frequency geometry from orbit.
+- Add displacement and material detail as the camera approaches.
+- Keep coastlines, large craters, and landmarks stable across LOD boundaries.
+- Use debug captures at orbit, high altitude, gameplay altitude, and close view.
+
+## Gameplay
+
+- Store seeds and planet parameters in serializable config.
+- Derive spawn zones from slope, altitude, biome, and hazard masks.
+- Keep planet-relative controls and camera up vectors consistent.
+- Separate visual tessellation from gameplay collision when necessary.
+
+## Rendering
+
+- Add atmosphere after terrain material masks are readable.
+- Keep clouds in a separate layer with independent quality controls.
+- Use exposure and aerial perspective to explain scale without hiding terrain.

package/templates/skills/genex-threejs-procedural-vegetation/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: genex-threejs-procedural-vegetation
+description: Generate procedural vegetation for Genex Three.js games. Use for trees, trunks, roots, recursive branches, canopies, leaf cards, grass clumps, species presets, deterministic variation, growth forces, wind deformation, and vegetation that supports navigation or scene readability.
+---
+
+# Genex Three.js Procedural Vegetation
+
+Vegetation should read as a species with structure, not as random cylinders and
+leaf sprites. Build growth rules that support gameplay scale and navigation.
+
+Read [references/vegetation-systems.md](references/vegetation-systems.md) for
+branching, foliage, wind, placement, and budgets.
+
+## Build order
+
+1. Define species silhouette, height range, trunk character, canopy density, and
+   gameplay role.
+2. Generate trunk, roots, primary branches, secondary branches, and foliage as
+   separate semantic parts.
+3. Use seeded growth forces: upward bias, light seeking, gravity, spread, and
+   obstacle avoidance.
+4. Place foliage with stable normals, density masks, and LOD behavior.
+5. Add wind after static form reads.
+6. Expose debug views for hierarchy, branch radius, foliage density, and wind.
+
+## Rules
+
+- Keep branching deterministic for a given seed.
+- Do not let leaf cards carry the entire silhouette at close range.
+- Use lower geometry density for background vegetation.
+- Keep collision/navigation proxies simpler than visual meshes.
+- Make wind hierarchical: trunk slow, branches medium, leaves fast.