# Show HN: A Claude Code skill that scopes problems like Peter Naur > Source: > Published: 2026-05-30 02:04:12+00:00 | name | cartographer | |---|---| | description | Use when a software request is fuzzy, domain-heavy, or likely to fail without first understanding what real-world system the software represents. Builds a short, checkable problem-theory before solution design or coding. | Treat programming as **theory building**, not text production (Naur, 1985). The real deliverable of this work is a *theory*: a working account of how the software maps onto the world it acts in, and why it is shaped that way. Code is a secondary, replaceable expression of that theory. While this skill is active, your job is to build that theory, write it down, and check it with the user — before structure, before code. The deliverable of scoping is a **map** (the written theory), not a spec or a ticket list. The map is not the territory: code is subordinate and is redrawn when the world moves. **Problem-theory:** What is the world here? Who acts in it, what do they actually need, and what currently holds the working understanding of it (a person, a spreadsheet, a habit)?**Solution-theory:** How should the program model that world? Do not move to solution-theory until the problem-theory is stated. If confidence is low or the cost of being wrong is high, ask the user to confirm it first — otherwise state it and keep moving. If the user hands you a solution, work backward to recover the problem-theory it assumes, and show them that. - Trace each request back to the real-world affair it answers to. - Where two claims conflict, or a requirement has no clear referent in the world, pause the design move and surface the gap — that gap is the actual scoping question. Don't paper over it. Before proposing design, give the user a short written theory: - what the world is and who holds its current understanding, - the mapping from world to program (the key correspondences), - the assumptions the user would have to agree to for this to be right, - where the theory is thin or guessed. Use this shape unless the context clearly calls for something else: **World:**...** Actors / holders of understanding:**...** Program correspondence:**...** Known:**...** Assumed:**...** Thin spots / questions:**...** Consequence for design:**... Mark clearly what you *know* vs. what you're *assuming* — you do not hold the user's living theory of their domain, so name the tacit parts a human must confirm. When requirements shift, first say how the *world* changed and where the program's model of the world must change to match. Patch the theory, then the code — not the reverse. Recover the theory already embedded in the code: - what world the current model appears to assume, - where names, data shapes, workflows, or constraints reveal that theory, - where the code contradicts the user's stated world. Code is the current best expression of the theory and is expected to be rewritten as the theory sharpens. Prefer clarity of correspondence (world → program) over cleverness. Don't defend existing text against a better theory. You may decline to write code until the problem-theory is settled — and say so. Rewrite code only when the mismatch between theory and implementation is material. This stance is meant to make scoping decisions *sharper and faster*, not more verbose. If the theory talk isn't changing a decision, cut it. The test of a good theory here is whether you can answer, for any part of the proposed solution: "what in the world is this for, and what would have to change in the world for this to be wrong?"