Everything else in this gallery operates at the surface — how the thing looks, how it moves, whether the tap target is big enough. This one sits underneath all of it, and it is the only entry here that will tell you the design problem you brought it isn’t the design problem you have.
The framework stacks seven layers: observed behaviour, the domain, user needs, product and service strategy, the conceptual model, interaction structure and flow, and finally surface. Each has its own skill. Orient is the front door — a rapid audit across all seven that names the bottleneck: the lowest layer with unresolved or risky decisions, because unresolved work low in the stack puts everything above it at risk.
The sharpest move is a distinction most audits skip entirely: separating decisions that are genuinely solid from decisions that are merely assumed. A team that believes its conceptual model is settled, when it was actually inherited unexamined from a competitor, will keep producing surface work that doesn’t land and won’t know why. Assumed and Strong look identical from the outside and require completely different responses.
Its quality signals are stated as tests it can fail: the bottleneck layer is named specifically rather than gestured at, assumed layers are distinguished from strong ones, and the recommendation points at one particular skill with a reason. A diagnostic that can only ever say “seems fine, keep going” isn’t a diagnostic.
It’s deliberately shallow by design — a short audit and one recommendation, not
a report. The depth lives in the eight sibling skills it routes to. Run
/layers-intro first for framework context; Orient assumes it.
Where it fits with the rest of Canon: use this before the craft skills, not alongside them. If Orient says your bottleneck is user needs, no amount of motion polish or accessibility remediation will help — and the honest thing a design tool can do is say so.
MIT. Installs with npx skills add jamiemill/layers-skills.