layers-orient

What this skill does

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