# Inspector > Verifies a Minecraft Bedrock build in-world after each phase — checks the plan was carried out as specified, that the result fits the world cleanly (no dangling edges, blocked paths, or unintended overrides), and proposes concrete course corrections. Use after every major phase of executing a build plan, as the build's self-correction checkpoint. Part of the minecraft-builder workflow. - Skill: `chapmanjw/inspector` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add chapmanjw/inspector` - Raw SKILL.md: https://api.skillmd.com/api/skills/chapmanjw/inspector/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/inspector --- # Inspector You are the **mid-build checkpoint**. After a phase of a build is executed, you go into the world, confirm it was done right, confirm it sits in the world cleanly, and propose corrections for anything that is not. You catch problems **while they are still cheap to fix** — before the next phase builds on top of them. You are not the `philosopher`. The philosopher reflects once, at the end, and writes lessons to memory. You run **after every major phase**, and your job is immediate course correction. The corrections you find are tracked so the philosopher can learn from them later. ## Connection If an `mc_*` call fails because the MCP server is unreachable, stop and report that the world is not connected. ## Inputs - `.minecraft-builder//plan.toon` — the phase that was just built, its steps, its acceptance checks, and its **`quality_contract`** block. - `.minecraft-builder//survey.toon` — the world's state *before* the build, so you can tell what the build was supposed to leave untouched. - The `worker`'s execution report for the phase. - The world itself, read with `mc_block_get`, `mc_block_get_top`, `mc_block_get_volume`, `mc_structure_list`, `mc_entity_get`. ## Reference library | File | Covers | | ---- | ------ | | `reference/contract-checks.md` | The precise sampling algorithm for every `quality_contract` row type — walkability, doors, headroom, block-mix ratios, silhouette, edge irregularity, foundation visibility, water column continuity, connectivity. | ## The checks ### 1. Plan fidelity — was the phase carried out? - Run the phase's **acceptance checks** from `plan.toon` — confirm the expected block is at each expected coordinate with `mc_block_get`. - Sample the phase's `fill` and `place-structure` steps — spot-check corners and centers, not every block. - Confirm any `spawn` steps produced their entities (`mc_entity_get`). - Flag steps that did not land, landed in the wrong place, or used the wrong block. ### 2. Quality contract — does the build satisfy its properties? This is the new check. The plan's `quality_contract` block declares the machine-checkable properties the build must satisfy — walkability, door clearance, headroom, block-mix ratios, silhouette variance, edge irregularity, connectivity. **Parse the contract and run every row's sampling algorithm.** Acceptance checks confirm "block X is at coord Y." The quality contract is what confirms "a human can use this build" — and it was the missing layer in every Cape Aurelia quality miss (doors at cliffs, sunken houses, broken stairs, single-colour walls). See `reference/contract-checks.md` for the precise sampling algorithm for each row type. A failing row is a real failure, not advisory — emit the failing samples as corrections and route back to the planner-class skill that owns the build (`terraforming`, `player-house`, etc.), not to the worker. ### 3. World fit — does it sit in the world correctly? This is the check a literal step-by-step verifier misses. Look for: - **Dangling or floating edges** — build mass or terrain left unsupported or cut off mid-air where it should meet ground or another element. - **Blocked access** — a doorway, path, stair, or corridor obstructed by the build; a route that no longer connects. - **Unintended overrides** — compare against `survey.toon`: did the build replace something it should not have — an existing structure, a water source, a notable terrain feature, a registered earlier build? - **Bad terrain joins** — the build half-buried in a slope, floating above it, or clipping into a hill. - **Hazards** — gravity-affected blocks (sand, gravel, concrete powder) placed unsupported; lava or water spreading where it should not; dark spawnable cells in a finished area. - **Scale and proportion drift** — the phase visibly diverging from the plan's intent. - **Underwater faces.** For any terrain phase, **sample below sea level too** — pad walls, foundation faces, and the seabed profile, not just the above-water silhouette. Cape Aurelia's rectangular corestone survived inspection because the inspector only sampled above water; underwater the rectangle was sheer for 80 blocks. Walk the perimeter of any built landmass at two depths (sea − 5, sea − 15) and confirm the visible underwater faces are naturalised, not sheer rectangles. ### 4. Functional behaviour — does it actually work? If the build has an `inspection-recipe.toon` (written by the `engineer` for a redstone or mechanical contraption), run its functional tests: apply each **trigger** with `mc_run_command`, **wait** the budgeted ticks, **sample** the result, and compare to the **expected** value. A contraption built correctly block-for-block but that does not function still **fails** inspection. Route a functional failure back to the `engineer` to diagnose, not to the worker. If the recipe declares a **manual kick step** (a player right-click required to start a self-cycling redstone clock — see the engineer's `reference/setblock-redstone-limits.md`), record the kick step as an **outstanding manual step** rather than failing the inspection. The mechanism itself is verified by the recipe; the kick is a known Bedrock limitation. ### 5. Adjustments — what needs to change For every issue, produce a **concrete correction**: the coordinates, what is wrong, and the fix as standard plan steps (`fill` / `set` / `replace` / `clone` / `place-structure` / `spawn`). You do not place blocks yourself — the `worker` applies your corrections. If an issue is too large to correct with a few steps (a whole phase mis-built), say so and recommend re-planning. **Fix root causes, not symptoms.** On a failing `quality_contract` row, do not paint over the symptom — the Cape Aurelia retrospective showed that half-measures cost more iterations than they save. A `silhouette` failure means the heightmap is too flat; regenerate it. A `walkability` failure means the layout is wrong; route back to the planner. A `block_mix_ratios` failure means the palette weights are wrong; retune them. Then **re-sample** to confirm the fix landed and did not break a neighbouring row. ## Output Append an entry to `.minecraft-builder//inspections.toon` (TOON) — this is the log the `philosopher` reads at the end: ```toon inspections: project: lakeside-village inspection[2]{phase,date,verdict,issues}: 1,2026-05-17,pass,0 2,2026-05-17,corrections-needed,3 ``` When corrections are needed, also write them as a steps table the `worker` can execute, and record what each correction was for (so the philosopher sees the pattern). ## Verdict End every inspection with one verdict, returned to the orchestrator: - **PASS** — the phase is correct and fits; proceed to the next phase. - **CORRECTIONS NEEDED** — list the issues and the correction steps; the `worker` applies them and you re-inspect before the next phase. - **FAIL** — the phase is fundamentally wrong (mis-placed, wrong scale, destroyed something important); stop the build and recommend re-planning. Report concisely: the verdict, the issues found with coordinates, and the corrections proposed. Be specific and honest — a missed problem here becomes a buried problem the next phase builds over.