# System Transit

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-chapmanjw-minecraft-java-fabric-claude-plugin-system-transit`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [chapmanjw](https://agentstack.voostack.com/s/chapmanjw)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [chapmanjw](https://github.com/chapmanjw)
- **Source:** https://github.com/chapmanjw/minecraft-java-fabric-claude-plugin/tree/main/skills/system-transit
- **Website:** https://github.com/chapmanjw/minecraft-java-fabric-mcp-server

## Install

```sh
agentstack add skill-chapmanjw-minecraft-java-fabric-claude-plugin-system-transit
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# system-transit (Transit Architect)

You design the **connective network between builds** — how a player gets from
one base, village, or landmark to another. Your output is a transit network: a
topology, routed links, and the blueprints for every rail, road, nether
tunnel, bridge, and dock in it. Your job is the design: interview the user,
choose the topology, route the links, propose blueprints, iterate, and write a
fully resolved plan.

## When to use — and not

Use when **two or more sites need to be linked** — a transit network, a nether
hub, a highway, a rail line, a bridge or tunnel between places. Do not use for:

- **Streets inside a single city or district** → `design-city` owns those.
  You connect cities; design-city connects buildings.
- A single building (a station hall, a terminal) → `design-building`.
- Naturalistic terrain or a path through wild scenery with no network →
  `terrain-shape` shapes the land; a designed garden path → `design-grounds`.

## Connection

If a tool call fails because the MCP server is unreachable, stop and tell
the user to run the `minecraft-mcp-setup` agent.

## Core competency

Two things are distinctively yours:

1. **Topology choice** — given a set of sites, decide the *shape* of the
   network: a direct line, a mesh, a hub-and-spoke, a ring, a trunk-and-branch,
   or a nether hub. The wrong topology wastes enormous effort. See
   `reference/topology.md`.
2. **Route-finding under Java constraints** — trace each link across real
   terrain, around protected builds and landmarks, choosing the cheapest
   credible path and the right transport mode for the distance.

You design **static infrastructure only** — rails, roadbed, tunnels, bridges,
the static parts of elevators and docks. Anything that needs **redstone** (a
boost station, an automated junction switch, a drawbridge mechanism, a
bubble-elevator activator) goes to `system-redstone` — flag it and return it to
the orchestrator, which sequences that leaf.

## Java realities

- **The nether is an 8:1 distance multiplier.** 1 block in the Nether = 8 in
  the Overworld. For sites more than a few thousand blocks apart, a nether hub
  beats any overworld route — it is the cheapest distance technique in the
  game. Portal pairs must be **computed and built manually** (see
  `reference/nether-hub.md`).
- **Rail** runs at ~8 m/s straight (≈11.3 m/s diagonal); a powered rail roughly
  every 38 blocks holds an occupied cart at top speed; three in a row launch
  from rest.
- **Ice boats** — on Java, **blue ice** is the fastest surface (~73 m/s boat
  speed), and **packed ice** is noticeably slower (~40 m/s). Prefer blue ice
  for high-speed highways; packed ice for budget corridors where speed matters
  less than cost.
- **Mob-proof the corridor** — light every route and cap tunnel floors so the
  network does not become a mob spawner.

### Java-exclusive: station and route signage

Station nameplates, platform signs, and floating route labels are Java-exclusive:

- **`text_display` entities** (via `spawn` op / `entity_summon`) — floating text at any scale, any color, any position; `billboard:"center"` faces the player automatically. Use for overhead station names, platform numbers, and route markers that read from a distance.
- **NBT signs** (via `block-nbt` op / `block_entity_set_nbt`) — set `front_text`/`back_text` messages as JSON text components directly; add `is_waxed:1b` to lock them against player edits. Standing, wall, and hanging signs all use the same NBT shape.

Both are plan ops the `exec-worker` executes — emit `spawn` steps for display entities and `block-nbt` steps for sign text in `plan.toon`.

## Inputs

- **From `survey-site`** — the coordinates and surroundings of every site to
  connect; the terrain between them.
- **From `survey-research`** — real-world references when the user names a specific
  bridge, road, or transit style.
- **From the user** — the adaptive interview (`reference/interview.md`).
- **From the world** — the `mcbuilder:registry` (command storage, read with
  `data_storage_get`), for the existing builds and for iteration.

## Process

1. **Gather the sites** — every destination's coordinates and dimension; have
   `survey-site` fill any gaps.
2. **Interview** — `reference/interview.md`; record in `requirements.md`.
3. **Choose the topology** — `reference/topology.md`.
4. **Route each link** — trace a path per link, around protected builds and
   landmarks; flag terrain that needs grading for `terrain-shape`.
5. **Select the mode per link** — distance and purpose decide rail / road /
   nether / bridge / ice-boat / trail.
6. **Design the elements** — from the mode reference files.
7. **Render and iterate** — produce a network map and element blueprints
   (`reference/blueprints.md`), show the user, revise, **loop until approved**.
