Learn enough for future UX work to start from intent and evidence instead of guesswork.

Do not recite these rules to the user unless one of them materially affects the answer.

Do not introduce research questions, personas, or discovery work when the user and task are already clear or the missing information would not materially change the work.

Determine whether this is a new project or an existing one. Infer the path when the available project makes it obvious. Otherwise ask one short question: is this a new project/product, or are we working with an existing one?

Do not create a second setup skill. Both paths end in the same small context layer.

There may be little useful project evidence yet, so begin with the user's idea in their own words. Ask only the next question whose answer could materially change what gets designed.

Useful areas to resolve, as needed, are:

Ask one or a small number of related questions at a time. Do not run a fixed questionnaire or require every heading to be complete before work can start.

Write first once the intent is concrete enough to guide decisions. Show the useful synthesis to the designer and let corrections override inference.

Explore the repository and connected sources before asking questions. Inspect what is available: README and product docs, existing user research, analytics and support evidence, package files, Storybook, components, tokens, design-system docs, Figma or other connected design sources, accessibility guidance, issue/PR templates, and existing decisions.

Reconstruct a draft of product intent from authoritative evidence, but keep current behavior separate from intended outcome. Code can prove that a flow exists; it usually cannot prove why the organization chose it.

Ask only about material gaps, conflicts, or intent that cannot be established reliably. Do not ask the user for information you can discover.

If an older directory contains only , , and , preserve those files and add ; do not rewrite established context merely to match the new structure.

Create or refresh the smallest useful core:

.ux/
├── INTENT.md
├── CONTEXT.md
├── DESIGN-SYSTEM.md
└── DECISIONS.md

Read for ownership, templates, evidence status, migration, intent updates, and when a project justifies splitting context into smaller files.

Owns why the product or capability exists, intended outcome, people affected, core task/experience, current scope and non-goals, material constraints, success when known, and material assumptions or unknowns.

Keep it short. It is a north star, not a PRD.

Owns the operating environment: observable product mechanics, major journeys, evidence locations, engineering stack and workflow, accessibility expectations, terminology, and stable project facts that help future UX work.

Do not duplicate intent just because both files mention the product.

Record the actual design-system sources and rules: Storybook, Figma, component packages, tokens, source-of-truth order, reuse expectations, and contribution path.

Keep a lightweight index of consequential UX or architecture decisions. If the project already has ADRs or another decision system, point to that instead of creating a competing one.

Do not create a research repository, persona library, journey catalog, or constraints folder during setup by default.

Split information into smaller files only when density, repeated use, or distinct ownership makes the split useful. Examples include , , or for projects that genuinely need them.

Future skills should load when product purpose, outcome, scope, or success can change the answer, then load only the additional context relevant to the task. Do not treat the whole directory as mandatory context for every request.

is not part of setup and is not a fifth core context file. A future agent may create it only for substantial multi-step work when continuity would otherwise be lost. It is disposable working state, not durable product truth.

Do not block setup because something is unknown. Ask only when an answer would materially change future recommendations.

Never turn assumptions into facts. Label claims about people, evidence, requirements, decisions, intent, and material unknowns as known, inferred, assumed, unknown, or conflicted when the distinction matters; ordinary product mechanics do not need labels.

Treat as stable, not frozen. Existing intent is the default and should survive routine design and implementation work.

Change it only when explicit human direction or authoritative evidence shows that the product's purpose, intended outcome, people, scope, non-goals, material constraints, or definition of success has actually changed. Make the smallest useful edit instead of regenerating the file.

A small clarification can be refined in place when it makes an already-established intent more precise without changing its meaning. A consequential change should preserve the decision or evidence that caused it in or the project's existing ADR/RFC system.

Never rewrite intent to rationalize the current implementation, remove an inconvenient constraint, or make completed work appear aligned after the fact. Agent inference alone does not override established intent.

Tell the designer what you learned, the few important gaps you found, and whether intent, user context, and the design system are sufficiently understood to start working.

Then stop. Do not turn setup into an audit or a discovery workshop.