/layers-orient

name: layers-orient
description: Diagnostic audit across all seven layers — identifies the bottleneck layer and recommends where to focus

/layers-orient

*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:**

• Whether key decisions have been made at each layer, and how solidly
• Whether decisions treated as solid are actually assumptions
• Which layer is the most foundational with unresolved work, creating risk for everything above

**Quality signals — when orient is done well:**

• The bottleneck layer is specifically named, not vaguely gestured at
• Assumed layers are distinguished from Strong ones — they require different responses
• The recommendation connects to a specific skill with a clear reason

---

Guided session

*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: 1. What product or feature are you working on? 2. What design challenge are you facing right now? 3. How far along is this work — early exploration, active design, or fixing something in an existing product?

Listen for clues about which layers have already been worked through and which are thin or missing.

---

Layer audit

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?"*

---

Decision landscape

Produce the audit as a table:

Layer                      | State       | Notes
---------------------------|-------------|----------------------------------------
Observed behaviour         |             |
The domain                 |             |
User needs                 |             |
Product & service strategy |             |
Conceptual model           |             |
Interaction structure      |             |
Surface                    |             |

---

Bottleneck analysis

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.

---

Recommendation

Recommend a specific skill to run next and why:

• Conceptual model → `/layers-conceptual-model`
• Product strategy → `/layers-product-strategy`
• User needs → `/layers-user-needs`
• Domain → `/layers-domain`
• Interaction structure → `/layers-interaction-flow`
• Observed behaviour → `/layers-observed-behaviour`

Close with: *"Want to run [skill] now, or is there something in this picture to push back on first?"*