ui-engineeringlisted

# UI Engineering A relevant UI task is not complete merely because source tests pass. Follow the product's design authority while composing the interface, then inspect the rendered affected journey through the provider's qualified browser capability. ## Design authority Before designing or changing a UI, read the repository-owned design principles, frontend instructions, tokens, shared primitives, and known-good reference screens that apply to the surface. Repository and user requirements outrank external examples. - Reuse local components and patterns before creating another implementation of the same idea. - Preserve the product's established hierarchy, typography, spacing, colour, radii, density, interaction, accessibility, and responsive conventions. - Do not introduce a new visual language because an external component is attractive in isolation. - When repairing an existing surface, prefer the smallest change that restores consistency with the established system. If the repository has no design contract yet and the task is genuinely greenfield, establish the smallest useful project-local foundation before multiplying page-specific choices: core tokens, typography, layout rules, shared controls, and one or more reference surfaces. Keep product taste in the repository, not in this reusable Skill. ## Component composition Use this order for new UI patterns: 1. Inspect local shared primitives and nearby canonical surfaces. 2. Reuse or extend a suitable local primiti