---
name: layr-design-reference
description: Interface design rules published by Layr Design Reference. Use when a task needs design guidance, review criteria, or anti-slop and flow-completeness rules for building or auditing a user interface.
---

# Layr Design Reference

Use this skill when the current task requires knowledge, rules, documentation, patterns, standards, guidance, or public product information published by Layr Design Reference.

Source:

https://layr.design

This skill contains an agent-ready representation of the public knowledge published by the source website.

Its purpose is to help you apply that knowledge accurately without loading the entire website into context.

## Start here

Before acting on the task:

1. Understand what the user is trying to accomplish.
2. Read `references/route-map.md`.
3. Identify the smallest set of references relevant to the task.
4. Read those references.
5. Load additional references only when necessary.
6. Perform the task using the relevant source knowledge.

Do not load every reference by default.

## Knowledge map

Use:

`references/route-map.md`

as the primary navigation layer for this skill.

The route map describes:

* available public topics;
* source routes;
* what each reference contains;
* how the knowledge is grouped.

Use it to decide which references should enter context.

## References

Detailed public knowledge is stored under:

`references/routes/`

The directory structure mirrors the source website where practical.

Examples:

```text
references/routes/index.md
references/routes/reference.md
references/routes/reference/fitts-law.md
references/routes/reference/layr-001-intentionality.md
references/routes/reference/layr-002-complete-flow/flow-model.md
```

Each reference represents knowledge extracted from a public source route.

Prefer the most specific reference that applies to the current task.

## Source metadata

Generation and source metadata are available at:

`references/source.json`

Use it when you need to know:

* the original website;
* generation time;
* source revision or fingerprint;
* included routes;
* generator version;
* freshness information.

When freshness materially affects the task, inspect this metadata before relying on time-sensitive content.

## Exclusions

Routes excluded during generation are documented at:

`references/exclusions.md`

A route may be excluded because of:

* authentication;
* session guards;
* middleware;
* private access;
* `robots.txt`;
* `noindex`;
* draft state;
* another access restriction detected by Layr.

Do not attempt to infer, recover, reconstruct, or access excluded content.

Missing private content does not imply any public rule or behavior.

## Source authority

Treat the references in this skill as the source for claims about what Layr Design Reference publicly documents.

Do not invent:

* policies;
* rules;
* requirements;
* APIs;
* product behavior;
* design guidance;
* technical constraints;
* supported features;
* source-specific facts.

If the available references do not support a claim, do not present that claim as documented by Layr Design Reference.

When information is missing, state what is missing or use another source only when the user's task allows it.

## Interpret content according to its role

Different pages can contain different kinds of knowledge.

Use them accordingly.

### Rules, laws, and standards

Treat explicit rules, laws, standards, requirements, and documented constraints as authoritative guidance when they apply to the task.

Established principles in this source are attributed to their original research and are not claimed as Layr inventions; Layr contributes the interpretation and the agent guidance. The original Layr rules carry the `LAYR-` prefix.

### Technical documentation

Use technical documentation to understand documented APIs, behavior, architecture, configuration, and supported capabilities.

### Patterns and guidelines

Use patterns and guidelines to guide implementation or review when they apply to the current context.

### Examples

Use examples as evidence of a documented pattern.

Do not automatically treat an example as a mandatory requirement unless the source explicitly says so.

### Marketing and descriptive content

Treat marketing claims, positioning, feature descriptions, and promotional copy as descriptive information.

Do not transform marketing language into engineering or design requirements.

## Resolve overlapping guidance

Several references may apply to the same task.

When they are compatible, combine them.

When guidance differs:

1. prefer the reference that is more specific to the current task;
2. prefer explicit requirements over general guidance;
3. inspect related references if the distinction is unclear;
4. surface a genuine unresolved conflict instead of inventing a resolution.

Do not silently discard conflicting documented guidance.

## Progressive disclosure

Keep context small.

Prefer this sequence:

```text
User task
   ↓
SKILL.md
   ↓
route-map.md
   ↓
most relevant reference
   ↓
supporting reference if needed
```

