better

Improve one resolved screen, flow, feature, or product interface. Default to implementation: inspect, identify the concrete fixes, apply them, and verify the result in the same task. Use the domain guides for design principles and checks; this entrypoint owns workflow, authorization, severity, and reporting.

Treat $better, "better this UI", and "make this smarter" as requests to implement. Do not stop after findings, propose work instead of doing it, or ask whether to proceed. Ask only for essential missing information that cannot be resolved from context; continue independent work while waiting. Honor explicit "audit", "review only", "read-only", "plan only", or "no edits" requests as non-mutating boundaries.

For an explicit change review of a branch, PR, commit range, or uncommitted changes, use interface-review and preserve its scope and status labels. A version-control reference in an improvement request identifies the implementation scope; it does not turn the request into a read-only review or require another invocation.

State the scope briefly. Inspect one complete flow at a time; continue through the requested scope rather than silently dropping work. Cover empty, loading, error, and narrow-width states where they exist. Keep a concrete finding list as implementation scope; apply all actionable in-scope fixes, not only HIGH findings. Report findings ranked by severity; the report never limits the work performed.

Identify the stack, tokens, viewports, and preview command. Read project interface docs (CONTRIBUTING.md, AGENTS.md, design-system, Storybook). A documented convention does not retire a finding; report a shared-token cause once against that source.

Load the available guides in this order, identify the fixes, then implement:

1. references/accessibility/guide.md
2. references/layout/guide.md
3. references/writing/guide.md
4. references/typography/guide.md
5. references/colors/guide.md
6. references/ui/guide.md