/tileset

name: tileset
description: Generate a fixed-profile terrain atlas and compile it into a native Godot TileSet. Use for reusable terrain libraries, never for designing a TileMap.

TileSet Asset Skill

Produce one reusable square TileSet from a real source atlas. This production path supports hand-painted, illustrated, or rendered terrain art. It is standalone: direct callers use the same request and result contract as callers higher in the pipeline.

Contract

Read and enforce `.godotmaker/asset-runtime/asset-skill-contract.md` and `schema/request.schema.json`. Read the caller input from the canonical `.godotmaker/asset-generation/<asset_id>-request.json`. Accept only `asset_type: "tileset"`, a stable `asset_id`, a concise `brief`, optional visible art references, and the typed family `spec`. The caller never supplies output paths, compiler recipes, profile coordinates, or processing commands. Return the deterministic runtime result at `.godotmaker/asset-generation/<asset_id>-result.json`:

{
  "asset_type": "tileset",
  "outputs": [{"role": "runtime", "path": "res://assets/generated/tileset/<asset_id>/<asset_id>.tres", "godot_type": "TileSet"}],
  "sources": [{"path": "res://assets/generated/tileset/<asset_id>/<asset_id>_atlas.png", "layout": "tile_atlas"}],
  "previews": [],
  "validation": {"passed": true, "levels": {"L0": true, "L1": true, "L2": true, "L3": true, "L4": true}}
}

Do not read or require tags, stage state, `ASSETS.md`, either generated manifest, or any `/gm-asset` mode. Do not register outputs or decide worker dispatch. Those are caller responsibilities outside this skill.

Fixed Terrain Profiles

Production supports exactly these versioned profiles:

| Profile | Atlas grid | Required painted slots | Godot terrain mode | Use when | | --- | --- | --- | --- | --- | | `marching_squares_15` | 4x4 | 15; `(0,0)` remains transparent | Match Corners (`1`) | Rule-based roads, floors, walls, and simple boundaries | | `blob_47` | 8x6 | 47; `(7,5)` remains transparent | Match Corners and Sides (`0`) | Natural ground, caves, shorelines, and detailed inner/outer corners |

`spec.autotile_profile` is required for declarative JSON. If an interactive caller asks for a TileSet without selecting it, ask whether the request needs simple rule-based boundaries for roads, floors, or walls, or detailed natural inner and outer corners for shorelines, caves, and irregular ground. Recommend one profile from the brief, then wait for a selection of `marching_squares_15` or `blob_47`. If the caller cannot answer, STOP before provider work. Never guess, fall back, or accept another profile.

`tools/asset_tileset_profile.py` is the fixed source of truth for slot coordinates, edge signatures, and peering bits. Provider guides, final atlas validation, recipe generation, and compiler input must derive from that one implementation. Agents must not enumerate 15/47 cells or hand-write `.tres` resources.

The profile generator emits `tile_size`, `margins`, `separation`, `terrain_sets`, and `peering_bits` deterministically. Physics, navigation, and custom data may be declared in `spec.semantic_metadata`; they are applied only to named semantic roles such as `foreground_full` or `foreground_isolated`, never inferred from pixels. In `blob_47`, the no-peering-bit slot is the isolated current terrain, not a complete background tile. This Skill does not support animated TileSets, occlusion, or alternatives. Unknown or misspelled fields are rejected.

References, Provider, And Trace

Carry every visual rule stated in `brief` into the prompt as written; it is the visual specification for this terrain library. References are optional caller-provided visual inputs, never profile definitions and never a style rule the brief did not state: they condition the stated rules, and a supplied reference that contradicts one of them is a STOP with a blocker naming the reference role, its path, and the rule. With references, resolve every `res://` path against the project root, verify it is readable, preserve its `canonical` or `style` role, and attach the actual image to the selected provider. A textual path is not an attachment. If attachment fails, STOP. Use a style reference for its material, color, linework, and visual language; do not copy its unrelated scene composition.

Honor `provider` exactly: `native`, `codex`, `gemini`, `openai`, `grok`, and `wan` never fall back to another provider. For Codex, call image generation with `referenced_image_paths` containing every readable local reference. Before the call, write a one-item plan with `require_provider_trace: true` and source target `.godotmaker/asset-generation/source/<asset_id>_provider.png`. After the call, write a generated-path report containing the actual image path, the Codex tool-call identity, configured coding model/reasoning, image-model identity (or `not_exposed_by_subscription_runtime`), every reference role, and the exact attached paths. Then claim it with `python .godotmaker/asset-runtime/tools/codex_image_claim.py --plan <plan.json> --report <generated-paths.json> --project-root . --out-report .godotmaker/asset-generation/reports/<asset_id>_source.json`. Missing or incomplete provider trace is a STOP; never copy a generated image directly into the project. Use `asset_source_generate.py` for Gemini/OpenAI/Grok/Wan API-backed generation.

Retain the controlled claim result, prompt, raw source, reference roles and paths, processing reports, commands or code, diagnostics, repairs, inputs, outputs, and modified files under `.godotmaker/asset-generation/`. Do not hand-write provider provenance. Diagnostic tools beyond the owned tools are allowed when needed, but the trace must explain why they were used and what recheck passed afterward.

Deterministic Production

1. Create the exact built-in profile manifest and labeled processing guide with `asset_tileset_profile.py`; do not make a generic numbered grid. The guide is not calle