メニュー
Techniques for defining the product's objects, relationships, states, and vocabulary independently of any interface — the most load-bearing layer
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/jamiemill/layers-skills --skill layers-conceptual-modelコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | layers-conceptual-model |
| description | Techniques for defining the product's objects, relationships, states, and vocabulary independently of any interface — the most load-bearing layer |
Assumes /layers-intro has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.
The conceptual model is the most neglected load-bearing layer. It defines the objects the product recognises, how they relate, what states they can be in, and the vocabulary for all of it — a deliberate decision about how the product models its domain, independent of any interface.
It is not the users' messy mental model (that's the domain layer), and not a database schema, wireframe, or flow. But the gap between this model and what engineers build matters: a large, unexamined gap is both UX debt (users meet a product that contradicts the model) and technical debt (the system is hard to evolve).
If none of these is genuinely open, you may not need this layer right now. Say so rather than working it for the sake of it.
Apply these to whatever you produce, in any order. They are the high-value part of this layer.
Pick the one that fits the live decision — don't run them all.
| Technique | Use it to |
|---|---|
| Noun foraging + OOUX (Sophia Prater) | Extract objects from research or domain notes. The default when you have naturalistic language to mine. Sort nouns into objects / attributes / instances-or-values / set-aside (UI elements, vague abstractions, actions dressed as nouns), using the "real objects only" test above. |
| Object definition | Pin down one object: what it is (one sentence, the user's view), its attributes, its relationships (cardinality + role names), and its actions. |
| Sketch the flow first (push forward, pull back) | Objecthood is uncertain — whether something should be a persistent object depends on how it's used. Breadboard the flow (/layers-interaction-flow) to see what must persist, hold state, or be returned to, then come back and formalise only those. Often the fastest way to tell a real object from a transient one. |
Relational object map (erDiagram) | See objects and relationships together and catch missing, reversed, or spurious connections. ||=exactly one, o{=zero-or-many, |{=one-or-many; crow's foot on the many side; labels read first entity → second. |
State transition diagram (stateDiagram-v2) | For an object whose status changes what users can do — name the states, the transitions, and what each state forbids. |
| Action (CTA) inventory | List every action a user can take, across all objects, in one place — the product's call-to-action vocabulary. Listing them together (not object by object) is what exposes inconsistency (Add vs Create vs New for one operation) and over-flattening (one verb hiding distinct operations). |
| Ubiquitous language list | Resolve naming. For each contested concept: the chosen term, rejected alternatives, and why. One name per concept, one concept per name — in UI, help text, API names, and internal talk alike. |
| Semantic IxD / action grammar (Rosenberg) | Audit verb consistency and precision across many actions and objects. |
| Event storming — commands/policies (Brandolini) | Process-heavy domain: start from what happens, work back to the objects involved. |
| Card sorting | Vocabulary is unclear or contested across users or teams. |
| Walking the existing product | Redesign: the current UI reveals the implicit model — compare it to how users actually think. |
Also probe the temporal decisions from /layers-intro — intermediate action states, read-model lag, relationship temporality, deletion semantics, history — for any object where they bite.
Find which of the decisions above are live. Offer the technique that fits: noun foraging if there's material to mine, walking the product if redesigning, or straight to object definition if the objects are known and only their shape is open. Do the next useful thing, not the whole toolkit.
Capture only the residue — the object definitions that got settled (and which are still provisional, pending a bet or a flow), any diagram that encodes a real relationship or lifecycle, the vocabulary calls, and the open questions (objects that felt thin, decisions deferred to engineering). Don't write a report the designer won't reread.
If domain work hasn't been done, say plainly: this model is a hypothesis until there's evidence.
When the objects and actions are stable, the natural next move is to design how users move through them — /layers-interaction-flow.
