# Transit Architect > Designs and blueprints world-spanning transit and infrastructure networks in a live Minecraft Bedrock world — rail lines, roads and highways, nether-hub transit, bridges, tunnels, elevators, docks, and airports — the connective network between separate builds. Chooses the network topology and routes the links. Use when the user wants to connect two or more sites, build a transit network, a nether hub, a highway, a bridge, a tunnel, or a rail line between places. Part of the minecraft-builder workflow. - Skill: `chapmanjw/transit-architect` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add chapmanjw/transit-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/chapmanjw/transit-architect/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: chapmanjw (https://skillmd.com/u/chapmanjw) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/chapmanjw/transit-architect --- # 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** → `city-planner` owns those. You connect cities; the city-planner connects buildings. - A single building (a station hall, a terminal) → `building-architect`. - Naturalistic terrain or a path through wild scenery with no network → `terraforming` shapes the land; a designed garden path → `landscape-architect`. ## Connection If an `mc_*` 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 Bedrock 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) is an `engineer` handoff. ## Bedrock 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 diagonal); a powered rail roughly every 38 blocks holds an occupied cart at speed; three in a row launch from rest. - **Ice boats** — on Bedrock, packed ice and blue ice run at the **same** speed (unlike Java). Default to **packed ice** — identical performance, far cheaper. - **Mob-proof the corridor** — light every route and cap tunnel floors so the network does not become a mob spawner. ## Inputs - **From `surveyor`** — the coordinates and surroundings of every site to connect; the terrain between them. - **From `researcher`** — 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`, for the existing builds and for iteration. ## Process 1. **Gather the sites** — every destination's coordinates and dimension; have the `surveyor` 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 `terraforming`. 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 hand off** — `requirements.md`, `plan.toon`, registry. Structure names follow the canonical colon form `mcb:_`. **Emit a `quality_contract` block** per the schema in `planner/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. ## 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 the `terraforming` skill's `reference/command-budget.md`. ## Sibling coordination Transit touches almost every skill — name each seam: - **Redstone** (boost stations, junction switches, drawbridges, elevator activators) → `engineer`. You place the static rail and footprints. - **Buildings** (station halls, terminals, control towers, lighthouses) → `building-architect`. You place the footprint and the connection point. - **Terrain grading** (a mountain pass, an embankment, a dredged channel) → `terraforming`. Flag it; do not grade inline. - **City streets** → `city-planner`; the **last stretch into a base or village** → `player-house` / `village-planner`. - **Sculpture** on a bridge or dock → `monument-builder`; **greenways and station plazas** → `landscape-architect`. ## Hard rules - **Never place blocks** — you produce a plan; the `worker` executes it. - **Static infrastructure only** — every redstone-driven mechanism is an `engineer` handoff. - **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 `terraforming` rather than carving terrain into the plan yourself. ## Hand off State the network back to the user — topology, the links and their modes, the major bridges and tunnels — and confirm `plan.toon` is written. Tell the orchestrator the order: `terraforming` grades any flagged terrain first, then `building-architect` builds stations and terminals, then `blueprinter` and the `worker` lay the network link by link with the `inspector` after each, and `engineer` adds the boost stations, switches, and elevator mechanisms last.