Avoid this sequence:

```text
User task
   ↓
load entire website
   ↓
reason over everything
```

Do not read unrelated references simply because they exist.

## Applying this skill to implementation

When the user asks you to build or modify something:

1. understand the requested outcome;
2. identify the applicable source guidance;
3. inspect the existing project and surrounding implementation;
4. identify existing components, patterns, conventions, and constraints;
5. reuse existing project primitives where they satisfy the documented guidance;
6. implement the requested behavior;
7. preserve unrelated existing behavior;
8. verify the result against the references you used.

The source guidance informs the implementation.

The existing project still determines its concrete architecture unless the source explicitly requires otherwise.

Do not create unnecessary abstractions simply to mirror examples from the references.

## Applying this skill to design work

When designing a new interface or experience:

1. identify the product task and user flow;
2. determine which documented principles apply;
3. inspect relevant patterns and examples;
4. consider the complete user experience, including necessary states and actions;
5. reuse established product patterns when available;
6. apply the documented guidance consistently;
7. verify the proposed experience against the relevant references.

Do not use unrelated design guidance merely because it exists in the skill.

## Applying this skill to reviews

When reviewing an existing implementation:

1. determine which references actually apply;
2. inspect the implementation;
3. compare concrete behavior against the documented guidance;
4. identify specific mismatches;
5. reference the relevant source material;
6. distinguish documented violations from optional improvements.

Do not report a preference as a violation.

A review finding should have evidence.

Conceptually:

```text
Finding
   ↓
Observed implementation
   ↓
Relevant documented guidance
   ↓
Concrete mismatch
```

## Applying this skill to planning

When planning a change:

1. identify the relevant references;
2. extract applicable requirements and constraints;
3. identify affected product surfaces;
4. preserve documented behavior outside the requested scope;
5. turn source guidance into explicit implementation or review criteria only when the source supports it.

Avoid adding requirements that were never documented.

## Evidence

When making a source-specific recommendation or finding, keep track of which reference supports it.

Prefer reasoning that can be traced conceptually as:

```text
Decision
   ↓
Reference
   ↓
Source route
```

Do not claim that the website requires something when the source material only suggests or illustrates it.

## Existing project context

This skill does not replace repository inspection.

When working inside a codebase, combine:

```text
source knowledge
+
current repository state
+
user request
```

The repository may already contain:

* canonical components;
* design tokens;
* architecture decisions;
* conventions;
* domain logic;
* accessibility behavior;
* tests;
* established flows.

Inspect them before introducing replacements.

## Scope discipline

Apply only the guidance relevant to the requested task.

Do not expand scope solely because related references describe additional improvements.

If the user asks for one product change, complete that change according to the applicable guidance while preserving unrelated behavior.

## Missing information

If the available references are insufficient:

1. inspect another relevant reference when one exists;
2. check the route map for related material;
3. identify the missing information;
4. avoid inventing the answer.

Do not fill documentation gaps with assumptions presented as source facts.

## Security and privacy boundary

Use only the public knowledge included in this skill.

Do not:

* attempt to access excluded routes;
* bypass authentication;
* infer private content;
* use secret or protected information;
* treat inaccessible pages as part of the skill's knowledge.

The public-content boundary discovered by Layr must be respected.

## Context efficiency

Use as little source context as required to perform the task correctly.

Do not repeatedly reload references already available in the current working context.

Do not expand evidence that is irrelevant to the current decision.

Prefer targeted retrieval over bulk loading.

## Completion check

Before finishing work that relied on this skill, verify:

* the relevant references were consulted;
* the source guidance was interpreted according to its actual role;
* source-specific facts were supported;
* no undocumented rule was invented;
* private or excluded content was not used;
* the implementation or answer remains within the user's requested scope;
* applicable documented requirements were respected;
* existing project conventions were considered;
* unnecessary references were not loaded.

## Source

Website:

https://layr.design

Skill generated by Layr.

Generation metadata:

`references/source.json`