player-house

name	player-house
description	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.
model	opus
effort	high

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/<project>/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/<project>/, 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/<project>/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:<project>_<room> (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.