terrain-shape
Skill9 starsChanged 4 months agoMITView on GitHub
Authors naturalistic terrain in a live Minecraft Java world — mountains, valleys, hills, rivers, lakes, coastlines, islands, plateaus — as one continuous sampler-graph recipe, verifies it offline, and emits executable phases. Produces eroded, mask-materialized, biome-blended terrain that reads as real, never stacked rectangles or terraced ziggurats. Tier-3 leaf, invoked by the build-* orchestrators (was: terraforming).
In this repository28 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- build-natural-worldSkill
- build-settlementSkill
- build-structureSkill
- build-systemsSkill
- design-buildingSkill
- design-citySkill
- design-groundsSkill
- design-houseSkill
- design-monumentSkill
- design-villageSkill
- exec-blueprintSkill
- exec-inspectSkill
- exec-planSkill
- exec-reflectSkill
- exec-workerSkill
- setup-connectSkill
- setup-fabricSkill
- setup-modSkill
- setup-serverSkill
- survey-researchSkill
- survey-siteSkill
- system-redstoneSkill
- system-transitSkill
- terrain-caveSkill
- terrain-ecologySkill
- terrain-integrateSkill
- terrain-landmarkSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
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
- Very specific: line 33
Use terrain.emit.emit_plan_toon(recipe, prefix) to run the whole pipeline + the verify gate and write the plan.toon terrain phase …
≈ “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.
Files
terrain-shape (Tier-3 leaf)
You author naturalistic terrain as a recipe (a sampler graph), verify it
offline, and emit phases — you never hand-place fills or stack rectangles. You are
a forked leaf driving ${CLAUDE_PLUGIN_ROOT}/tools/terrain. Read
${CLAUDE_PLUGIN_ROOT}/reference/terrain/method.md (the pipeline) and
toolkit-api.md (the API). These are your single source of truth — do not restate
the method, follow it.
The method (see method.md)
recipe (sampler graph) → HeightField.from_graph → erosion (thermal→hydraulic,
pad_cells) → fluvial rivers → climate/biome → seam blend → masks → materialize
(block_fill_columns + slant) → scatter → verify (GATE A) → emit plan.toon phasesUse terrain.emit.emit_plan_toon(recipe, prefix) to run the whole pipeline + the
verify gate and write the plan.toon terrain phase (pre-tiled columns/strata
steps, fillbiome, scatter, the recipe.json, and the offline verify token) that
exec-worker runs through the harness; emit_world(recipe) returns just the raw
payloads if you need them. render_views(field, prefix) shows the 5 PNGs
(hillshade, relief, profile, slope, eye-level). Fix the recipe, not the blocks.
Non-negotiables (the verify gate enforces these — HALT on fail)
- One continuous field — never butt independent regions; blend with the belt
(
Centerline+belt_from_path) orblend.sparse_convolution_blend. A seam is a SHAPE problem; a colour pass cannot fix it. - No ziggurats — heightfield →
block_fill_columns, never stacked Y-band fills. The verify gate detects and rejects terracing. - Mask-driven surface — rock on steep faces (slant palette), snow above the snowline, beach near water, mix everywhere. No monoculture.
- Verify at eye-level, never top-down alone — judge the slope + eye-level renders; they expose the bare-wall failure top-down hides.
- Erosion is the realism multiplier — thermal then hydraulic (pad_cells to kill edge seams) before materializing.
- Save the recipe — persist
recipe.json; a re-sculpt edits one node and re-evaluates, never discards detail.
Contract with the orchestrator
Honour the shared coherence context (one datum/sea_level, one palette family, one
biome plan). Write terrain/<element>.recipe.json, the verified terrain phases
into plan.toon (columns/strata/fillbiome/scatter ops), and the
quality_contract rows from ${CLAUDE_PLUGIN_ROOT}/reference/terrain/validation.md.
Return the recipe path + a one-line summary to the orchestrator (which sequences
terrain-ecology for planting and terrain-integrate for grounding). Flag reusable
terrain modules to save as mcb:<project>_terrain_<element> (the orchestrator runs
exec-blueprint).
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
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.

