Layers Domain
- 1.6k installs
- 282 repo stars
- Updated May 30, 2026
- jamiemill/layers-skills
layers-domain is a Claude Code skill that supplies techniques to map real-world domain concepts, terminology conflicts, and bounded contexts for developers who must understand a problem space before building a conceptual
About
layers-domain is part of jamiemill/layers-skills and assumes layers-intro has been loaded first. The skill is a technique library—not a fixed script—for observing what exists in the real world independently of any product: concepts, language, processes, relationships, and user mental models. It helps decide key domain concepts, how they relate, and where terminology conflicts or bounded contexts appear. Developers reach for layers-domain when starting a new product area, entering an unfamiliar industry, or before committing to data models, APIs, or UX flows that encode the wrong abstractions.
- Maps key domain concepts and their real-world relationships independently of any product design
- Captures terminology conflicts, synonyms, and polysemy as findings rather than resolving them
- Identifies natural seams where communities use the same words differently
- Records events and processes that structure domain activity over time
- Disciplines include 'Don't resolve contradictions — record them' and 'Stay in the real world'
Layers Domain by the numbers
- 1,575 all-time installs (skills.sh)
- +128 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #374 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/jamiemill/layers-skills --skill layers-domainAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.6k |
|---|---|
| repo stars | ★ 282 |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 30, 2026 |
| Repository | jamiemill/layers-skills ↗ |
How do you map domain concepts before building software?
Systematically map real-world domain concepts, terminology conflicts, and bounded contexts before building any conceptual model or product features.
Who is it for?
Developers or tech leads entering a new business domain who need shared vocabulary and boundaries before architecture or UI work.
Skip if: Teams that already have a validated ubiquitous language and bounded contexts locked in documentation.
When should I use this skill?
The user wants domain discovery, bounded-context mapping, or terminology alignment before design or implementation.
What you get
Domain concept inventory, terminology conflict notes, bounded-context map, and conceptual-model raw material.
- Domain concept map
- Terminology conflict log
- Bounded-context outline
Files
/layers-domain
Assumes `/layers-intro` has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.
The domain layer maps what exists in the real world independently of any product: the concepts, terminology, processes, relationships, and mental models users bring with them. This is observation, not design.
---
The decisions this layer makes
- What the key concepts in this domain are, and how they relate
- What language people use — and where it conflicts or diverges
- Where the natural seams are: communities that use the same words differently
- What events and processes structure the domain's activity over time
If the domain is already well understood and uncontested, you may not need this layer — go straight to the conceptual model.
---
Disciplines — what keeps domain work honest
- Don't resolve contradictions — record them. Messy, inconsistent domain language is data: it signals where communities have diverged and where the product will later have to choose. Resolution belongs to the conceptual model, not here. Capture synonyms (same thing, different names) and polysemy (same name, different things in different contexts) as findings, not problems.
- Stay in the real world. Push back whenever answers drift toward product or interface decisions. The question is always how the domain works before your product enters it.
- Real objects vs instances (for the noun harvest). A true object is instanceable (you can have many), structured (has its own attributes), and useful (people care about it in its own right). Watch for instances mistaken for objects: "CAC", "ROAS", "LTV" aren't objects, they're instances of one object, Metric. Mark each noun object / attribute / instance-or-value / unclear — and don't filter aggressively; the conceptual model does the sorting.
- Beliefs vs reality. If you're mapping what the team believes rather than researched fact, say so throughout — it's the team's model, not necessarily how users experience the domain.
---
Techniques
Pick what fits — concept mapping plus a terminology audit is the usual core.
| Technique | Use it when |
|---|---|
Concept maps / bubble diagrams (graph TD/LR) | The domain is complex and poorly understood. Informal nodes-and-lines show how concepts relate without forcing premature structure. |
| Terminology audit | Capture, per concept: the names used, who uses which and when, and whether the conflict is synonymy or polysemy. Don't pick a winner. |
| Bounded-context mapping | Communities share vocabulary internally but diverge across groups. Name and describe each seam — it will matter when the model is defined. |
| Noun harvest | Compile every noun surfaced, marked object / attribute / instance-or-value / unclear. Raw material for the conceptual model. |
| Domain event storming (Brandolini) | Process-heavy domain. Name significant events in past tense on a timeline; note triggers and results. Objects with events around them likely need state diagrams later. |
| Expert interviews | Domain knowledge lives in people, not documents — surfaces tacit knowledge and contested terms. |
| Document & artefact analysis | The domain produces contracts, forms, invoices that reveal natural structure and vocabulary. |
| Competitive analysis | Entering an established domain — existing products reveal how others modelled it, and where they disagree. |
| Shadowing | Workflows are hard to articulate; watching reveals what people actually do. |
---
Working with the designer
Open by asking what domain you're mapping, who operates in it, and what they're trying to accomplish before any product exists. Then surface concepts — listen for nouns (candidate objects), verbs (processes), and the natural vocabulary, including what people actually call things.
Offer the technique that fits the live question: a concept map when relations are unclear, a terminology audit when language is contested, event storming when the domain is process-heavy. Do the next useful thing, not all of them.
Capture only the residue — the concept map if it earned its place, the documented terminology conflicts and bounded contexts, any key events, and the noun harvest. This is raw material, not a finished document.
When the domain is mapped, the noun harvest is the starting point for /layers-conceptual-model.
Related skills
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493kFAQ
Does layers-domain require other Layers skills?
layers-domain assumes layers-intro has been loaded first. layers-intro explains how to use the Layers technique library; layers-domain then focuses on real-world concepts, language, and bounded contexts.
Is layers-domain a design or coding skill?
layers-domain is observation, not visual design or implementation. layers-domain captures what exists in the domain—the concepts, terminology, and boundaries—that later conceptual models and features are built from.
Is Layers Domain safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.