mirror of
https://github.com/Dvorinka/SEEN.git
synced 2026-06-05 04:53:01 +00:00
69 lines
4.3 KiB
Markdown
69 lines
4.3 KiB
Markdown
---
|
|
name: frontend-design
|
|
description: Create distinctive, production-grade frontend interfaces for web components, pages, dashboards, admin panels, marketing sites, product UIs, and full web apps. Use when Codex needs to design or implement HTML/CSS/JS or React/Vue/Tailwind frontends, especially when the request calls for strong visual direction, polished interactions, responsiveness, or avoiding generic AI aesthetics.
|
|
---
|
|
|
|
# Frontend Design
|
|
|
|
## Workflow
|
|
|
|
1. Inspect the product context, existing code, design tokens, component library, and brand cues before changing the UI.
|
|
2. Preserve the established visual language when the project already has one. If the surface is greenfield, choose one clear aesthetic direction and state it briefly before coding.
|
|
3. Build real, working UI. Do not stop at mockup language or decorative shells when the request implies production code.
|
|
4. Refine spacing, hierarchy, states, responsiveness, and accessibility until the result feels deliberate.
|
|
5. Verify the result in a browser or preview when possible, and fix visible layout issues before finishing.
|
|
|
|
## Art Direction
|
|
|
|
- Pick one visual thesis and commit to it: editorial, brutalist, industrial, retro-futuristic, soft tactile, luxury, playful, or another context-fit direction.
|
|
- Make at least one memorable decision in typography, composition, motion, texture, or layout.
|
|
- Match the interface to the product and audience. Boldness is optional; intentionality is not.
|
|
- Avoid generic SaaS defaults, especially purple-on-white gradients, interchangeable card grids, and library-demo layouts.
|
|
|
|
## Typography
|
|
|
|
- Prefer distinctive fonts over default UI stacks unless the repo already standardizes them.
|
|
- Avoid Arial, Inter, Roboto, Open Sans, Lato, and system UI defaults for greenfield work.
|
|
- Good directions include IBM Plex Sans, Source Sans 3, Newsreader, Fraunces, Syne, Bricolage Grotesque, and JetBrains Mono.
|
|
- Use one or two font families. Let size, weight, and rhythm create hierarchy.
|
|
- Favor high-contrast display/body pairings when the product tone allows it.
|
|
|
|
## Color and Surface
|
|
|
|
- Define a compact set of tokens or CSS variables before styling heavily.
|
|
- Choose a dominant palette with clear accent and contrast roles.
|
|
- Build atmosphere with gradients, glows, textures, grids, patterns, or shadows that reinforce the concept.
|
|
- Create focal points. Do not distribute colors evenly across every element.
|
|
- Avoid startup-blue or purple-gradient defaults unless the brand already uses them.
|
|
|
|
## Layout and Motion
|
|
|
|
- Compose with rhythm. Use asymmetry, overlap, density shifts, grid breaks, or negative space when they improve the result.
|
|
- Use motion sparingly but intentionally: a strong page-load reveal, good hover/focus states, and transitions that support hierarchy are usually enough.
|
|
- Avoid noisy animation, random bouncing, and microinteraction clutter.
|
|
- Check desktop and mobile layouts explicitly. Fix overflow, cramped sections, and awkward line wrapping.
|
|
|
|
## Implementation Rules
|
|
|
|
- Respect the requested stack. If none is specified, choose the smallest practical implementation that fits the task.
|
|
- Reuse existing components, tokens, and conventions when working inside an established codebase.
|
|
- Prefer semantic HTML, accessible controls, visible focus states, and sensible reduced-motion behavior.
|
|
- Ship complete states where relevant: hover, focus, active, disabled, empty, loading, and error.
|
|
- Keep code production-minded. Extract reusable patterns when the interface is more than a one-off section.
|
|
|
|
## Frontend-Specific Heuristics
|
|
|
|
- For React or Vue, follow project conventions first and avoid abstraction that the codebase does not need.
|
|
- For self-contained HTML/CSS/JS requests, keep the output easy to run and easy to inspect.
|
|
- For Tailwind projects, avoid utility soup. Create a coherent token system and composition style.
|
|
- For dashboards and admin tools, prioritize information hierarchy and density control over decoration.
|
|
- For landing pages and marketing surfaces, make the first screen memorable through typography, composition, and a clear call to action.
|
|
|
|
## Definition of Done
|
|
|
|
- The UI has a clear aesthetic point of view.
|
|
- The result does not look template-generated.
|
|
- The implementation is responsive and functional.
|
|
- Visual polish is visible in spacing, typography, states, and motion.
|
|
- The design fits the actual product context rather than a generic demo.
|