# Philosopher > Reviews a completed Minecraft build — the plan, the execution, what worked and what did not — and records reusable process lessons in Claude's project memory so future builds go better. Use after a build is finished or a build session wraps up. Part of the minecraft-builder workflow. - Skill: `chapmanjw/philosopher` (Agent Skill) - Install (CLI): `npx skillmds@latest add chapmanjw/philosopher` - Raw SKILL.md: https://api.skillmd.com/api/skills/chapmanjw/philosopher/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/philosopher --- # Philosopher You run the retrospective. After a build, you look back over the whole job and distill **process lessons** — knowledge that makes the *next* build better — and record them where they will be available next time. ## Gather the evidence Review, for the just-finished job: - `.minecraft-builder//requirements.md` — what was asked for. - `.minecraft-builder//plan.toon` — what was planned. - `.minecraft-builder//survey.toon` and `research.*` — what was known. - The `worker`'s execution report — what actually happened. - `.minecraft-builder//inspections.toon` — the `inspector`'s log of every phase: what passed, and every course correction made along the way. - The world itself, if useful — `mc_structure_list`, the `mcbuilder:registry` property, spot-checks of the result. ## Assess Ask, honestly: - Where did plan and reality diverge — failed steps, rework, deviations? - What did the `inspector` have to course-correct, and why? A correction that recurs across phases or projects is a planning lesson worth recording — the goal is for the next plan to not need that correction at all. - Was the plan precise enough for the worker, or did ambiguity cause stalls? - Did the survey or research miss something that mattered? - What estimates (size, materials, phase count) were off, and by how much? - What went *right* and is worth doing again deliberately? - For a terrain or natural-wonder build, walk the `natural-landmarks` skill's `reference/anti-patterns.md` checklist — are all the signature features present and legible, and the proportions credible? A failed signature gate is a correction to make, not a cosmetic note. ## Record lessons — in the right place There are two stores, and mixing them up defeats the purpose: - **Build data → the world.** Coordinates, structure names, build status, revisions belong in the `mcbuilder:registry` world property and the structure files — not in memory. Before finishing, verify the registry is accurate; fix it with `mc_property_set` if the worker left it inconsistent. Do **not** copy build data into project memory. - **Process lessons → Claude project memory.** Generalizable knowledge about *how to build well* — write these to memory so the next job benefits. Write each lesson as a project-memory entry following the project's memory convention: a file with frontmatter (`type: project` for build-context facts, `type: feedback` for "do it this way next time" guidance), a `description` line for recall, and a body with **Why** and **How to apply**. Add a one-line pointer to the memory index. Keep lessons concrete and reusable — "fill the floor before the walls so hollowing doesn't clip the slab" — not vague ("plan better"). Check for an existing memory on the same point and update it rather than duplicating. ## Outstanding manual steps — surface them, every time Some builds leave **one-time manual actions** the user has to perform for the build to actually function. Most commonly: - A self-cycling redstone clock (rotating beam, windmill animation, observer ring) built via `setblock` will not self-start in Bedrock — the user must right-click one component once to kick the loop. See `engineer/reference/setblock-redstone-limits.md`. - Pressure-plate triggers wired to a hidden mechanism may need the player to walk over them once for the inspector's functional test to pass. - Boats, minecarts, and item frames placed via spawn or setblock sometimes need a player-click to "register" properly. Aggregate every such item from the project's `inspection-recipe.toon` files (every recipe's `manual_kick` block) and the inspector's reports. Surface them as a clearly-titled section in the final retrospective — coordinates, the action, and what it activates: ``` Outstanding manual steps (do these to activate the build): 1. Right-click any of the 4 lantern-room repeaters at (-39,143,-42), (-34,143,-39), (-37,143,-34), or (-42,143,-37) to start the rotating lighthouse beam. 2. Right-click the observer at (5,125,-30) at the windmill cap to start the blade animation. 3. Pull the lever at (-44,128,-44) to sound the foghorn. (Lever-driven — no kick needed; this is how to use it.) ``` This is non-optional. The Cape Aurelia retrospective established that the user shouldn't have to discover that the rotating beam needs a kick by noticing it isn't rotating — the orchestrator's final message must include the kick steps prominently, every time. ## Report Give the user a short retrospective: what worked, what didn't, the estimate gaps, the lessons you recorded, and the **outstanding manual steps**. Confirm the world registry is consistent. This closes the build; the world now holds everything needed to iterate on it later, and memory holds everything needed to build the next one better.