Techniques for mapping a domain's concepts, terminology conflicts, and bounded contexts — the raw material the conceptual model is built from
This skill is a library of techniques for the domain layer of a product design framework, focused on mapping what exists in the real world independently of any product: concepts, terminology, processes, relationships, and the mental models users bring. It solves the problem of building products on shallow or contested domain understanding by treating domain mapping as observation rather than design, capturing the raw material from which a conceptual model is later built.
Rather than a rigid script, it offers disciplines and techniques to apply as the situation demands. Its disciplines stress recording contradictions instead of resolving them (capturing synonyms and polysemy as findings), staying in the real world before product decisions creep in, distinguishing real objects from mere instances or values in a noun harvest, and being honest about whether you are mapping team beliefs versus researched fact. The techniques table includes concept maps and bubble diagrams, terminology audits, bounded-context mapping, noun harvests, domain event storming, expert interviews, document and artefact analysis, competitive analysis, and shadowing, each annotated with when to use it. The intended output is lightweight residue: a concept map if it earned its place, documented terminology conflicts, bounded contexts, key events, and the noun harvest that feeds the conceptual model skill.
It targets product designers, UX researchers, and product teams using this layered design methodology (it assumes a companion layers-intro has been loaded). Typical use cases include mapping an unfamiliar or contested domain before design begins, auditing terminology where communities use words differently, and preparing structured raw material for conceptual modeling. It is pure methodology guidance with no code execution or external tooling.
No. It is explicitly a library of techniques, not a script. You pick the technique that fits the live question, with concept mapping plus a terminology audit described as the usual core.
Yes. It assumes a companion layers-intro has been loaded for framework context and how-to-use guidance, and its noun harvest output feeds into a separate layers-conceptual-model skill.
Synonyms are the same thing with different names; polysemy is the same name meaning different things in different contexts. The skill says to capture both as findings rather than resolving them, since resolution belongs to the conceptual model layer.
Only the residue that carries a decision: a concept map if useful, documented terminology conflicts and bounded contexts, any key events, and the noun harvest, each noun marked as object, attribute, instance-or-value, or unclear.
Quick Setup:
.claude/skills/Repository
jamiemill/layers-skills