context_uiux_design

Context UI/UX Design

Ownership

Own durable Design Authority only: root DESIGN.md, visual identity and exact-value token source/generation direction, visual rationale, canonical adopted-target interpretation/selection basis, adoption records, UI Authority Closure and selected-design alignment.

This Skill does not own product goals/business rules/acceptance (context_product_plan), information/action/feedback and main/drilldown responsibility (context_surface_contract), resource generation (design-resource-authoring), implementation, or acceptance. Route rather than duplicate those owners.

Project-specific UI/UX rules may live in <harnessRoot>/skills/uiux_design/SKILL.md; durable facts remain in DESIGN.md and owning project_context/**. When a valid Long-Task binding is active, long-task-workflow alone owns Source/Contract lifecycle, formal verification, Final Gate and completion. This Skill may contribute non-authoritative task-level UI/UX analysis and Design Authority closure, but creates no second plan, lifecycle, Authority, Gate or acceptance path.

Task-level analysis adapter

For a material task-analysis trigger, read task-uiux-analysis.md completely and apply only the relevant methods. This adapter is non-authoritative: Product/Surface/Screen Source owns the user, page duty, primary task/work object, information/action/feedback and interaction-topology facts; this Skill still owns durable Design Authority only. The current Goal may compare and select implementation candidates under those constraints. A conflicting candidate cannot proceed to resource generation or implementation until the stale owner is authoritatively updated or a genuine decision is obtained.

UI Authority Closure

1. Read core/default and owning surface/interaction Context, root DESIGN.md, its authored token source/generation direction, existing production route/components and every affected selected exact-target or constraint through its immutable locator. Run ty-context design-resource preflight <handoff.md> before treating a formal handoff as input.
2. Classify references as exact-target, constraint or inspiration. Inspiration authorizes no reproduction claim. Provider success, a hash/index or an implementation screenshot proves neither selection nor fidelity.
3. For every affected stable surface/control/target key, classify durable meaning as Context/DESIGN.md covered, requiring update, task-local, out of scope or decision-required. Conflicting, missing, stale, unreadable or unselected authority fails closed for the affected claim.
4. Confirm exactly one canonical adoption record per adopted target:
   • project/system/component-family targets are fully owned by DESIGN.md;
   • screen/interaction targets are fully owned by the owning Screen Contract, with DESIGN.md keeping only the stable key and owner/anchor;
   • the record preserves interpretation, selection basis, immutable path/URI and digest, applicable conditions and editable upstream owner/locator/update route.
5. Never overwrite an adopted baseline. Create a new immutable version/digest, review it deliberately and update the unique canonical record. An implementation render/diff is evidence and cannot become the target it claims to match.
6. Decide exactly one Context Delta: none|required. Skill activation, analysis, audit or candidate comparison alone authorizes no durable write. Durable visual-system, token, rationale, adopted interpretation, owner/anchor or verification-route change is required; ordinary UI/CSS fixes that preserve authority are none. When product/UI implementation is already authorized and the current Goal independently finds a durable Surface/Screen change, update the smallest owning Surface Context before code or return decision-required.
7. Route unresolved surface placement to context_surface_contract; route any request to generate/iterate a wireframe, prototype, visual candidate, state study or handoff to design-resource-authoring. Do not invoke resource generation implicitly.