{"slug": "show-hn-a-claude-code-skill-that-scopes-problems-like-peter-naur", "title": "Show HN: A Claude Code skill that scopes problems like Peter Naur", "summary": "A new skill for Claude Code, called \"cartographer,\" implements a programming methodology based on computer scientist Peter Naur's 1985 theory that software development is fundamentally about building a shared understanding of how code maps to the real world. The skill forces the AI to construct a written \"problem-theory\" before proposing any solution or writing code, requiring it to identify actors, assumptions, and gaps in the user's domain knowledge. This approach aims to make scoping decisions sharper and faster by prioritizing clarity of real-world correspondence over code generation.", "body_md": "| name | cartographer |\n|---|---|\n| 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. |\n\nTreat programming as **theory building**, not text production (Naur, 1985). The\nreal deliverable of this work is a *theory*: a working account of how the\nsoftware maps onto the world it acts in, and why it is shaped that way. Code is\na secondary, replaceable expression of that theory. While this skill is active,\nyour job is to build that theory, write it down, and check it with the user —\nbefore structure, before code.\n\nThe deliverable of scoping is a **map** (the written theory), not a spec or a\nticket list. The map is not the territory: code is subordinate and is redrawn\nwhen the world moves.\n\n**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?\n\nDo 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.\n\n- Trace each request back to the real-world affair it answers to.\n- 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.\n\nBefore proposing design, give the user a short written theory:\n\n- what the world is and who holds its current understanding,\n- the mapping from world to program (the key correspondences),\n- the assumptions the user would have to agree to for this to be right,\n- where the theory is thin or guessed.\n\nUse this shape unless the context clearly calls for something else:\n\n**World:**...** Actors / holders of understanding:**...** Program correspondence:**...** Known:**...** Assumed:**...** Thin spots / questions:**...** Consequence for design:**...\n\nMark clearly what you *know* vs. what you're *assuming* — you do not hold the\nuser's living theory of their domain, so name the tacit parts a human must\nconfirm.\n\nWhen requirements shift, first say how the *world* changed and where the\nprogram's model of the world must change to match. Patch the theory, then the\ncode — not the reverse.\n\nRecover the theory already embedded in the code:\n\n- what world the current model appears to assume,\n- where names, data shapes, workflows, or constraints reveal that theory,\n- where the code contradicts the user's stated world.\n\nCode 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.\n\nThis stance is meant to make scoping decisions *sharper and faster*, not more\nverbose. If the theory talk isn't changing a decision, cut it. The test of a\ngood theory here is whether you can answer, for any part of the proposed\nsolution: \"what in the world is this for, and what would have to change in the\nworld for this to be wrong?\"", "url": "https://wpnews.pro/news/show-hn-a-claude-code-skill-that-scopes-problems-like-peter-naur", "canonical_source": "https://github.com/spinchange/cartographer-skill/blob/main/skills/cartographer/SKILL.md", "published_at": "2026-05-30 02:04:12+00:00", "updated_at": "2026-05-30 02:15:32.621190+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "large-language-models", "artificial-intelligence"], "entities": ["Peter Naur", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/show-hn-a-claude-code-skill-that-scopes-problems-like-peter-naur", "markdown": "https://wpnews.pro/news/show-hn-a-claude-code-skill-that-scopes-problems-like-peter-naur.md", "text": "https://wpnews.pro/news/show-hn-a-claude-code-skill-that-scopes-problems-like-peter-naur.txt", "jsonld": "https://wpnews.pro/news/show-hn-a-claude-code-skill-that-scopes-problems-like-peter-naur.jsonld"}}