Frontend App Builder

Use this skill to turn a frontend application request into a working, visually checked app. For new apps, dashboards, games, websites, product interfaces, tools, redesigns, and other visually driven UI work from scratch, act first as a senior front-end designer unless the user explicitly says not to use Image Gen for concepting: create a concrete visual direction, use the installed @imagegen skill to produce an overall interface, screen, dashboard, game, website, or hero concept, then implement the concept in code as faithfully as possible. Aim for high-taste, agency-quality, minimal design rather than maximal visual spectacle, except when the product or game genre calls for richer art direction. Use additional generated assets when they materially improve the implemented UI or are needed to match the generated concept. For app interfaces, implement the main functionality with believable local state and real interactions so the user can click through the core idea instead of only viewing a static mockup. The accepted concept is an implementation contract, not a moodboard: do not redesign, simplify, rename, reorder, or substitute it unless the user explicitly asks for a change. Keep working until the running app matches the generated concept closely enough to pass a professional design-agency inspection and the core workflow has been verified, or until you hit a concrete blocker that you report clearly. Always run the app and verify the result in a browser; use the Browser plugin / built-in app browser first whenever it is available, and only fall back to Playwright with Chromium when Browser/IAB is unavailable or demonstrably unreliable for the needed check.

Workflow

1. Read the existing app structure, scripts, styling system, and asset locations before editing.
2. Use a concept-first image generation pass for new apps, dashboards, games, websites, product interfaces, tools, redesigns, and visually described UI from scratch unless the user explicitly instructs you not to use Image Gen for concepting.
3. If the user asks to generate a concept first, review concepts, or hold implementation until approval, enter Concept Review Mode: generate and show the concept, iterate with the user until they are happy, and do not implement yet.
4. For concept-first implementation work, read and follow the installed @imagegen skill, then write a concise design-director brief and generate the overall app, dashboard, game, website, screen, redesign, or hero concept before implementation.
5. Choose one generated image as the accepted layout concept and keep its exact path visible in your notes. If multiple images were generated, label the rest as supporting assets and do not let them redefine the page structure.
6. Reject or iterate on generated concepts that are cluttered, overly decorative, under-specified, or trying to show too many product ideas at once.
7. Before coding, create a concept-to-implementation inventory from the accepted concept: native concept size/aspect, first-viewport composition, headline line breaks, nav/header geometry, brand mark, palette, type scale, panel/card topology, row counts, chart axes, drawers/rails, footer/status regions, asset roles, data/copy values, visible control states, and mobile continuation.
8. Define the minimum implementation plan, core interaction path, and asset list needed for the complete screen, page, or flow. Every visible concept element should map to code, an imagegen asset, or a clearly named intentional deviation.
9. If the accepted concept only shows part of the page or a single state, infer the remaining sections, states, and responsive views from the concept's visual language and implement them in the same design system.
10. Use the imagegen built-in tool path for missing visual assets such as logos, brand marks, hero imagery, product scenes, illustrations, textures, mockups, thumbnails, and empty-state art.
11. Treat the accepted concept as the visual spec. Extract layout, spacing, typography, palette, imagery, component shapes, interaction model, and responsive implications before coding.
12. Complete the inline preservation checklist below before coding; map every visible concept element to an implementation choice.
13. Implement the design in the app using the repo's existing framework, routing, component, styling, state, data, accessibility, and asset conventions.
14. Use imagegen again for individual project assets only to reproduce or isolate assets from the accepted concept, not to invent a new direction.
15. Add the main app functionality, thoughtful motion, and interactive visual behavior for concept elements that should feel alive, demonstrate the product, or reward exploration.
16. Run the app and use the Browser plugin / built-in app browser first for visual fidelity and interaction testing. If Browser/IAB is unavailable, cannot reach the local app, cannot capture the needed view, or produces unreliable screenshots such as broken fixed-header stitching, use Playwright with Chromium and record the fallback reason.
17. Perform an agency pass before final: compare the running UI against the accepted concept at the concept's native aspect/size when practical, a normal desktop viewport, and a mobile viewport. Name at least five concrete mismatches and fix them, or explicitly state that no material mismatches remain. Structural mismatches in topology, branding, copy, density, media behavior, or primary workflow block completion.
18. Verify the core workflow through the browser. Visible controls, media players, filters, forms, tabs, drawers, command palettes, canvas/game controls, and generated-result demos must update real local UI state; do not ship fake timecodes, inert buttons, hidden underlying media, or placeholder interactions.
19. Fix every material mismatch found during browser testing, then repeat the browser check. Keep iterating until the running app matches the concept and works as a product surface or a real blocker prevents further progress.
20. Do not send the final response or write any user-requested completion marker until the fidelity gate has passed with concrete evidence: accepted concept path, Browser/IAB verification method or Playwright fallback reason, mismatch list, fixes or blockers, and core workflow proof.
21. Before finishing, remove temporary QA-only files such as browser screenshots, fidelity reports, scratch notes, and intermediate generated assets unless the user explicitly asks to keep them or the task contract explicitly requires them. The accepted concept image may remain available for design iteration, and final assets used by the implementation must remain in the project's normal asset location.

Imagegen Coordination

• The installed @imagegen skill is the source of truth for image generation and editing mechanics. Use its built-in tool mode by default; never choose its CLI fallback unless the user explicitly asks for CLI mode.
• Every Image Gen concept prompt for a website, landing page, dashboard, product interface, app, tool, or game UI should explicitly ask for a clean interface that embraces whitespace, uses restrained content density, and avoids clutter unless the genre or user request calls for intentional density. Do not ask Image Gen to fill the page with extra cards, stats, badges, charts, icons, HUD elements, controls, or sections unless the user explicitly requests them or the game/product needs them.
• Classify new full-page, dashboard, app, game UI, and section concepts as ui-mockup unless another imagegen taxonomy slug is clearly more precise. For redesigns, use ui-mockup when the screenshot is only a reference, or an edit slug such as style-transfer when the screenshot is the imagegen edit target.
• Treat initial website concepts as preview or design-reference outputs, but do not lose track of the accepted concept. For concept-first implementation, keep the accepted concept reopenable by exact path. Do not cop