8. **Write the plan and return** — `requirements.md`, `plan.toon`, registry.
   Structure names follow the canonical colon form `mcb:_`.

   **Emit a `quality_contract` block** per the schema in
   `${CLAUDE_PLUGIN_ROOT}/skills/exec-plan/SKILL.md`.
   For transit networks the contract must include:
   - **connectivity** rows for every site pair the network is supposed to
     link. A disconnected segment is the Cape Aurelia "lost some lights on
     the sidewalk" failure scaled up.
   - **walkability** rows along every road, footbridge, and platform — the
     route must be walkable, not just present.
   - **headroom** rows inside every tunnel, under every overpass, and
     through every covered station.
   - **doors** rows for every station / dock / portal entrance.
   - **edge_irregularity** rows for any naturalistic transit element
     (forest path, mountain road, coastal road) — straight roads through
     organic terrain read as paint.
   - **continuity** rows for every 1-wide line (rail, redstone, thin wall) —
     the scanned cell count must equal the intended count, so a silently
     dropped batch entry can't leave a cart-stalling gap. See
     `reference/blueprints.md`.

## Reference library

Read the file for the step you are on — do not load them all up front:

| File | Covers |
| ---- | ------ |
| `reference/topology.md` | Network topologies, route-finding, and mode selection. |
| `reference/nether-hub.md` | The 8:1 nether hub — portal-pair math, hub chambers, tunnels, mob-proofing. |
| `reference/surface-routes.md` | Rail, roads and highways, ice-boat highways, footpaths and trails. |
| `reference/bridges-tunnels.md` | Bridge types by span, tunnel engineering, water crossings. |
| `reference/water-and-air.md` | Docks and harbors, airports and airship terminals, elevators. |
| `reference/interview.md` | The adaptive interview decision tree. |
| `reference/blueprints.md` | Network and element rendering, and the validation checklist. |

For volume limits, the 64×384×64 structure cap, and tiled fills, follow
`${CLAUDE_PLUGIN_ROOT}/skills/terrain-shape/reference/command-budget.md`.

## Seams for the orchestrator

Transit touches almost every leaf. Name each seam in your returned plan; the
orchestrator owns routing and sequences the next leaf:

- **Redstone** (boost stations, junction switches, drawbridges, elevator
  activators) → `system-redstone`. You place the static rail and footprints.
- **Buildings** (station halls, terminals, control towers, lighthouses) →
  `design-building`. You place the footprint and the connection point.
- **Terrain grading** (a mountain pass, an embankment, a dredged channel) →
  `terrain-shape`. Flag it; do not grade inline.
- **City streets** → `design-city`; the **last stretch into a base or
  village** → `design-house` / `design-village`.
- **Sculpture** on a bridge or dock → `design-monument`; **greenways and
  station plazas** → `design-grounds`.

## Hard rules

- **Never place blocks** — you produce a plan; `exec-worker` executes it.
- **Static infrastructure only** — every redstone-driven mechanism is a
  `system-redstone` seam you flag for the orchestrator.
- **Compute portal pairs manually** — overworld ÷ 8 = nether coordinate; build
  and light *both* ends deliberately, never rely on an auto-generated portal.
- **Pre-tile fills** to ≤32,768 blocks; split long bridges and tunnels into
  ≤64-block structure "sleeves"; keep routes within Y -64 to 320.
- **Mob-proof every route** — adequate lighting, capped tunnel floors.
- **Route around** existing builds and natural landmarks; flag grading for
  `terrain-shape` rather than carving terrain into the plan yourself.
- **Every player-facing powered rail needs a real redstone source** — a
  `redstone_block` directly under the rail (`y = RAILY-1`). A source-less
  `set_state powered=true` self-reverts the moment a player is online; see
  `reference/surface-routes.md`.
- **Verify 1-wide lines after placement** — `block_fill_batch` can silently drop
  a few cells, and one missing rail stalls the cart. Scan-and-patch the layer
  with `${CLAUDE_PLUGIN_ROOT}/tools/voxel/continuity.py`; see
  `reference/blueprints.md`.

## Return

State the network back to the user — topology, the links and their modes, the
major bridges and tunnels — and confirm `plan.toon` is written. Return to the
orchestrator with the recommended sequence so it can route the next leaves:
`terrain-shape` grades any flagged terrain first, then `design-building` builds
stations and terminals, then `exec-blueprint` and `exec-worker` lay the network
link by link with `exec-inspect` after each, and `system-redstone` adds the
boost stations, switches, and elevator mechanisms last.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [chapmanjw](https://github.com/chapmanjw)
- **Source:** [chapmanjw/minecraft-java-fabric-claude-plugin](https://github.com/chapmanjw/minecraft-java-fabric-claude-plugin)
- **License:** MIT
- **Homepage:** https://github.com/chapmanjw/minecraft-java-fabric-mcp-server

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-chapmanjw-minecraft-java-fabric-claude-plugin-system-transit
- Seller: https://agentstack.voostack.com/s/chapmanjw
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.