Skip to content
Back to skills

Environment Kit

ASecurity

Generate a modular environment kit: walls, floor tiles, pillars, doors, arches in one visual style.

  • 77 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 16, 2026
ai-agentsgoshellnode

Works with

  • claude code
  • cursor
  • terminal
  • cli
  • mcp

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned October 16, 2026

npx -y skills add SummerEngine/summer --skill environment-kit --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Environment Kit?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Environment Kit
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/summerengine-environment-kit-summer/badge)](https://www.skillsdirectory.com/skills/summerengine-environment-kit-summer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: environment-kit
description: "Generate a modular environment kit: walls, floor tiles, pillars, doors, arches in one visual style."
license: MIT
compatibility: [Cursor, Claude Code, Windsurf, Codex]
category: 3d-assets
user-invocable: true
allowed-tools: Read Grep summer_assets_search summer_assets_get summer_import_asset_by_id summer_assets_generate_3d summer_assets_generate_image summer_import_from_url summer_add_node summer_set_prop summer_inspect_node summer_get_scene_tree summer_save_scene summer_jobs_wait summer_call
paths: ["assets/kits/**", "assets/models/**", "**/*.tscn", "**/*.gd"]
---

# Environment Kit — Style-Locked Modular Pieces

A kit is a *family* of meshes — wall, floor, door, pillar, corner, arch — that the level designer snaps together to build interiors and exteriors. The skill exists to solve **one specific failure mode**: generating each piece with a fresh prompt produces six pieces that look like they came from six different games. The fix is the **style anchor pattern** — generate one piece first, lock its prompt suffix, and reuse that exact suffix for every subsequent piece.

The backing operation is `assets.generate_3d`, called once per piece; each call answers with a job that `jobs.wait` follows. A 6-piece kit is six generations and about 5 minutes. Generation uses credits, so confirm scope before starting (`dryRun: true` on one piece's call gives its credits).

## When to use

- "Build me a dungeon kit — walls, floor, door, pillar."
- "I need modular wall pieces for a sci-fi corridor."
- "Make a tileset for a wooden tavern interior."
- "Generate the pieces for a stone temple — I'll assemble the level."
- The user wants to build a level out of repeating, snapping pieces.

## When NOT to use

- A single hero prop (single chest, single throne) → `prop-model`.
- Open-world terrain (rolling hills, forests) → use a heightmap + scattered organic models from `organic-model`.
- Repeating flat surfaces only (just walls and floors, no decorative pieces) → `asset-strategy` Pipeline 2 (textures + CSG) is cheaper and snaps perfectly to grid.
- Characters or vehicles in the scene — those are separate skills.

## The style anchor pattern

This is the whole skill. Get it right and the kit looks unified. Get it wrong and every piece is wasted.

1. **Generate the anchor piece first.** Pick the most visually defining piece — usually the wall or the door. Iterate the prompt until the user approves it visually.
2. **Extract the style suffix.** Everything after the object description. Example anchor prompt:
   ```
   A stone dungeon wall section, mossy granite blocks with iron reinforcements, 
   torch-bracket sconce, weathered surface. Game asset, centered, stylized 
   low-poly game art, warm torchlight palette, white background, isolated object.
   ```
   The suffix to lock is everything from `Game asset, ...` onward, plus `mossy granite blocks with iron reinforcements, weathered surface, warm torchlight palette` — the material + palette tokens.
3. **Reuse the suffix verbatim** for every other piece. Only change the object description at the front.

| Anchor: wall | `A stone dungeon wall section, ...` + LOCKED SUFFIX |
| Floor tile | `A stone dungeon floor tile, square, ...` + SAME LOCKED SUFFIX |
| Pillar | `A stone dungeon pillar, square base, fluted shaft, ...` + SAME LOCKED SUFFIX |
| Door | `A stone dungeon doorway, arched, heavy wooden door with iron studs, ...` + SAME LOCKED SUFFIX |
| Corner block | `A stone dungeon corner wall section, two walls joined at right angle, ...` + SAME LOCKED SUFFIX |
| Arch | `A stone dungeon archway with keystone, ...` + SAME LOCKED SUFFIX |

If the user says "the door doesn't match the rest", the answer is almost always: the suffix drifted. Check the exact strings.

## Snap-grid alignment

Kit pieces only feel modular if they snap to a fixed grid. Pick the grid before generating and tell the user.

| Grid size | Use for | Notes |
|---|---|---|
| **1m** | Tight interiors (dungeons, ship corridors, cells) | Wall = 1×3×0.3m. Floor = 1×1m. Most common. |
| **2m** | Standard interiors (homes, taverns, offices) | Wall = 2×3×0.3m. Floor = 2×2m. Halves piece count. |
| **4m** | Exteriors and large halls (temples, warehouses, throne rooms) | Wall = 4×4×0.4m. Floor = 4×4m. Quarter the piece count for the same area. |

**Critical:** include the dimensions in the prompt. `assets.generate_3d` doesn't enforce them, but Hunyuan respects scale cues — `2 meter tall wall section` produces a mesh that imports near 2m tall. Then verify with `summer_inspect_resource` and scale-correct in the editor if needed.

## Steps

### 1. Confirm scope and pick the grid

> About to build a dungeon kit. Suggested pieces: wall, floor, pillar, door, corner, arch (6 generations, ~5 min). Snap grid: 2m (standard interior). OK?

### 2. Generate the anchor (wall)

Use the prop-style prompt with explicit dimensions:

```
assets.generate_3d({
  prompt: "A 2 meter wide by 3 meter tall stone dungeon wall section, mossy granite blocks with iron reinforcements, torch-bracket sconce, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object.",
  model: "hunyuan",
  targetPolycount: 1500
})
jobs.wait({ jobId: "<job.id>", timeoutSeconds: 50 })   // again until finished; result.assetId
assets.get({ assetId: "<assetId>" })
summer_import_asset_by_id(assetId="<assetId>", path="res://assets/kits/dungeon/wall.glb")
```

Show the result to the user. **Iterate the anchor until approved** — every other piece copies its style.

### 3. Lock the suffix and generate the remaining pieces

Once the user says "yes, that's the look", store the locked suffix and crank through the rest. Same model, same `targetPolycount` scale. Only the object description changes. Start every piece first, then wait on the jobs: they run side by side.

```
# Floor
assets.generate_3d({ prompt: "A 2 by 2 meter square stone dungeon floor tile, mossy granite blocks with iron reinforcements, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object.", model: "hunyuan", targetPolycount: 800 })

# Pillar
assets.generate_3d({ prompt: "A 3 meter tall stone dungeon pillar, square base, fluted shaft, mossy granite blocks with iron reinforcements, weathered surface. Game asset, ...", model: "hunyuan", targetPolycount: 1500 })

# Door, Corner, Arch — same pattern. Then jobs.wait on each job id.
```

For each finished job, capture the returned `assetId`, then import that
exact ID with `summer_import_asset_by_id`. Do not search for generated pieces by
name after creating them; exact IDs are the production path.

Polycount targets per kit piece: walls/floors 800–1500 tris (placed dozens of times), decorative (pillar, arch) 1500–3000, doors 2000–3000.

### 4. Import and stage in a kit scene

Don't dump the kit into the level scene. Make a `kit_dungeon.tscn` that holds one of every piece, labelled, positioned next to each other on the snap grid. The level designer instantiates from there.

```
summer_instantiate_scene(scenePath="res://assets/kits/dungeon/kit_dungeon.tscn", parent="./KitRoot", scene="res://assets/kits/dungeon/wall.glb", name="Wall")
summer_set_prop(scenePath="res://assets/kits/dungeon/kit_dungeon.tscn", path="./KitRoot/Wall", key="position", value="Vector3(0, 0, 0)")
# ...repeat for floor, pillar, door, corner, arch with positions Vector3(2,0,0), Vector3(4,0,0), ...
summer_save_scene(scenePath="res://assets/kits/dungeon/kit_dungeon.tscn")
```

Three things the shape of those calls encodes:

- **A `.glb` is instantiated, not assigned.** There is no `scene` property on `Node3D`, and an imported `.glb` is a scene, not a `Mesh` — `ResourceLoader.get_recognized_extensions_for_type("Mesh")` on the shipped 4.6.1 binary returns `["tres", "mesh", "res"]`, with no `glb`. Use `summer_instantiate_scene`, which adds the model as a child in one op.
- **Every scene-mutating tool takes an explicit `scenePath`**, and node paths are relative to that scene's root (`./`).
- **`summer_set_prop`'s property argument is named `key`**, not `property`.

### 5. Verify scale and pivots

```
summer_inspect_resource(path="res://assets/kits/dungeon/wall.glb")
```

Check the AABB. If the wall is 1.85m tall when you asked for 3m, scale it in the editor (or re-import with `Scale` in the import dock). Pivots should sit at the *bottom-back* corner for walls and *bottom-center* for floors — that makes snapping to a 2m grid trivial. If pivots are wrong, use the "Center to Origin" import option.

## Anti-patterns

- **Drifting style suffix.** Each piece gets a slightly different suffix → the kit looks mismatched. Copy-paste the exact string.
- **Different polycount per piece.** A 5k-tri pillar next to a 500-tri wall reads as "the pillar is a hero piece" — wrong; they should feel like equal kit citizens. Match polycount within ~2× across the kit.
- **Skipping the anchor approval.** If you generate all six pieces in a batch, you bake in whatever the first call's interpretation of the style was — and the user may hate it after six generations.
- **Generating walls / floors as individual meshes when you only need a tileable texture.** A flat wall section is cheaper as a textured `CSGBox3D`. Reserve the kit for pieces that need actual geometric detail (sconces, mouldings, doorways, arches).
- **No scale cue in the prompt.** Wall comes back 0.4m tall. Always include `2 meter wide by 3 meter tall` (or your chosen grid).
- **Forgetting the snap grid.** A 1.87m-tall wall with no scale fix → level looks crooked when tiled.

## Edge cases

- **Curved or organic kit (cave, alien hive).** Modular geometry resists snapping. Generate longer pieces (4m walls, transition tiles) and accept some overlap. Or switch to procedural — `design-level` can scatter cave pieces with rotation jitter.
- **Outdoor kit (cliffs, ruins, forest path).** Use the kit pattern but accept rotation/jitter at placement time. Mesh edges should fade naturally rather than snap cleanly. Pair with `organic-model` for foliage scatter.
- **Sci-fi kit (corridors, doors, terminals).** The style suffix becomes critical — `clean panels, soft cyan emissive trim, brushed metal, white background, isolated object`. Hard surfaces drift more than organic ones; review every piece.
- **The user wants to add a piece later.** The locked suffix lives in the kit's notes (drop it in `assets/kits/dungeon/STYLE.md` if the user wants persistence). Reuse it verbatim for any addition — never re-derive.

## Without Summer Engine

In a session without Summer Engine tools (the assets profile; the `summer-assets` skill has the whole loop), do steps 1-3 and skip steps 4-5 (staging in a kit scene). Save the file where the person asked with `out` (the `summer-assets` skill says how), and tell them the path and format. Tell the person the grid from step 1, so they can check scale and pivots in their own engine.

## Fallback (no MCP)

1. Run each prompt at the Summer dashboard (or Hunyuan / Trellis web UIs), keeping the locked suffix.
2. Download each `.glb`.
3. Drop into `res://assets/kits/<kit-name>/`.
4. Build the kit-display scene manually in Summer Engine, with one of each piece
   snapped to the grid.
5. Hand to the level designer.

## Handoff

After the kit is staged:

> Dungeon kit ready: `res://assets/kits/dungeon/` with wall, floor, pillar, door, corner, arch on a 2m snap grid. Display scene at `res://assets/kits/dungeon/kit_dungeon.tscn`.
>
> Next: hand off to the level-design step — instantiate kit pieces into `level_01.tscn`, snap to the 2m grid, dress with props (`prop-model`) and foliage (`organic-model`). For lighting, see `3d-lighting`.

## See also

- `prop-model` — for the chests, statues, and decorative props that dress the kit.
- `organic-model` — for foliage and rocks that break up modular repetition.
- `asset-strategy` — Pipeline 2 (textures + CSG) is the cheaper alternative when pieces are flat.
- `scene-composition` — how to organize the kit scene and the level scenes that consume it.
- `3d-lighting` — interior kit pieces typically need warm point lights at sconce positions.

<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
## From a shell

No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@4.3.0` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.

| In this skill | Command |
|---|---|
| `assets.generate_3d`, `summer_assets_generate_3d` | `summer assets generate-3d` |
| `summer_assets_generate_image` | `summer assets generate-image` |
| `summer_assets_get` | `summer assets get` |
| `summer_assets_search` | `summer assets search` |
| `summer_add_node` | `summer engine add-node` |
| `summer_get_scene_tree` | `summer engine get-scene-tree` |
| `summer_import_asset_by_id` | `summer engine import-asset-by-id` |
| `summer_import_from_url` | `summer engine import-from-url` |
| `summer_inspect_node` | `summer engine inspect-node` |
| `summer_inspect_resource` | `summer engine inspect-resource` |
| `summer_instantiate_scene` | `summer engine instantiate-scene` |
| `summer_save_scene` | `summer engine save-scene` |
| `summer_set_prop` | `summer engine set-prop` |
| `jobs.wait`, `summer_jobs_wait` | `summer jobs wait` |
<!-- /shell-commands -->

Files in this skill

  • SKILL.md13.4 KB
  • resource.yaml753 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.