Menu
Diagnostic audit across all seven layers — identifies the bottleneck layer and recommends where to focus
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Techniques for defining the product's objects, relationships, states, and vocabulary independently of any interface — the most load-bearing layer
Framework orientation for Layers of Product Design — load this first; provides the context all other skills depend on
Techniques for mapping a domain's concepts, terminology conflicts, and bounded contexts — the raw material the conceptual model is built from
Techniques for mapping interaction structure and flow — places, affordances, edge cases, and failure paths — without committing to visual form
Techniques for planning user research and synthesising it into grounded, confidence-rated findings about what users actually do
Techniques for connecting user opportunities to business outcomes and solution bets, and testing the riskiest assumptions cheaply
| name | layers-orient |
| description | Diagnostic audit across all seven layers — identifies the bottleneck layer and recommends where to focus |
Assumes /layers-intro has been loaded for framework context.
Orient is a rapid diagnostic — the front door for finding the live decisions the other skills then work. It maps the current state of decisions across all seven layers, identifies the bottleneck — the lowest layer with unresolved or risky decisions — and recommends where to focus next.
It is not a deep dive into any layer. That's what the individual layer skills are for. Orient answers the prior question: which layer deserves attention most urgently? Keep it fast and light — the output is a short audit and one recommendation, not a report.
What it assesses:
Quality signals — when orient is done well:
Describe your design situation and what prompted you to pick it up, or say "let's orient" to start.
(Capture is opt-in and light — see /layers-intro. For orient, the audit table itself is usually all that's worth keeping.)
Then ask:
Listen for clues about which layers have already been worked through and which are thin or missing.
Work through each layer with one or two targeted questions. Rate each as: Strong / Partial / Assumed / Weak / Not started / N/A
Observed behaviour "What user research do you have? Have you spoken to users, observed them, or have analytics? Or is this mostly based on what the team believes users do?"
The domain "How well do you understand the space this product operates in — the real-world concepts, terminology, and how users think before your product enters the picture?"
User needs "Can you articulate what users are trying to achieve — not in features, but the underlying job and why it matters? Do you have job stories or equivalent?"
Product & service strategy "Do you know which specific user need this work targets and what business outcome it's meant to move? Is the connection between opportunity and business goal explicit, or informal?"
Conceptual model "Does the product have a clear model of the objects it works with — the things that exist, how they connect, and what vocabulary you use? Is this shared across the team, or does each person have their own version?"
Interaction structure and flow "Do you have a clear picture of the key user journeys — places, steps, decision points? A breadboard, rough flow, working code, or a description you can narrate?"
Surface "Is there an existing design system, visual language, or component library this needs to fit into?"
Produce the audit as a table:
Layer | State | Notes
---------------------------|-------------|----------------------------------------
Observed behaviour | |
The domain | |
User needs | |
Product & service strategy | |
Conceptual model | |
Interaction structure | |
Surface | |
Identify the bottleneck layer: the lowest layer with Weak, Assumed, or Not started state. State it clearly: what decisions are missing, and what risk does that create for the layers above?
Also flag assumed layers — layers treated as decided but not verified. Assumptions that look solid are often where the most dangerous decisions hide.
If the designer has a deadline or constraint that changes the calculus, acknowledge it. Sometimes the right move isn't the most foundational one — name that tradeoff explicitly rather than ignoring it.
Recommend a specific skill to run next and why:
/layers-conceptual-model/layers-product-strategy/layers-user-needs/layers-domain/layers-interaction-flow/layers-observed-behaviourClose with: "Want to run [skill] now, or is there something in this picture to push back on first?"