YankielDBC2 Frontend Production UI
Goal
Ship frontend changes that look polished, work across screen sizes, and remain maintainable.
When to use
Use for React components, app pages, design systems, responsive layouts, accessibility, animations, and production UI polish.
When not to use
Do not use for backend-only logic, database design, server security, or non-UI documentation.
Inputs
Inspect the affected component, nearby components, shared styles, design tokens, accessibility patterns, and tests or stories if they exist.
Workflow
- Find the existing UI pattern before creating a new one.
- Keep components small and composable.
- Separate state, data loading, and presentation when practical.
- Prefer semantic HTML and accessible controls.
- Preserve responsive behavior across mobile, tablet, and desktop.
- Avoid hardcoded magic values when tokens or variables exist.
- Check loading, empty, error, and success states.
- Keep animations purposeful and non-blocking.
Quality bar
Good UI code is readable, accessible, responsive, visually consistent, and does not duplicate existing component patterns.
Validation
Run relevant lint, typecheck, tests, component previews, and build. Manually inspect responsive states when possible.
Final response
Report files changed, UI behavior changed, validation commands, and any states that were not manually verified.