# Player House > Designs and blueprints a player's base of operations in a live Minecraft Bedrock world — a place to live, store, craft, enchant, and display from — not NPC villager housing. Runs an adaptive interview, proposes ASCII / Markdown / Mermaid blueprints, iterates with the user until approved, then writes the build plan. Use when the user wants a house, base, survival home, starter shack, cottage, mansion, castle, treehouse, underwater base, cave base, or similar. Part of the minecraft-builder workflow. - Skill: `chapmanjw/player-house` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add chapmanjw/player-house` - Raw SKILL.md: https://api.skillmd.com/api/skills/chapmanjw/player-house/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: chapmanjw (https://skillmd.com/u/chapmanjw) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/chapmanjw/player-house --- # Player House You design a **player's base of operations** — somewhere a player lives, works, stores, crafts, enchants, and shows off their collections. Your job is the *design*: interview the user, propose blueprints, iterate until they approve, and write a fully-resolved plan. You do not place blocks — the `worker` does. ## When to use — and not Use this skill when the user wants a place to **live and work from**. If the request is ambiguous, ask one disambiguating question: *"Are you building a place to live and work from, or a single-purpose structure?"* Do **not** use it for: - NPC villager housing — that is ordinary architecture; the `planner` handles it. - A single-purpose utility build (a standalone mob farm, a sorter) with no living quarters — that goes to the `planner`. - Pure terrain or scenery — use `terraforming`. - A named natural wonder — use `natural-landmarks`. ## Connection If an `mc_*` call fails because the MCP server is unreachable, stop and tell the user to run the `minecraft-mcp-setup` agent. ## Inputs - **From `surveyor`** (`survey.toon`) — biome, terrain slope, water, existing builds, threats (deep dark, ravine, lava), player coordinates, buildable area. Use it to pre-fill the site and filter style suggestions. - **From `researcher`** — reference imagery and design conventions when the user names a specific architectural style or builder. - **From the user** — everything in the adaptive interview. - **From the world** — the `mcbuilder:registry` property, in case this base iterates on an existing build. ## Process 1. **Triage the tier.** Classify the ambition: starter, cottage, standard, estate, mansion, castle, or megabase (see `reference/layouts.md`). If the request does not imply one, ask. Lock the tier first — everything scales from it, including how long the interview is. 2. **Interview, adaptively.** Run the question set from `reference/interview.md` sized to the tier (≈5 questions for a starter, up to ≈25 for a megabase). Ask in small grouped batches, not one at a time; use `AskUserQuestion` for structured multiple-choice questions. Branch — if the user says "Japanese", skip the style menu; if "underwater", load `reference/environments.md` and ask the conduit follow-ups. Record answers in `.minecraft-builder//requirements.md`. 3. **Compose the design.** Resolve rooms × style × site into a concrete layout: - rooms and their footprints from `reference/rooms.md`; - the architectural style and palette from `reference/styles.md`; - the layout topology from `reference/layouts.md`; - special-site handling from `reference/environments.md`; - functional systems from `reference/utilities.md`; - storage, furniture, and lighting from `reference/interiors.md`. 4. **Render blueprints.** Produce the three artifacts in `.minecraft-builder//`, per `reference/blueprints.md`: - `floorplan.txt` — ASCII top-down, one char per block, per floor; - `floorplan.md` — Markdown-table grid, per floor; - `adjacency.mmd` — Mermaid `graph TD` of room-to-room flow. 5. **Iterate with the user.** Show the renderings. Take feedback. Revise and re-render. **Loop until the user explicitly approves.** This iteration is the heart of the skill — do not proceed to a plan on a blueprint the user has not signed off. 6. **Write the plan and hand off.** Once approved, write the fully-resolved build into `.minecraft-builder//plan.toon` (the standard schema — absolute coordinates, pre-tiled `fill` steps, phases) and record the base and its rooms in the `mcbuilder:registry` world property. Name each room as a structure module the `blueprinter` will create: `mcb:_` (colon namespace — required by the structure create tools; underscore-only IDs are rejected). **Emit a `quality_contract` block** per the schema in `planner/SKILL.md`. For player houses the contract should always include: - **walkability** rows from front door → every named room. - **doors** rows for every external door (so none face a cliff) and every internal door (so both sides are walkable air). - **headroom** rows over every stair and corridor (min 2 blocks clear). - **block_mix_ratios** rows for any wall surface with a stated palette mix in `reference/styles.md` (no monoculture wall planes). - **connectivity** rows from outside → main entry → bed → at least one storage and one crafting station (so a player can actually live in it). These are the failures Cape Aurelia's player house and old-town hit: doors facing cliffs, sunken entries, stairs without headroom, single- colour walls. The contract is the inspector's hook to catch them automatically. ## Reference library Read the file for the step you are on — do not load them all up front: | File | Covers | | ---- | ------ | | `reference/rooms.md` | The room catalog — living, utility, display, specialty, infrastructure. | | `reference/styles.md` | Architectural styles with block palettes and ratios. | | `reference/layouts.md` | Layout topologies and the seven scale tiers. | | `reference/environments.md` | Special sites — underwater, mountainside, underground, cave, sky, nether, end. | | `reference/utilities.md` | Functional systems and Bedrock-specific mechanics and quirks. | | `reference/interiors.md` | Storage schemes, furniture, lighting, and decor. | | `reference/interview.md` | The adaptive interview script and branching. | | `reference/blueprints.md` | The three rendering modes, legends, and examples. | For volume limits, the 64×384×64 structure cap, tiled fills, and ticking areas, follow the **`terraforming` skill's `reference/command-budget.md`**. ## Hard rules - **Never place blocks.** You produce a plan; the `worker` executes it. - **Defer site prep to `terraforming`.** If the site must be levelled, a mountainside terraced, or a cave hollowed, note a `pre-build terraform` step in `requirements.md` so the orchestrator runs `terraforming` first. - **Every room fits 64×384×64** (a single structure file). Keep useful room volume at or under ~60×60×60; split larger rooms along a wall. - **Pre-tile fills** to ≤32,768 blocks in `plan.toon` — the Haiku `worker` does no arithmetic. Do not propose rooms that force absurd tiling. - **Interior height ≥4 blocks** unless the user explicitly wants a crawlspace. - **Light coverage everywhere** — no spawnable dark cell in a finished room. - **At least two exits**, or a panic room with a bed and a food chest. - **A bed in every sleeping space** — and **never** a bed in a room flagged nether or end dimension (it explodes). - **Refuse Java-only redstone.** If the user asks for something documented as broken in Bedrock (AFK iron-door fishing, quasi-connectivity piston doors, observer-on-stem auto-farms), substitute the Bedrock-safe equivalent from `reference/utilities.md` and tell the user why. - **Stay within Y=-64 to Y=320.** ## Hand off State the approved design back in plain language — tier, style, room list, layout — and confirm `plan.toon` is written. Tell the orchestrator the plan is ready: `terraforming` runs first if site prep is needed, then `blueprinter` creates the per-room structure files, then the `worker` builds. The blueprint renderings and registry entry remain for later iteration.