---
name: designwright-direction
description: Turn project evidence into an approved design direction.
license: MIT
---

# Designwright Direction

Use this skill to turn a user job, project evidence, and constraints into a reviewable design contract before implementation. It protects product-specific identity without treating a reference, a taste pack, or a familiar page pattern as a substitute for project evidence.

## When to use

Use it for greenfield identity, material brand or information-architecture change, a high-cost irreversible pattern, or any brief with two plausible structures that imply different user behavior. Use one direction for a constrained bug fix, a token-aligned routine state, or a component change already decided by current project memory.

## Procedure

1. State the job. Capture the named user, job to be done, critical journey, primary action, success behavior, content priorities, and any protected copy or behavior. Separate observed requirements from assumptions and hypotheses.
2. Read the project record. Use current human decisions, canonical project memory, verified components and tokens, responsive policy, accessibility policy, anti-references, and existing baselines as constraints. Do not replace local identity with a generic central style.
3. Inspect references safely. Record source, owner or permission, allowed use, capture date, and sensitivity. Extract design DNA such as hierarchy, density, type roles, color roles, structure, responsive transformations, and interaction intent. Do not copy text, assets, logos, signature compositions, or pixels. When using an external `DESIGN.md` collection as comparative research, follow [`references/comparative-reference-intake.md`](references/comparative-reference-intake.md): curate a small role-based packet, record only original principle-level observations, and preserve a project-specific transformation for every adopted signal.
4. Choose the direction count. For a material decision, propose two or three genuinely different structures or interaction theses. For a constrained change, explain why one direction is sufficient. Never manufacture alternatives after a direction has already been approved merely to create churn.
5. Write each direction as a contract. Include thesis, user and product fit, information hierarchy, content and state behavior, semantic type/color/spacing/geometry roles, responsive transformations, interaction and accessibility invariants, component-source plan, evidence gates, risks, and what must remain unchanged.
6. Apply the component policy. Name the capability needs rather than jumping to a component brand. Plan discovery in `project-local -> approved private -> approved curated external -> new` order and leave unresolved selection as an explicit decision, not a hidden assumption.
7. Make reference transformations visible. When a reference materially informs the proposal, name product-specific content or IA, project token or component mapping, and at least one distinct structural or interaction choice. These transformations are evidence of adaptation, not permission to clone.
8. Request approval at the right boundary. A human or project owner approves identity, direction, protected invariants, external references, new primitives, and baseline intent. Do not implement source code, install a dependency, or imply renderer support from a direction document.

## Direction contract

Return a selected or proposed contract containing:

- user, job, journey, goal, primary action, and success measure;
- direction ID, revision, thesis, rationale, and alternatives considered;
- hierarchy, content states, semantic system, responsive rules, and accessibility invariants;
- component needs and ordered source policy;
- reference records, permitted-use labels, extracted DNA, and non-cloning transformations;
- evidence required to accept the result;
- assumptions, unresolved questions, risks, and unchanged requirements;
- approver and status: proposed, selected, superseded, or deferred.

A selected direction is a design decision, not production approval. A target-family label does not prove that a renderer or adapter exists.

## Quality checks

Reject a direction that is generic without a project reason, contradicts current project memory without an explicit decision, hides an external source, relies on an unapproved component, silently weakens an accessibility or responsive requirement, or omits how the critical user action will be verified. Prefer a reversible, bounded slice over a broad visual rewrite.

## Verification

Another agent should be able to implement the approved slice without inventing hierarchy, tokens, states, components, or acceptance criteria. The contract must identify evidence for every material claim and must leave no unresolved decision disguised as a visual preference.