[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-openai-frontend-app-builder":3,"mdc--m1c0ci-key":39,"related-repo-openai-frontend-app-builder":899,"related-org-openai-frontend-app-builder":1017},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":28,"repoUrl":29,"updatedAt":30,"license":31,"forks":32,"topics":33,"repo":34,"sourceUrl":37,"mdContent":38},"frontend-app-builder","build visually driven frontend applications","Use for new frontend applications, dashboards, games, creative websites, hero sections, and visually driven UI from scratch, or when the user explicitly asks for a redesign\u002Frestyle\u002Fmodernization. Builds from clean, airy, high-taste, readable image-generated concept design with section-specific references, faithful implementation, and browser testing.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"openai","OpenAI","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fopenai.png",[12,16,19,22,25],{"name":13,"slug":14,"type":15},"React","react","tag",{"name":17,"slug":18,"type":15},"Tailwind CSS","tailwind-css",{"name":20,"slug":21,"type":15},"Web Development","web-development",{"name":23,"slug":24,"type":15},"Frontend","frontend",{"name":26,"slug":27,"type":15},"Design","design",3992,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fplugins","2026-04-24T05:14:28.798891",null,465,[],{"repoUrl":29,"stars":28,"forks":32,"topics":35,"description":36},[],"OpenAI Plugins","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fplugins\u002Ftree\u002FHEAD\u002Fplugins\u002Fbuild-web-apps\u002Fskills\u002Ffrontend-app-builder","---\nname: frontend-app-builder\ndescription: Use for new frontend applications, dashboards, games, creative websites, hero sections, and visually driven UI from scratch, or when the user explicitly asks for a redesign\u002Frestyle\u002Fmodernization. Builds from clean, airy, high-taste, readable image-generated concept design with section-specific references, faithful implementation, and browser testing.\n---\n\n# Frontend App Builder\n\nUse this skill to create polished frontend apps, dashboards, games, creative websites, hero sections, redesigns, and other visually driven UI. Act first as a senior front-end designer, then as an engineer implementing an approved design spec.\n\n## Core Standard\n\nThe two priorities of this skill outrank everything else:\n\n1. Create enough great-looking Image Gen design first: clean, airy, distinctive, complete, readable, section-specific when needed, and not repetitive by default.\n2. Do not stop until the accepted design and browser implementation match 10\u002F10. Keep fixing visual, interaction, responsive, asset, and typography mismatches until `view_image` comparison would pass agency sign-off.\n\n## Hard Rules\n\n1. Use Image Gen for the visual concept unless the user explicitly opts out or the task is a small UI fix inside an existing design system.\n2. Design the complete requested surface before coding. For a full page, app, dashboard, game, or product interface, a header or hero concept is not enough. For multi-section websites and long landing pages, prefer coordinated section-by-section concepts, plus an optional overview for rhythm, over one tall image that loses detail. For apps, dashboards, games, or compact product surfaces, generate the full primary screen plus any needed state, responsive, or asset concepts first.\n3. Inside Codex, default multi-section website concepting to one fresh, large, readable Image Gen screenshot per major section. If the request has 1-10 sections, expect roughly 1-10 primary section images. Generate additional section\u002Fdetail screenshots whenever text, buttons, card anatomy, typography, spacing, or colors are too small to extract. Do not crop or zoom an old full-page image as the main reference; regenerate a fresh standalone section or detail image that preserves the same design system.\n4. In Plan mode, generate the design first, then use `request_user_input` to get design approval before planning implementation details.\n5. Once accepted, the concept is a production design spec. No creative liberties during implementation: do not reinterpret layout, visible copy, hierarchy, container model, styling, imagery, density, or sections unless the user approves it or a concrete blocker requires it. General design heuristics never override the accepted concept.\n6. The completion bar is agency-signoff faithful implementation: 10\u002F10 fidelity to the accepted spec plus production-quality code. If the browser-rendered UI would receive design-review comments, keep fixing it.\n7. Before coding, build a small design system from the accepted image: tokens, typography, component families, variants, spacing, icon treatment, and container rules. Include both content typography and UI chrome typography for tools, editors, and dashboards. Implement from that system so repeated elements stay consistent.\n8. For new complex app UIs such as dashboards, admin tools, editors, data-heavy tools, and multi-panel product surfaces, default to React + Vite unless the user specifies another framework, the existing repo already dictates one, or the task is explicitly a single-file\u002Fstatic deliverable.\n9. Hero eyebrow, kicker, pretitle, badge, or pill labels above the main heading are prohibited by default. Use one only when the user explicitly requested it or the accepted\u002Freference design already contains it.\n10. Verify in the Browser plugin \u002F built-in browser first. Use Playwright Chromium only when Browser\u002FIAB is unavailable or unreliable, and state the fallback reason.\n11. Final handoff is blocked until you use `view_image` on both the accepted concept and the latest browser screenshot. This cannot be skipped or replaced with browser inspection alone. Judge the pair directly: is this agency-signoff faithfully implemented, and would a great, highly skilled design agency sign off on this exact implementation of the accepted design? If not, keep fixing.\n12. Remove temporary QA artifacts before handoff unless the user or task explicitly asks to keep them.\n\n## Coordinate With Other Installed Skills\n\nThis skill owns visual concepting and faithful frontend implementation. Use other installed skills when the app needs capabilities outside frontend design. Provider setup should not block Image Gen concepting, static UI work, or design review that does not exercise provider-backed behavior, but implementation and verification of provider-backed behavior should coordinate through the installed skill for that capability. Avoid placeholder setup instructions when another installed skill covers that setup.\n\nFor AI\u002Fmodel-generated output, use `openai-developers:openai-platform-api-key` when available unless the user names another provider or explicitly says not to use OpenAI. When that skill is available, always use its credential flow instead of fake keys, placeholder env vars, or manual API-key setup instructions.\n\n## Image Gen Workflow\n\nRead and follow the installed @imagegen skill. For website-specific briefing guidance, use `references\u002Fimagegen-website-concepts.md`.\n\nBefore calling Image Gen:\n\n- Copy the user's concrete requirements into the brief: product\u002Fpage purpose, audience, required sections or states, workflow, supplied copy, nav labels, CTA labels, data fields, required media, responsive needs, and implementation constraints.\n- Ask for the complete requested surface: full page, app screen, dashboard, game screen, or coordinated section\u002Fstate set. If the deliverable is more than a hero, say the concept must include downstream sections, states, or responsive continuation. If the section count is known or implied, name each section\u002Fstate that needs its own concept screenshot.\n- Repeat the implementation constraints: code-native app UI text and controls, fully rendered product\u002Fbackground assets with their own text and branding when appropriate, separable assets, reusable component families, intentional container model, no default card grids, no invented hero eyebrows\u002Fkickers\u002Fbadges\u002Fpills, and practical HTML\u002FCSS\u002Fcomponent implementation.\n- Preserve information architecture from user content, screenshots, or existing apps. Do not let Image Gen invent unrelated sections, fake metrics, new product claims, extra dashboards, new navigation, or a different product story.\n- For multi-section websites or long landing pages, default to one coordinated concept image per major section. Use an optional overview only for structure and rhythm; never rely on one giant compressed board when it makes text, button details, card structure, spacing, or typography hard to analyze.\n- For dense apps, dashboards, editors, product surfaces, and complex sections, generate separate state or detail concepts for the areas that would become unreadable in a single full-screen image: tables, sidebars, inspectors, modals, toolbars, charts, forms, cards, pricing blocks, testimonials, or media modules.\n- If any concept screenshot is too small, blurry, cropped, crowded, or ambiguous for implementation, generate a fresh standalone section\u002Fstate\u002Fdetail screenshot before coding. Keep the same palette, typography mood, component family, asset treatment, density, and section order. Do not crop, slice, zoom, or reuse a tiny part of an earlier image as the source of truth.\n- For games, plan a dedicated Image Gen asset pass in addition to the concept: transparent character\u002Fstate sprites or sprite sheet, terrain\u002Fplatform tiles, collectibles, hazards, goal\u002Fcheckpoint objects, props, and 2-3 parallax\u002Fbackground layers when the environment has depth. HUD text, scoring, controls, physics, and collision remain code-native.\n\nReject or iterate on concepts that are header-only for a full-surface ask, cluttered, generic, repetitive, under-specified, unreadable, over-decorated, off-spec with hero eyebrows\u002Fkickers\u002Fbadges\u002Fpills not explicitly requested or present in the reference, or not practical to implement faithfully.\n\n## Design Quality Bar\n\nThe concept should look like a professional product mockup by a senior product designer:\n\n- One clear creative idea or visual point of view.\n- Strong first viewport with clear offer, product signal, and primary action.\n- Full-page rhythm: sections, states, transitions, and mobile views feel designed as one system, without repetitive card stacks or repeated section formulas.\n- Cohesive section-to-section flow: connect sections with shared spacing, palette, type rhythm, media treatment, and subtle transitions, not by inventing major new UI components.\n- Excellent typography: clear hierarchy, scale, weight, line height, label treatment, and control\u002Fchrome text that never falls back to browser-default sizing.\n- Intentional whitespace and density; no filler cards, hero eyebrow\u002Fkicker labels, pills, badges, fake metrics, or icon rows unless explicitly requested or present in the accepted design.\n- Simpler by default: use fewer, stronger visual elements instead of filling the page with illustrations, iconography, decorative widgets, or complex UI chrome.\n- Coherent visual system: palette, spacing, radius, borders, shadows, gradients, icon style, imagery, and component geometry.\n- Icon fidelity matters when icons are present. Match the accepted design's icon metaphor, stroke weight, fill style, corner shape, size, color, alignment, and spacing instead of swapping in generic nearby icons.\n- Color fidelity is mandatory. Match the accepted design's actual background, surface, text, border, shadow, and accent colors; if the design uses a white background, use white rather than cream, ivory, beige, warm gray, or any softened off-white substitute.\n- Hero media treatment must match the accepted design. If the hero image has no color overlay or tint in the concept, the implementation must not add one. Use edge fades, masks, or background gradients only to blend image edges into the page; do not wash the image with a color overlay.\n- High-quality generated assets for logos, brand marks, hero imagery, product renders, background scenes, illustrations, textures, posters, avatars, empty states, and game sprites\u002Ftiles\u002Fbackground layers. Product\u002Fbackground assets should be fully rendered with consistent branding and in-image text when that text belongs to the asset.\n- Purposeful motion that clarifies hierarchy, reveals state, or makes the product feel tangible.\n- Specific, non-generic copy when the user has not provided exact copy.\n\nDefault to clean, airy, tasteful 7\u002F10 creativity: distinctive enough to feel designed, restrained enough to build, and not repetitive. Interpret \"clean\" as edited and legible, not empty or sterile.\n\n## Visual Direction Defaults\n\nUse these defaults when the user has not given stronger art direction. Adapt them to the product type instead of forcing every app into a marketing-site style.\n\n- Baseline: roughly 7\u002F10 creativity, low-to-medium density, generous spacing, high implementation clarity, high typography discipline, and image-led moments when the domain benefits from real visuals.\n- Before generating concepts, choose a coherent visual direction: one theme paradigm, background character, typography character, hero or primary-screen architecture, section\u002Fapp rhythm, 2-4 signature component motifs, and 1-2 motion cues. Commit to the combination so the design feels intentional instead of a generic template.\n- Hero or first viewport: keep one obvious focal point, a short readable headline or primary task, restrained supporting copy, a visible primary action, and enough negative space to work on a small laptop. Do not overcrowd the opening view with stats, chips, badges, fake controls, or competing mini-panels.\n- Header simplicity: default to a clean brand mark, essential navigation, and one primary action or control. Avoid icon-heavy nav, extra buttons, search bars, status widgets, segmented controls, decorative illustrations, or dense product chrome in the header unless the user explicitly asks for them or the product workflow requires them.\n- Visual economy: prefer one or two high-quality image or illustration moments over many small decorative visuals. Use iconography only where it clarifies navigation, controls, or product meaning.\n- Container discipline: avoid nested cards, giant rounded wrappers around every section, default bento\u002Fcard grids, and over-framed dashboards unless the concept or product type truly needs them. Prefer open layouts, bands, rails, lists, tables, canvases, or a single purposeful framing move.\n- Section rhythm: long pages should vary density, image-to-text ratio, alignment, scale, whitespace, and visual tempo while keeping one coherent brand system. Do not repeat the same centered block or left-text\u002Fright-card formula through the whole page.\n- Section continuity: when multiple section concepts need to become one page, use connective tissue from the existing design system: gutters, bands, alignment, repeated typography, recurring media frames, color rhythm, and small transitional spacing shifts. Do not invent major new carousels, accordions, pricing cards, dashboards, forms, nav systems, feature grids, or other component families unless the user requested them or the accepted concepts show them.\n- Media framing: generated imagery should usually sit in clear, implementation-friendly frames with stable aspect ratios, consistent crop logic, radius, shadows, and spacing. Avoid random image sizes or collage chaos unless the user explicitly asks for that direction.\n- UI restraints: small labels, utility pills, pseudo-system markers, fake metrics, and decorative dashboard jargon are allowed only when they clarify the product. If they are just visual filler, remove them before acceptance.\n\n## Concept Review Mode\n\nUse only when the user asks to generate concepts first, review options, or wait for approval.\n\n- Generate and show the concept.\n- Iterate until the user approves.\n- Do not implement while the user is still reviewing.\n- Once approved, treat the concept as the active spec and follow the fidelity workflow below.\n\n## Before Coding\n\nTurn the accepted concept into a design system and implementation inventory before coding:\n\n- Exact visible copy, nav items, CTA labels, section headings, proof points, data labels, and important UI text.\n- Per-section\u002Fstate image inventory: source concept screenshot, native aspect, visual priority, readable text, typography relationships, spacing, button\u002Fcontrol styling, component\u002Fcontainer rules, dominant colors, and any unresolved details that required a fresh extraction screenshot.\n- Allowed above-the-fold copy list: every visible hero, nav, eyebrow\u002Fkicker\u002Fpretitle, badge\u002Fpill, CTA, label, and proof string allowed from the accepted concept or user-provided copy.\n- First viewport composition, section order, downstream states, responsive continuation, and next-section preview.\n- Section continuity plan: how adjacent sections connect using the accepted design system, and which major component families are allowed. Treat unshown major components as prohibited unless the user requested them or a required workflow cannot function without them.\n- Brand mark, imagery roles, product mockups, dashboards, tables, charts, maps, media rails, forms, HUDs, or other visual artifacts.\n- Hero\u002Fmedia treatment inventory: whether each image has no overlay, a color overlay, a gradient overlay, edge fade, mask, transparent background, or matching background color. Record this explicitly before coding.\n- Standalone asset needs: if the concept includes a logo, brand mark, product label, packaging, poster, sign, product render, or branded background object, create matching standalone assets with Image Gen editing before implementation so branding stays coherent.\n- Game asset needs: if the concept is a game, create matching production art assets with Image Gen before implementation. Include transparent sprite\u002Fstate assets, tiles\u002Fplatforms, collectibles, hazards, goal objects, props, and parallax\u002Fbackground layers as needed; use code for collision boxes and game state, not as a substitute for visible art.\n- Design tokens sampled or approximated from the image: background, surface, text, muted text, border, shadow, accent, semantic colors, radii, elevation, spacing scale, and motion timing.\n- Color lock: explicitly identify whether the concept background is true white, off-white, cream, gray, dark, or tinted, then implement that exact choice. Do not warm up, cool down, mute, or otherwise \"tastefully\" reinterpret the palette.\n- Typography system: font family\u002Ffallback, type scale, weights, line heights, tracking, label treatment, heading\u002Fbody\u002Fcaption styles, control text styles, and responsive type behavior.\n- Icon inventory: every visible icon, glyph, chevron, logo-like mark, toolbar symbol, status symbol, and empty-state symbol; record meaning, source family, outline vs filled style, stroke width, size, color, container, alignment, spacing, and selected\u002Fhover\u002Fdisabled treatment.\n- Component families and variants: buttons, navigation, rows, panels, media frames, product mockups, cards only where present, tables, forms, chips, icons, empty states, responsive variants, hover\u002Ffocus\u002Fselected states.\n- Component architecture plan for complex app UIs: app shell, navigation, major feature regions, reusable UI primitives, data\u002Fstate helpers, chart\u002Ftable\u002Fform modules, asset modules, and responsive layout boundaries. A great front-end implementation should have clear component ownership, not one giant `App` component or one-off copied markup.\n- Container model: cards, panels, rails, bands, lists, tables, canvases, drawers, sidebars, modals, or full-bleed sections.\n- Core workflow: controls that must respond, selected states, filters, tabs, edits, creation flow, success state, playback, game controls, or generated-result demo.\n\nIf the concept omits required downstream sections, states, mobile views, or readable detail for a complex area, generate matching section\u002Fstate\u002Fdetail concepts when visual consistency or extraction is uncertain. Otherwise extend in the exact same visual system.\n\n## Implementation\n\n- Build the real usable surface first, not a marketing wrapper around a future app.\n- Follow the repo's framework, routing, component, styling, state, accessibility, and asset conventions.\n- When creating a new complex app UI without an existing framework constraint, use React + Vite by default. Structure it like a senior front-end engineer would: small focused components, a clear app shell, reusable primitives for repeated controls, feature-specific modules for dashboards\u002Ftables\u002Fcharts\u002Fforms, separated sample data and state helpers, and shared tokens\u002Fstyles. Keep `App` as composition glue instead of a monolithic screen implementation.\n- Implement through the design system extracted from the image. Similar elements must use the same component or shared style primitive; differences should be explicit variants, not one-off copied CSS.\n- Implement the accepted concept exactly. Preserve copy, hierarchy, section order, density, colors, typography, spacing, radii, borders, shadows, asset framing, and interaction model.\n- For multi-section pages, implement in slices that match the accepted section concepts. Start with the first viewport, compare its browser screenshot to the section concept, fix visible drift, then continue section by section. Do not defer all visual comparison until the whole page is coded, and do not merge or simplify section-specific design decisions just because a broad overview image is easier to follow.\n- Connect sections into one cohesive page without adding unapproved major UI components. Use spacing, background bands, alignment, typography rhythm, repeated motifs, and media framing to bridge gaps. Do not invent new carousels, accordions, pricing blocks, dashboards, forms, tab systems, feature-card grids, or other large components to make the page feel complete unless they appear in the accepted concept, were requested by the user, or are recorded as a concrete functional necessity.\n- Do not add new visible above-the-fold copy, hero eyebrows\u002Fkickers, explanatory labels, subtitles, or category text after concept acceptance unless it appears in the accepted concept, came from the user, or is recorded as an intentional deviation. If semantic HTML, SEO, or accessibility requires changing an H1 or heading level, change the element semantics first; do not invent compensating visible copy.\n- Do not add decorative hero eyebrow labels, pills, badges, gradients, glows, or overlays that were not in the accepted design. Do not substitute a gradient treatment unless it matches the concept's palette, direction, intensity, and placement. If the accepted hero image has no color overlay, do not add a translucent tint, wash, or colored layer over it. If the image needs help blending into a non-matching page background, use a matching asset, transparent cutout, edge fade, mask, or background gradient around the image rather than a color overlay on top of the image. Do not replace white backgrounds with cream\u002Foff-white or otherwise shift the accepted color temperature.\n- Define typography on controls deliberately. Do not rely on browser defaults or inherited `16px` sizing for buttons, tabs, inputs, toolbars, sidebars, inspector panels, layer rows, status bars, command palettes, or export\u002Fshare controls.\n- Preserve the container model. Do not add cards, bordered panels, floating containers, tiles, or card grids where the spec uses open whitespace, bands, rails, lists, tables, canvases, or full-bleed composition.\n- Keep real interactive app UI text, navigation, buttons, forms, tables, controls, and labels code-native. This does not apply to text and branding that belong inside product images, posters, packaging, signs, background scenes, hero photos, or other raster assets. Do not ship a static screenshot as UI.\n- Use Image Gen for central non-icon assets. Render product images and background assets completely with the needed text, logos, marks, labels, packaging, signage, and branding. When the asset must layer into the UI, request a transparent background or clean cutout. Quote exact asset text and require verbatim rendering when text matters.\n- If the accepted design includes branded product imagery, use Image Gen editing to create standalone versions of the logo\u002Fproduct\u002Fpackaging\u002Fsignage assets from the concept or a matching asset pass. Include transparent-background variants when those assets need to layer into the UI. Do not rebuild branded raster assets from generic CSS, mismatched fonts, or approximate labels.\n- For games, use Image Gen for visible production art: character\u002Fstate sprites or sprite sheets, terrain\u002Fplatform tiles, collectibles, hazards, goals\u002Fcheckpoints, foreground props, and parallax\u002Fbackground layers. Do not fall back to canvas-drawn shapes because collision, scaling, or animation is simpler. Keep HUD text, score, controls, hit boxes, physics, and game state code-native, and tune collision geometry to the rendered assets. Any code-drawn or vector game art must be listed as an intentional deviation or concrete blocker.\n- Do not replace concept assets with rough CSS drawings, generic gradients, placeholder SVGs, or stock-like crops. Images must sit naturally in the composition: background color, lighting, edges, crop, shadow, and transparency should blend with the surrounding design. SVG is fine for faithful icons and directional glyphs.\n- Use SVG\u002Ficon components for arrows, chevrons, carets, disclosure indicators, pagination arrows, and carousel arrows; do not use plain text glyphs unless the concept intentionally does.\n- Implement icons as faithfully as other visual elements. Prefer the repo's existing icon set or lucide only when it matches the accepted design's style; otherwise create a small custom SVG\u002Ficon variant that matches the concept. Custom SVG icons must be production-quality vector assets: clear `viewBox`, clean geometry, consistent stroke widths, aligned joins\u002Fcaps, balanced negative space, optical centering, scalable paths, no jagged or placeholder-looking shapes, and `currentColor` or explicit fills only when they match the design system. Do not replace filled icons with outline icons, rounded icons with sharp icons, thick strokes with thin strokes, or specific metaphors with generic symbols. Keep icon color, optical size, baseline alignment, padding, and interactive states consistent with the extracted icon inventory.\n- Make app interfaces experiential: local state, meaningful selected states, working filters\u002Ftabs\u002Fforms, editable or creatable items, success states, playback controls, game controls, or simulated generated output where appropriate.\n- Use interactive UI inside a hero only when it genuinely fits: SaaS\u002Fsoftware product previews, product demos, or purposeful interactive animation. Do not force fake interactive chrome into a branded, editorial, product, venue, food, consumer, or background-led hero. Faithful implementation and consistent branding are more important than adding interactivity.\n- Add motion only where it supports the design. Respect accessibility and `prefers-reduced-motion`.\n- Keep implementation production-oriented: semantic markup, stable responsive dimensions, no fragile hardcoded hacks, and type\u002Flint\u002Ftest checks when the repo supports them.\n\n## Verification\n\nRun the app and verify the visible product, not just the build.\n\n1. Use Browser\u002FIAB first. Load the app, inspect the first viewport, scroll, and click through the core workflow.\n2. Check desktop, current browser viewport, and a mobile-sized viewport.\n3. Capture or locate the accepted concept and the latest implementation screenshot. Use `view_image` on both in the same QA pass before final handoff; do not skip this step or substitute a browser glance for it.\n4. Capture the implementation at the accepted concept's native dimensions when practical. If not practical, record the blocker and also verify the current browser viewport.\n5. Write a fidelity ledger before final: mismatch, concept evidence, render evidence, and fix made or reason not fixed. For multi-section or multi-state specs, include evidence from the relevant section\u002Fstate concept screenshots, not only the overview. Inspect at least five concrete comparison points covering copy, layout, typography, palette\u002Fgradients, asset treatment, spacing\u002Fcontainer model, responsive behavior, or motion.\n6. Compare side by side for copy, nav, CTA labels, section order, first-viewport balance, next-section visibility, palette, gradient treatment, font personality, type scale, spacing, borders, radii, container model, asset\u002Fbackground blending, motion, and simulated interactions.\n7. Run an above-the-fold copy diff against the allowed copy list. Added, removed, renamed, or reordered visible copy must be fixed or listed as an intentional deviation; unapproved additions fail fidelity.\n8. Audit typography everywhere, not just the hero or main canvas. Check headings, body, captions, labels, toolbar controls, sidebar rows, tabs, inputs, inspector fields, status bars, command palettes, export\u002Fshare buttons, table cells, chart labels, and mobile line breaks. Use computed CSS sizes\u002Fweights\u002Fline-heights when the screenshot suggests drift.\n9. Audit icons wherever they appear: nav, buttons, cards, toolbar controls, sidebars, tables, status indicators, empty states, pagination, carousels, and mobile controls. Check metaphor, stroke\u002Ffill style, size, color, alignment, optical weight, spacing, and state changes against the accepted concept.\n10. For canvas\u002Feditor apps, audit app chrome separately from canvas\u002Fdocument text. Default zoom and pan are part of the spec; persisted local state must not hide seed, scale, or typography fixes during verification.\n11. Ask explicitly: is this agency-signoff faithfully implemented, and would a great, highly skilled design agency sign off on this exact implementation of the accepted design? If anything would get a design-review comment, write a concrete repair checklist and keep editing. Do not final-answer with fixable visual issues.\n12. Verify generated assets load, are framed correctly, and do not obscure text or controls.\n13. Verify the core workflow updates real local UI state. Do not ship inert controls, fake media progress, hidden required media, or placeholder interactions.\n\nFunctional QA does not count as fidelity QA. Passing build checks, clicking controls, or verifying local state cannot replace the concept-to-screenshot comparison, native-size check, and written mismatch ledger.\n\nHard stops: clipped primary content, accidental wrapping, prototype-looking layout, rough seeded data, placeholder boxes, generic stock-like assets, unfinished cards, code-drawn game placeholders replacing concept art, invented visible copy, invented hero eyebrows\u002Fkickers\u002Fpills\u002Fbadges, mismatched colors or gradients, white backgrounds changed to cream\u002Foff-white, unapproved hero image color overlays or tints, missing or generic substituted icons, mismatched icon style or stroke weight, images that do not blend with the background, stale debug artifacts, unreadable text, type-scale drift, browser-default control typography, mobile overflow, unprofessional responsive collapse, or any visible drift from the accepted spec.\n\n## Surface Gates\n\n- Landing\u002Fcompany sites: preserve first viewport, hero role, brand\u002Fnav\u002FCTA labels, section order, next-section preview, and signature imagery.\n- Product\u002FSaaS pages: preserve product mockups, workflow diagrams, feature strips, proof elements, and brand treatment.\n- Dashboards\u002Ftools: preserve density, sidebars, headers, tables, tabs, timelines, charts, maps, row counts, and selected\u002Fdetail behavior. Do not turn table-driven concepts into card grids.\n- Canvas\u002Feditor tools: preserve default zoom\u002Fpan, canvas\u002Fdocument text scale, chrome density, toolbars, sidebars, inspector controls, layer rows, status bars, command surfaces, and autosaved\u002Fseed-state behavior.\n- Timeline\u002Fplanning tools: preserve grid\u002Ftime-axis anatomy, row spans, event density, status rails, and command-center fit.\n- Clone-like interfaces: preserve the recognizable skeleton before adding polish. Do not add marketing heroes or custom navigation that breaks the product type.\n- Games: preserve the art direction with Image Gen assets for sprites, tiles\u002Fplatforms, collectibles, hazards, goals\u002Fcheckpoints, props, and background\u002Fparallax layers. Verify assets load, scale, animate or swap state correctly, align with collision geometry, and support movement, action\u002Fjump\u002Fdrag behavior, scoring, hazards, and restart.\n- Media surfaces: verify real media load, duration, play\u002Fpause, seek\u002Fprogress, and visible frame changes.\n- Forms\u002Fbooking\u002Fpurchase\u002Frestaurant flows: verify the main transaction path and confirmation state.\n\n## Final Response\n\nInclude the accepted concept path, rendered screenshot method, Browser\u002FIAB verification method or Playwright fallback reason, `view_image` inspection of the accepted concept and latest implementation screenshot, native-size viewport checked or blocker, at least five inspected comparison points, above-the-fold copy diff result, remaining intentional deviations, and an explicit statement that the implementation was faithfully verified against the accepted design. Also include material mismatches fixed and core interaction path verified. If no material mismatches remain, say so directly.\n",{"data":40,"body":41},{"name":4,"description":6},{"type":42,"children":43},"root",[44,52,58,65,70,94,100,178,184,189,202,208,221,226,270,275,281,286,359,364,370,375,428,434,439,462,468,473,569,574,580,731,737,742,817,822,827,833,881,887],{"type":45,"tag":46,"props":47,"children":48},"element","h1",{"id":4},[49],{"type":50,"value":51},"text","Frontend App Builder",{"type":45,"tag":53,"props":54,"children":55},"p",{},[56],{"type":50,"value":57},"Use this skill to create polished frontend apps, dashboards, games, creative websites, hero sections, redesigns, and other visually driven UI. Act first as a senior front-end designer, then as an engineer implementing an approved design spec.",{"type":45,"tag":59,"props":60,"children":62},"h2",{"id":61},"core-standard",[63],{"type":50,"value":64},"Core Standard",{"type":45,"tag":53,"props":66,"children":67},{},[68],{"type":50,"value":69},"The two priorities of this skill outrank everything else:",{"type":45,"tag":71,"props":72,"children":73},"ol",{},[74,80],{"type":45,"tag":75,"props":76,"children":77},"li",{},[78],{"type":50,"value":79},"Create enough great-looking Image Gen design first: clean, airy, distinctive, complete, readable, section-specific when needed, and not repetitive by default.",{"type":45,"tag":75,"props":81,"children":82},{},[83,85,92],{"type":50,"value":84},"Do not stop until the accepted design and browser implementation match 10\u002F10. Keep fixing visual, interaction, responsive, asset, and typography mismatches until ",{"type":45,"tag":86,"props":87,"children":89},"code",{"className":88},[],[90],{"type":50,"value":91},"view_image",{"type":50,"value":93}," comparison would pass agency sign-off.",{"type":45,"tag":59,"props":95,"children":97},{"id":96},"hard-rules",[98],{"type":50,"value":99},"Hard Rules",{"type":45,"tag":71,"props":101,"children":102},{},[103,108,113,118,131,136,141,146,151,156,161,173],{"type":45,"tag":75,"props":104,"children":105},{},[106],{"type":50,"value":107},"Use Image Gen for the visual concept unless the user explicitly opts out or the task is a small UI fix inside an existing design system.",{"type":45,"tag":75,"props":109,"children":110},{},[111],{"type":50,"value":112},"Design the complete requested surface before coding. For a full page, app, dashboard, game, or product interface, a header or hero concept is not enough. For multi-section websites and long landing pages, prefer coordinated section-by-section concepts, plus an optional overview for rhythm, over one tall image that loses detail. For apps, dashboards, games, or compact product surfaces, generate the full primary screen plus any needed state, responsive, or asset concepts first.",{"type":45,"tag":75,"props":114,"children":115},{},[116],{"type":50,"value":117},"Inside Codex, default multi-section website concepting to one fresh, large, readable Image Gen screenshot per major section. If the request has 1-10 sections, expect roughly 1-10 primary section images. Generate additional section\u002Fdetail screenshots whenever text, buttons, card anatomy, typography, spacing, or colors are too small to extract. Do not crop or zoom an old full-page image as the main reference; regenerate a fresh standalone section or detail image that preserves the same design system.",{"type":45,"tag":75,"props":119,"children":120},{},[121,123,129],{"type":50,"value":122},"In Plan mode, generate the design first, then use ",{"type":45,"tag":86,"props":124,"children":126},{"className":125},[],[127],{"type":50,"value":128},"request_user_input",{"type":50,"value":130}," to get design approval before planning implementation details.",{"type":45,"tag":75,"props":132,"children":133},{},[134],{"type":50,"value":135},"Once accepted, the concept is a production design spec. No creative liberties during implementation: do not reinterpret layout, visible copy, hierarchy, container model, styling, imagery, density, or sections unless the user approves it or a concrete blocker requires it. General design heuristics never override the accepted concept.",{"type":45,"tag":75,"props":137,"children":138},{},[139],{"type":50,"value":140},"The completion bar is agency-signoff faithful implementation: 10\u002F10 fidelity to the accepted spec plus production-quality code. If the browser-rendered UI would receive design-review comments, keep fixing it.",{"type":45,"tag":75,"props":142,"children":143},{},[144],{"type":50,"value":145},"Before coding, build a small design system from the accepted image: tokens, typography, component families, variants, spacing, icon treatment, and container rules. Include both content typography and UI chrome typography for tools, editors, and dashboards. Implement from that system so repeated elements stay consistent.",{"type":45,"tag":75,"props":147,"children":148},{},[149],{"type":50,"value":150},"For new complex app UIs such as dashboards, admin tools, editors, data-heavy tools, and multi-panel product surfaces, default to React + Vite unless the user specifies another framework, the existing repo already dictates one, or the task is explicitly a single-file\u002Fstatic deliverable.",{"type":45,"tag":75,"props":152,"children":153},{},[154],{"type":50,"value":155},"Hero eyebrow, kicker, pretitle, badge, or pill labels above the main heading are prohibited by default. Use one only when the user explicitly requested it or the accepted\u002Freference design already contains it.",{"type":45,"tag":75,"props":157,"children":158},{},[159],{"type":50,"value":160},"Verify in the Browser plugin \u002F built-in browser first. Use Playwright Chromium only when Browser\u002FIAB is unavailable or unreliable, and state the fallback reason.",{"type":45,"tag":75,"props":162,"children":163},{},[164,166,171],{"type":50,"value":165},"Final handoff is blocked until you use ",{"type":45,"tag":86,"props":167,"children":169},{"className":168},[],[170],{"type":50,"value":91},{"type":50,"value":172}," on both the accepted concept and the latest browser screenshot. This cannot be skipped or replaced with browser inspection alone. Judge the pair directly: is this agency-signoff faithfully implemented, and would a great, highly skilled design agency sign off on this exact implementation of the accepted design? If not, keep fixing.",{"type":45,"tag":75,"props":174,"children":175},{},[176],{"type":50,"value":177},"Remove temporary QA artifacts before handoff unless the user or task explicitly asks to keep them.",{"type":45,"tag":59,"props":179,"children":181},{"id":180},"coordinate-with-other-installed-skills",[182],{"type":50,"value":183},"Coordinate With Other Installed Skills",{"type":45,"tag":53,"props":185,"children":186},{},[187],{"type":50,"value":188},"This skill owns visual concepting and faithful frontend implementation. Use other installed skills when the app needs capabilities outside frontend design. Provider setup should not block Image Gen concepting, static UI work, or design review that does not exercise provider-backed behavior, but implementation and verification of provider-backed behavior should coordinate through the installed skill for that capability. Avoid placeholder setup instructions when another installed skill covers that setup.",{"type":45,"tag":53,"props":190,"children":191},{},[192,194,200],{"type":50,"value":193},"For AI\u002Fmodel-generated output, use ",{"type":45,"tag":86,"props":195,"children":197},{"className":196},[],[198],{"type":50,"value":199},"openai-developers:openai-platform-api-key",{"type":50,"value":201}," when available unless the user names another provider or explicitly says not to use OpenAI. When that skill is available, always use its credential flow instead of fake keys, placeholder env vars, or manual API-key setup instructions.",{"type":45,"tag":59,"props":203,"children":205},{"id":204},"image-gen-workflow",[206],{"type":50,"value":207},"Image Gen Workflow",{"type":45,"tag":53,"props":209,"children":210},{},[211,213,219],{"type":50,"value":212},"Read and follow the installed @imagegen skill. For website-specific briefing guidance, use ",{"type":45,"tag":86,"props":214,"children":216},{"className":215},[],[217],{"type":50,"value":218},"references\u002Fimagegen-website-concepts.md",{"type":50,"value":220},".",{"type":45,"tag":53,"props":222,"children":223},{},[224],{"type":50,"value":225},"Before calling Image Gen:",{"type":45,"tag":227,"props":228,"children":229},"ul",{},[230,235,240,245,250,255,260,265],{"type":45,"tag":75,"props":231,"children":232},{},[233],{"type":50,"value":234},"Copy the user's concrete requirements into the brief: product\u002Fpage purpose, audience, required sections or states, workflow, supplied copy, nav labels, CTA labels, data fields, required media, responsive needs, and implementation constraints.",{"type":45,"tag":75,"props":236,"children":237},{},[238],{"type":50,"value":239},"Ask for the complete requested surface: full page, app screen, dashboard, game screen, or coordinated section\u002Fstate set. If the deliverable is more than a hero, say the concept must include downstream sections, states, or responsive continuation. If the section count is known or implied, name each section\u002Fstate that needs its own concept screenshot.",{"type":45,"tag":75,"props":241,"children":242},{},[243],{"type":50,"value":244},"Repeat the implementation constraints: code-native app UI text and controls, fully rendered product\u002Fbackground assets with their own text and branding when appropriate, separable assets, reusable component families, intentional container model, no default card grids, no invented hero eyebrows\u002Fkickers\u002Fbadges\u002Fpills, and practical HTML\u002FCSS\u002Fcomponent implementation.",{"type":45,"tag":75,"props":246,"children":247},{},[248],{"type":50,"value":249},"Preserve information architecture from user content, screenshots, or existing apps. Do not let Image Gen invent unrelated sections, fake metrics, new product claims, extra dashboards, new navigation, or a different product story.",{"type":45,"tag":75,"props":251,"children":252},{},[253],{"type":50,"value":254},"For multi-section websites or long landing pages, default to one coordinated concept image per major section. Use an optional overview only for structure and rhythm; never rely on one giant compressed board when it makes text, button details, card structure, spacing, or typography hard to analyze.",{"type":45,"tag":75,"props":256,"children":257},{},[258],{"type":50,"value":259},"For dense apps, dashboards, editors, product surfaces, and complex sections, generate separate state or detail concepts for the areas that would become unreadable in a single full-screen image: tables, sidebars, inspectors, modals, toolbars, charts, forms, cards, pricing blocks, testimonials, or media modules.",{"type":45,"tag":75,"props":261,"children":262},{},[263],{"type":50,"value":264},"If any concept screenshot is too small, blurry, cropped, crowded, or ambiguous for implementation, generate a fresh standalone section\u002Fstate\u002Fdetail screenshot before coding. Keep the same palette, typography mood, component family, asset treatment, density, and section order. Do not crop, slice, zoom, or reuse a tiny part of an earlier image as the source of truth.",{"type":45,"tag":75,"props":266,"children":267},{},[268],{"type":50,"value":269},"For games, plan a dedicated Image Gen asset pass in addition to the concept: transparent character\u002Fstate sprites or sprite sheet, terrain\u002Fplatform tiles, collectibles, hazards, goal\u002Fcheckpoint objects, props, and 2-3 parallax\u002Fbackground layers when the environment has depth. HUD text, scoring, controls, physics, and collision remain code-native.",{"type":45,"tag":53,"props":271,"children":272},{},[273],{"type":50,"value":274},"Reject or iterate on concepts that are header-only for a full-surface ask, cluttered, generic, repetitive, under-specified, unreadable, over-decorated, off-spec with hero eyebrows\u002Fkickers\u002Fbadges\u002Fpills not explicitly requested or present in the reference, or not practical to implement faithfully.",{"type":45,"tag":59,"props":276,"children":278},{"id":277},"design-quality-bar",[279],{"type":50,"value":280},"Design Quality Bar",{"type":45,"tag":53,"props":282,"children":283},{},[284],{"type":50,"value":285},"The concept should look like a professional product mockup by a senior product designer:",{"type":45,"tag":227,"props":287,"children":288},{},[289,294,299,304,309,314,319,324,329,334,339,344,349,354],{"type":45,"tag":75,"props":290,"children":291},{},[292],{"type":50,"value":293},"One clear creative idea or visual point of view.",{"type":45,"tag":75,"props":295,"children":296},{},[297],{"type":50,"value":298},"Strong first viewport with clear offer, product signal, and primary action.",{"type":45,"tag":75,"props":300,"children":301},{},[302],{"type":50,"value":303},"Full-page rhythm: sections, states, transitions, and mobile views feel designed as one system, without repetitive card stacks or repeated section formulas.",{"type":45,"tag":75,"props":305,"children":306},{},[307],{"type":50,"value":308},"Cohesive section-to-section flow: connect sections with shared spacing, palette, type rhythm, media treatment, and subtle transitions, not by inventing major new UI components.",{"type":45,"tag":75,"props":310,"children":311},{},[312],{"type":50,"value":313},"Excellent typography: clear hierarchy, scale, weight, line height, label treatment, and control\u002Fchrome text that never falls back to browser-default sizing.",{"type":45,"tag":75,"props":315,"children":316},{},[317],{"type":50,"value":318},"Intentional whitespace and density; no filler cards, hero eyebrow\u002Fkicker labels, pills, badges, fake metrics, or icon rows unless explicitly requested or present in the accepted design.",{"type":45,"tag":75,"props":320,"children":321},{},[322],{"type":50,"value":323},"Simpler by default: use fewer, stronger visual elements instead of filling the page with illustrations, iconography, decorative widgets, or complex UI chrome.",{"type":45,"tag":75,"props":325,"children":326},{},[327],{"type":50,"value":328},"Coherent visual system: palette, spacing, radius, borders, shadows, gradients, icon style, imagery, and component geometry.",{"type":45,"tag":75,"props":330,"children":331},{},[332],{"type":50,"value":333},"Icon fidelity matters when icons are present. Match the accepted design's icon metaphor, stroke weight, fill style, corner shape, size, color, alignment, and spacing instead of swapping in generic nearby icons.",{"type":45,"tag":75,"props":335,"children":336},{},[337],{"type":50,"value":338},"Color fidelity is mandatory. Match the accepted design's actual background, surface, text, border, shadow, and accent colors; if the design uses a white background, use white rather than cream, ivory, beige, warm gray, or any softened off-white substitute.",{"type":45,"tag":75,"props":340,"children":341},{},[342],{"type":50,"value":343},"Hero media treatment must match the accepted design. If the hero image has no color overlay or tint in the concept, the implementation must not add one. Use edge fades, masks, or background gradients only to blend image edges into the page; do not wash the image with a color overlay.",{"type":45,"tag":75,"props":345,"children":346},{},[347],{"type":50,"value":348},"High-quality generated assets for logos, brand marks, hero imagery, product renders, background scenes, illustrations, textures, posters, avatars, empty states, and game sprites\u002Ftiles\u002Fbackground layers. Product\u002Fbackground assets should be fully rendered with consistent branding and in-image text when that text belongs to the asset.",{"type":45,"tag":75,"props":350,"children":351},{},[352],{"type":50,"value":353},"Purposeful motion that clarifies hierarchy, reveals state, or makes the product feel tangible.",{"type":45,"tag":75,"props":355,"children":356},{},[357],{"type":50,"value":358},"Specific, non-generic copy when the user has not provided exact copy.",{"type":45,"tag":53,"props":360,"children":361},{},[362],{"type":50,"value":363},"Default to clean, airy, tasteful 7\u002F10 creativity: distinctive enough to feel designed, restrained enough to build, and not repetitive. Interpret \"clean\" as edited and legible, not empty or sterile.",{"type":45,"tag":59,"props":365,"children":367},{"id":366},"visual-direction-defaults",[368],{"type":50,"value":369},"Visual Direction Defaults",{"type":45,"tag":53,"props":371,"children":372},{},[373],{"type":50,"value":374},"Use these defaults when the user has not given stronger art direction. Adapt them to the product type instead of forcing every app into a marketing-site style.",{"type":45,"tag":227,"props":376,"children":377},{},[378,383,388,393,398,403,408,413,418,423],{"type":45,"tag":75,"props":379,"children":380},{},[381],{"type":50,"value":382},"Baseline: roughly 7\u002F10 creativity, low-to-medium density, generous spacing, high implementation clarity, high typography discipline, and image-led moments when the domain benefits from real visuals.",{"type":45,"tag":75,"props":384,"children":385},{},[386],{"type":50,"value":387},"Before generating concepts, choose a coherent visual direction: one theme paradigm, background character, typography character, hero or primary-screen architecture, section\u002Fapp rhythm, 2-4 signature component motifs, and 1-2 motion cues. Commit to the combination so the design feels intentional instead of a generic template.",{"type":45,"tag":75,"props":389,"children":390},{},[391],{"type":50,"value":392},"Hero or first viewport: keep one obvious focal point, a short readable headline or primary task, restrained supporting copy, a visible primary action, and enough negative space to work on a small laptop. Do not overcrowd the opening view with stats, chips, badges, fake controls, or competing mini-panels.",{"type":45,"tag":75,"props":394,"children":395},{},[396],{"type":50,"value":397},"Header simplicity: default to a clean brand mark, essential navigation, and one primary action or control. Avoid icon-heavy nav, extra buttons, search bars, status widgets, segmented controls, decorative illustrations, or dense product chrome in the header unless the user explicitly asks for them or the product workflow requires them.",{"type":45,"tag":75,"props":399,"children":400},{},[401],{"type":50,"value":402},"Visual economy: prefer one or two high-quality image or illustration moments over many small decorative visuals. Use iconography only where it clarifies navigation, controls, or product meaning.",{"type":45,"tag":75,"props":404,"children":405},{},[406],{"type":50,"value":407},"Container discipline: avoid nested cards, giant rounded wrappers around every section, default bento\u002Fcard grids, and over-framed dashboards unless the concept or product type truly needs them. Prefer open layouts, bands, rails, lists, tables, canvases, or a single purposeful framing move.",{"type":45,"tag":75,"props":409,"children":410},{},[411],{"type":50,"value":412},"Section rhythm: long pages should vary density, image-to-text ratio, alignment, scale, whitespace, and visual tempo while keeping one coherent brand system. Do not repeat the same centered block or left-text\u002Fright-card formula through the whole page.",{"type":45,"tag":75,"props":414,"children":415},{},[416],{"type":50,"value":417},"Section continuity: when multiple section concepts need to become one page, use connective tissue from the existing design system: gutters, bands, alignment, repeated typography, recurring media frames, color rhythm, and small transitional spacing shifts. Do not invent major new carousels, accordions, pricing cards, dashboards, forms, nav systems, feature grids, or other component families unless the user requested them or the accepted concepts show them.",{"type":45,"tag":75,"props":419,"children":420},{},[421],{"type":50,"value":422},"Media framing: generated imagery should usually sit in clear, implementation-friendly frames with stable aspect ratios, consistent crop logic, radius, shadows, and spacing. Avoid random image sizes or collage chaos unless the user explicitly asks for that direction.",{"type":45,"tag":75,"props":424,"children":425},{},[426],{"type":50,"value":427},"UI restraints: small labels, utility pills, pseudo-system markers, fake metrics, and decorative dashboard jargon are allowed only when they clarify the product. If they are just visual filler, remove them before acceptance.",{"type":45,"tag":59,"props":429,"children":431},{"id":430},"concept-review-mode",[432],{"type":50,"value":433},"Concept Review Mode",{"type":45,"tag":53,"props":435,"children":436},{},[437],{"type":50,"value":438},"Use only when the user asks to generate concepts first, review options, or wait for approval.",{"type":45,"tag":227,"props":440,"children":441},{},[442,447,452,457],{"type":45,"tag":75,"props":443,"children":444},{},[445],{"type":50,"value":446},"Generate and show the concept.",{"type":45,"tag":75,"props":448,"children":449},{},[450],{"type":50,"value":451},"Iterate until the user approves.",{"type":45,"tag":75,"props":453,"children":454},{},[455],{"type":50,"value":456},"Do not implement while the user is still reviewing.",{"type":45,"tag":75,"props":458,"children":459},{},[460],{"type":50,"value":461},"Once approved, treat the concept as the active spec and follow the fidelity workflow below.",{"type":45,"tag":59,"props":463,"children":465},{"id":464},"before-coding",[466],{"type":50,"value":467},"Before Coding",{"type":45,"tag":53,"props":469,"children":470},{},[471],{"type":50,"value":472},"Turn the accepted concept into a design system and implementation inventory before coding:",{"type":45,"tag":227,"props":474,"children":475},{},[476,481,486,491,496,501,506,511,516,521,526,531,536,541,546,559,564],{"type":45,"tag":75,"props":477,"children":478},{},[479],{"type":50,"value":480},"Exact visible copy, nav items, CTA labels, section headings, proof points, data labels, and important UI text.",{"type":45,"tag":75,"props":482,"children":483},{},[484],{"type":50,"value":485},"Per-section\u002Fstate image inventory: source concept screenshot, native aspect, visual priority, readable text, typography relationships, spacing, button\u002Fcontrol styling, component\u002Fcontainer rules, dominant colors, and any unresolved details that required a fresh extraction screenshot.",{"type":45,"tag":75,"props":487,"children":488},{},[489],{"type":50,"value":490},"Allowed above-the-fold copy list: every visible hero, nav, eyebrow\u002Fkicker\u002Fpretitle, badge\u002Fpill, CTA, label, and proof string allowed from the accepted concept or user-provided copy.",{"type":45,"tag":75,"props":492,"children":493},{},[494],{"type":50,"value":495},"First viewport composition, section order, downstream states, responsive continuation, and next-section preview.",{"type":45,"tag":75,"props":497,"children":498},{},[499],{"type":50,"value":500},"Section continuity plan: how adjacent sections connect using the accepted design system, and which major component families are allowed. Treat unshown major components as prohibited unless the user requested them or a required workflow cannot function without them.",{"type":45,"tag":75,"props":502,"children":503},{},[504],{"type":50,"value":505},"Brand mark, imagery roles, product mockups, dashboards, tables, charts, maps, media rails, forms, HUDs, or other visual artifacts.",{"type":45,"tag":75,"props":507,"children":508},{},[509],{"type":50,"value":510},"Hero\u002Fmedia treatment inventory: whether each image has no overlay, a color overlay, a gradient overlay, edge fade, mask, transparent background, or matching background color. Record this explicitly before coding.",{"type":45,"tag":75,"props":512,"children":513},{},[514],{"type":50,"value":515},"Standalone asset needs: if the concept includes a logo, brand mark, product label, packaging, poster, sign, product render, or branded background object, create matching standalone assets with Image Gen editing before implementation so branding stays coherent.",{"type":45,"tag":75,"props":517,"children":518},{},[519],{"type":50,"value":520},"Game asset needs: if the concept is a game, create matching production art assets with Image Gen before implementation. Include transparent sprite\u002Fstate assets, tiles\u002Fplatforms, collectibles, hazards, goal objects, props, and parallax\u002Fbackground layers as needed; use code for collision boxes and game state, not as a substitute for visible art.",{"type":45,"tag":75,"props":522,"children":523},{},[524],{"type":50,"value":525},"Design tokens sampled or approximated from the image: background, surface, text, muted text, border, shadow, accent, semantic colors, radii, elevation, spacing scale, and motion timing.",{"type":45,"tag":75,"props":527,"children":528},{},[529],{"type":50,"value":530},"Color lock: explicitly identify whether the concept background is true white, off-white, cream, gray, dark, or tinted, then implement that exact choice. Do not warm up, cool down, mute, or otherwise \"tastefully\" reinterpret the palette.",{"type":45,"tag":75,"props":532,"children":533},{},[534],{"type":50,"value":535},"Typography system: font family\u002Ffallback, type scale, weights, line heights, tracking, label treatment, heading\u002Fbody\u002Fcaption styles, control text styles, and responsive type behavior.",{"type":45,"tag":75,"props":537,"children":538},{},[539],{"type":50,"value":540},"Icon inventory: every visible icon, glyph, chevron, logo-like mark, toolbar symbol, status symbol, and empty-state symbol; record meaning, source family, outline vs filled style, stroke width, size, color, container, alignment, spacing, and selected\u002Fhover\u002Fdisabled treatment.",{"type":45,"tag":75,"props":542,"children":543},{},[544],{"type":50,"value":545},"Component families and variants: buttons, navigation, rows, panels, media frames, product mockups, cards only where present, tables, forms, chips, icons, empty states, responsive variants, hover\u002Ffocus\u002Fselected states.",{"type":45,"tag":75,"props":547,"children":548},{},[549,551,557],{"type":50,"value":550},"Component architecture plan for complex app UIs: app shell, navigation, major feature regions, reusable UI primitives, data\u002Fstate helpers, chart\u002Ftable\u002Fform modules, asset modules, and responsive layout boundaries. A great front-end implementation should have clear component ownership, not one giant ",{"type":45,"tag":86,"props":552,"children":554},{"className":553},[],[555],{"type":50,"value":556},"App",{"type":50,"value":558}," component or one-off copied markup.",{"type":45,"tag":75,"props":560,"children":561},{},[562],{"type":50,"value":563},"Container model: cards, panels, rails, bands, lists, tables, canvases, drawers, sidebars, modals, or full-bleed sections.",{"type":45,"tag":75,"props":565,"children":566},{},[567],{"type":50,"value":568},"Core workflow: controls that must respond, selected states, filters, tabs, edits, creation flow, success state, playback, game controls, or generated-result demo.",{"type":45,"tag":53,"props":570,"children":571},{},[572],{"type":50,"value":573},"If the concept omits required downstream sections, states, mobile views, or readable detail for a complex area, generate matching section\u002Fstate\u002Fdetail concepts when visual consistency or extraction is uncertain. Otherwise extend in the exact same visual system.",{"type":45,"tag":59,"props":575,"children":577},{"id":576},"implementation",[578],{"type":50,"value":579},"Implementation",{"type":45,"tag":227,"props":581,"children":582},{},[583,588,593,605,610,615,620,625,630,635,648,653,658,663,668,673,678,683,704,709,714,726],{"type":45,"tag":75,"props":584,"children":585},{},[586],{"type":50,"value":587},"Build the real usable surface first, not a marketing wrapper around a future app.",{"type":45,"tag":75,"props":589,"children":590},{},[591],{"type":50,"value":592},"Follow the repo's framework, routing, component, styling, state, accessibility, and asset conventions.",{"type":45,"tag":75,"props":594,"children":595},{},[596,598,603],{"type":50,"value":597},"When creating a new complex app UI without an existing framework constraint, use React + Vite by default. Structure it like a senior front-end engineer would: small focused components, a clear app shell, reusable primitives for repeated controls, feature-specific modules for dashboards\u002Ftables\u002Fcharts\u002Fforms, separated sample data and state helpers, and shared tokens\u002Fstyles. Keep ",{"type":45,"tag":86,"props":599,"children":601},{"className":600},[],[602],{"type":50,"value":556},{"type":50,"value":604}," as composition glue instead of a monolithic screen implementation.",{"type":45,"tag":75,"props":606,"children":607},{},[608],{"type":50,"value":609},"Implement through the design system extracted from the image. Similar elements must use the same component or shared style primitive; differences should be explicit variants, not one-off copied CSS.",{"type":45,"tag":75,"props":611,"children":612},{},[613],{"type":50,"value":614},"Implement the accepted concept exactly. Preserve copy, hierarchy, section order, density, colors, typography, spacing, radii, borders, shadows, asset framing, and interaction model.",{"type":45,"tag":75,"props":616,"children":617},{},[618],{"type":50,"value":619},"For multi-section pages, implement in slices that match the accepted section concepts. Start with the first viewport, compare its browser screenshot to the section concept, fix visible drift, then continue section by section. Do not defer all visual comparison until the whole page is coded, and do not merge or simplify section-specific design decisions just because a broad overview image is easier to follow.",{"type":45,"tag":75,"props":621,"children":622},{},[623],{"type":50,"value":624},"Connect sections into one cohesive page without adding unapproved major UI components. Use spacing, background bands, alignment, typography rhythm, repeated motifs, and media framing to bridge gaps. Do not invent new carousels, accordions, pricing blocks, dashboards, forms, tab systems, feature-card grids, or other large components to make the page feel complete unless they appear in the accepted concept, were requested by the user, or are recorded as a concrete functional necessity.",{"type":45,"tag":75,"props":626,"children":627},{},[628],{"type":50,"value":629},"Do not add new visible above-the-fold copy, hero eyebrows\u002Fkickers, explanatory labels, subtitles, or category text after concept acceptance unless it appears in the accepted concept, came from the user, or is recorded as an intentional deviation. If semantic HTML, SEO, or accessibility requires changing an H1 or heading level, change the element semantics first; do not invent compensating visible copy.",{"type":45,"tag":75,"props":631,"children":632},{},[633],{"type":50,"value":634},"Do not add decorative hero eyebrow labels, pills, badges, gradients, glows, or overlays that were not in the accepted design. Do not substitute a gradient treatment unless it matches the concept's palette, direction, intensity, and placement. If the accepted hero image has no color overlay, do not add a translucent tint, wash, or colored layer over it. If the image needs help blending into a non-matching page background, use a matching asset, transparent cutout, edge fade, mask, or background gradient around the image rather than a color overlay on top of the image. Do not replace white backgrounds with cream\u002Foff-white or otherwise shift the accepted color temperature.",{"type":45,"tag":75,"props":636,"children":637},{},[638,640,646],{"type":50,"value":639},"Define typography on controls deliberately. Do not rely on browser defaults or inherited ",{"type":45,"tag":86,"props":641,"children":643},{"className":642},[],[644],{"type":50,"value":645},"16px",{"type":50,"value":647}," sizing for buttons, tabs, inputs, toolbars, sidebars, inspector panels, layer rows, status bars, command palettes, or export\u002Fshare controls.",{"type":45,"tag":75,"props":649,"children":650},{},[651],{"type":50,"value":652},"Preserve the container model. Do not add cards, bordered panels, floating containers, tiles, or card grids where the spec uses open whitespace, bands, rails, lists, tables, canvases, or full-bleed composition.",{"type":45,"tag":75,"props":654,"children":655},{},[656],{"type":50,"value":657},"Keep real interactive app UI text, navigation, buttons, forms, tables, controls, and labels code-native. This does not apply to text and branding that belong inside product images, posters, packaging, signs, background scenes, hero photos, or other raster assets. Do not ship a static screenshot as UI.",{"type":45,"tag":75,"props":659,"children":660},{},[661],{"type":50,"value":662},"Use Image Gen for central non-icon assets. Render product images and background assets completely with the needed text, logos, marks, labels, packaging, signage, and branding. When the asset must layer into the UI, request a transparent background or clean cutout. Quote exact asset text and require verbatim rendering when text matters.",{"type":45,"tag":75,"props":664,"children":665},{},[666],{"type":50,"value":667},"If the accepted design includes branded product imagery, use Image Gen editing to create standalone versions of the logo\u002Fproduct\u002Fpackaging\u002Fsignage assets from the concept or a matching asset pass. Include transparent-background variants when those assets need to layer into the UI. Do not rebuild branded raster assets from generic CSS, mismatched fonts, or approximate labels.",{"type":45,"tag":75,"props":669,"children":670},{},[671],{"type":50,"value":672},"For games, use Image Gen for visible production art: character\u002Fstate sprites or sprite sheets, terrain\u002Fplatform tiles, collectibles, hazards, goals\u002Fcheckpoints, foreground props, and parallax\u002Fbackground layers. Do not fall back to canvas-drawn shapes because collision, scaling, or animation is simpler. Keep HUD text, score, controls, hit boxes, physics, and game state code-native, and tune collision geometry to the rendered assets. Any code-drawn or vector game art must be listed as an intentional deviation or concrete blocker.",{"type":45,"tag":75,"props":674,"children":675},{},[676],{"type":50,"value":677},"Do not replace concept assets with rough CSS drawings, generic gradients, placeholder SVGs, or stock-like crops. Images must sit naturally in the composition: background color, lighting, edges, crop, shadow, and transparency should blend with the surrounding design. SVG is fine for faithful icons and directional glyphs.",{"type":45,"tag":75,"props":679,"children":680},{},[681],{"type":50,"value":682},"Use SVG\u002Ficon components for arrows, chevrons, carets, disclosure indicators, pagination arrows, and carousel arrows; do not use plain text glyphs unless the concept intentionally does.",{"type":45,"tag":75,"props":684,"children":685},{},[686,688,694,696,702],{"type":50,"value":687},"Implement icons as faithfully as other visual elements. Prefer the repo's existing icon set or lucide only when it matches the accepted design's style; otherwise create a small custom SVG\u002Ficon variant that matches the concept. Custom SVG icons must be production-quality vector assets: clear ",{"type":45,"tag":86,"props":689,"children":691},{"className":690},[],[692],{"type":50,"value":693},"viewBox",{"type":50,"value":695},", clean geometry, consistent stroke widths, aligned joins\u002Fcaps, balanced negative space, optical centering, scalable paths, no jagged or placeholder-looking shapes, and ",{"type":45,"tag":86,"props":697,"children":699},{"className":698},[],[700],{"type":50,"value":701},"currentColor",{"type":50,"value":703}," or explicit fills only when they match the design system. Do not replace filled icons with outline icons, rounded icons with sharp icons, thick strokes with thin strokes, or specific metaphors with generic symbols. Keep icon color, optical size, baseline alignment, padding, and interactive states consistent with the extracted icon inventory.",{"type":45,"tag":75,"props":705,"children":706},{},[707],{"type":50,"value":708},"Make app interfaces experiential: local state, meaningful selected states, working filters\u002Ftabs\u002Fforms, editable or creatable items, success states, playback controls, game controls, or simulated generated output where appropriate.",{"type":45,"tag":75,"props":710,"children":711},{},[712],{"type":50,"value":713},"Use interactive UI inside a hero only when it genuinely fits: SaaS\u002Fsoftware product previews, product demos, or purposeful interactive animation. Do not force fake interactive chrome into a branded, editorial, product, venue, food, consumer, or background-led hero. Faithful implementation and consistent branding are more important than adding interactivity.",{"type":45,"tag":75,"props":715,"children":716},{},[717,719,725],{"type":50,"value":718},"Add motion only where it supports the design. Respect accessibility and ",{"type":45,"tag":86,"props":720,"children":722},{"className":721},[],[723],{"type":50,"value":724},"prefers-reduced-motion",{"type":50,"value":220},{"type":45,"tag":75,"props":727,"children":728},{},[729],{"type":50,"value":730},"Keep implementation production-oriented: semantic markup, stable responsive dimensions, no fragile hardcoded hacks, and type\u002Flint\u002Ftest checks when the repo supports them.",{"type":45,"tag":59,"props":732,"children":734},{"id":733},"verification",[735],{"type":50,"value":736},"Verification",{"type":45,"tag":53,"props":738,"children":739},{},[740],{"type":50,"value":741},"Run the app and verify the visible product, not just the build.",{"type":45,"tag":71,"props":743,"children":744},{},[745,750,755,767,772,777,782,787,792,797,802,807,812],{"type":45,"tag":75,"props":746,"children":747},{},[748],{"type":50,"value":749},"Use Browser\u002FIAB first. Load the app, inspect the first viewport, scroll, and click through the core workflow.",{"type":45,"tag":75,"props":751,"children":752},{},[753],{"type":50,"value":754},"Check desktop, current browser viewport, and a mobile-sized viewport.",{"type":45,"tag":75,"props":756,"children":757},{},[758,760,765],{"type":50,"value":759},"Capture or locate the accepted concept and the latest implementation screenshot. Use ",{"type":45,"tag":86,"props":761,"children":763},{"className":762},[],[764],{"type":50,"value":91},{"type":50,"value":766}," on both in the same QA pass before final handoff; do not skip this step or substitute a browser glance for it.",{"type":45,"tag":75,"props":768,"children":769},{},[770],{"type":50,"value":771},"Capture the implementation at the accepted concept's native dimensions when practical. If not practical, record the blocker and also verify the current browser viewport.",{"type":45,"tag":75,"props":773,"children":774},{},[775],{"type":50,"value":776},"Write a fidelity ledger before final: mismatch, concept evidence, render evidence, and fix made or reason not fixed. For multi-section or multi-state specs, include evidence from the relevant section\u002Fstate concept screenshots, not only the overview. Inspect at least five concrete comparison points covering copy, layout, typography, palette\u002Fgradients, asset treatment, spacing\u002Fcontainer model, responsive behavior, or motion.",{"type":45,"tag":75,"props":778,"children":779},{},[780],{"type":50,"value":781},"Compare side by side for copy, nav, CTA labels, section order, first-viewport balance, next-section visibility, palette, gradient treatment, font personality, type scale, spacing, borders, radii, container model, asset\u002Fbackground blending, motion, and simulated interactions.",{"type":45,"tag":75,"props":783,"children":784},{},[785],{"type":50,"value":786},"Run an above-the-fold copy diff against the allowed copy list. Added, removed, renamed, or reordered visible copy must be fixed or listed as an intentional deviation; unapproved additions fail fidelity.",{"type":45,"tag":75,"props":788,"children":789},{},[790],{"type":50,"value":791},"Audit typography everywhere, not just the hero or main canvas. Check headings, body, captions, labels, toolbar controls, sidebar rows, tabs, inputs, inspector fields, status bars, command palettes, export\u002Fshare buttons, table cells, chart labels, and mobile line breaks. Use computed CSS sizes\u002Fweights\u002Fline-heights when the screenshot suggests drift.",{"type":45,"tag":75,"props":793,"children":794},{},[795],{"type":50,"value":796},"Audit icons wherever they appear: nav, buttons, cards, toolbar controls, sidebars, tables, status indicators, empty states, pagination, carousels, and mobile controls. Check metaphor, stroke\u002Ffill style, size, color, alignment, optical weight, spacing, and state changes against the accepted concept.",{"type":45,"tag":75,"props":798,"children":799},{},[800],{"type":50,"value":801},"For canvas\u002Feditor apps, audit app chrome separately from canvas\u002Fdocument text. Default zoom and pan are part of the spec; persisted local state must not hide seed, scale, or typography fixes during verification.",{"type":45,"tag":75,"props":803,"children":804},{},[805],{"type":50,"value":806},"Ask explicitly: is this agency-signoff faithfully implemented, and would a great, highly skilled design agency sign off on this exact implementation of the accepted design? If anything would get a design-review comment, write a concrete repair checklist and keep editing. Do not final-answer with fixable visual issues.",{"type":45,"tag":75,"props":808,"children":809},{},[810],{"type":50,"value":811},"Verify generated assets load, are framed correctly, and do not obscure text or controls.",{"type":45,"tag":75,"props":813,"children":814},{},[815],{"type":50,"value":816},"Verify the core workflow updates real local UI state. Do not ship inert controls, fake media progress, hidden required media, or placeholder interactions.",{"type":45,"tag":53,"props":818,"children":819},{},[820],{"type":50,"value":821},"Functional QA does not count as fidelity QA. Passing build checks, clicking controls, or verifying local state cannot replace the concept-to-screenshot comparison, native-size check, and written mismatch ledger.",{"type":45,"tag":53,"props":823,"children":824},{},[825],{"type":50,"value":826},"Hard stops: clipped primary content, accidental wrapping, prototype-looking layout, rough seeded data, placeholder boxes, generic stock-like assets, unfinished cards, code-drawn game placeholders replacing concept art, invented visible copy, invented hero eyebrows\u002Fkickers\u002Fpills\u002Fbadges, mismatched colors or gradients, white backgrounds changed to cream\u002Foff-white, unapproved hero image color overlays or tints, missing or generic substituted icons, mismatched icon style or stroke weight, images that do not blend with the background, stale debug artifacts, unreadable text, type-scale drift, browser-default control typography, mobile overflow, unprofessional responsive collapse, or any visible drift from the accepted spec.",{"type":45,"tag":59,"props":828,"children":830},{"id":829},"surface-gates",[831],{"type":50,"value":832},"Surface Gates",{"type":45,"tag":227,"props":834,"children":835},{},[836,841,846,851,856,861,866,871,876],{"type":45,"tag":75,"props":837,"children":838},{},[839],{"type":50,"value":840},"Landing\u002Fcompany sites: preserve first viewport, hero role, brand\u002Fnav\u002FCTA labels, section order, next-section preview, and signature imagery.",{"type":45,"tag":75,"props":842,"children":843},{},[844],{"type":50,"value":845},"Product\u002FSaaS pages: preserve product mockups, workflow diagrams, feature strips, proof elements, and brand treatment.",{"type":45,"tag":75,"props":847,"children":848},{},[849],{"type":50,"value":850},"Dashboards\u002Ftools: preserve density, sidebars, headers, tables, tabs, timelines, charts, maps, row counts, and selected\u002Fdetail behavior. Do not turn table-driven concepts into card grids.",{"type":45,"tag":75,"props":852,"children":853},{},[854],{"type":50,"value":855},"Canvas\u002Feditor tools: preserve default zoom\u002Fpan, canvas\u002Fdocument text scale, chrome density, toolbars, sidebars, inspector controls, layer rows, status bars, command surfaces, and autosaved\u002Fseed-state behavior.",{"type":45,"tag":75,"props":857,"children":858},{},[859],{"type":50,"value":860},"Timeline\u002Fplanning tools: preserve grid\u002Ftime-axis anatomy, row spans, event density, status rails, and command-center fit.",{"type":45,"tag":75,"props":862,"children":863},{},[864],{"type":50,"value":865},"Clone-like interfaces: preserve the recognizable skeleton before adding polish. Do not add marketing heroes or custom navigation that breaks the product type.",{"type":45,"tag":75,"props":867,"children":868},{},[869],{"type":50,"value":870},"Games: preserve the art direction with Image Gen assets for sprites, tiles\u002Fplatforms, collectibles, hazards, goals\u002Fcheckpoints, props, and background\u002Fparallax layers. Verify assets load, scale, animate or swap state correctly, align with collision geometry, and support movement, action\u002Fjump\u002Fdrag behavior, scoring, hazards, and restart.",{"type":45,"tag":75,"props":872,"children":873},{},[874],{"type":50,"value":875},"Media surfaces: verify real media load, duration, play\u002Fpause, seek\u002Fprogress, and visible frame changes.",{"type":45,"tag":75,"props":877,"children":878},{},[879],{"type":50,"value":880},"Forms\u002Fbooking\u002Fpurchase\u002Frestaurant flows: verify the main transaction path and confirmation state.",{"type":45,"tag":59,"props":882,"children":884},{"id":883},"final-response",[885],{"type":50,"value":886},"Final Response",{"type":45,"tag":53,"props":888,"children":889},{},[890,892,897],{"type":50,"value":891},"Include the accepted concept path, rendered screenshot method, Browser\u002FIAB verification method or Playwright fallback reason, ",{"type":45,"tag":86,"props":893,"children":895},{"className":894},[],[896],{"type":50,"value":91},{"type":50,"value":898}," inspection of the accepted concept and latest implementation screenshot, native-size viewport checked or blocker, at least five inspected comparison points, above-the-fold copy diff result, remaining intentional deviations, and an explicit statement that the implementation was faithfully verified against the accepted design. Also include material mismatches fixed and core interaction path verified. If no material mismatches remain, say so directly.",{"items":900,"total":1016},[901,918,934,946,966,984,1004],{"slug":902,"name":902,"fn":903,"description":904,"org":905,"tags":906,"stars":28,"repoUrl":29,"updatedAt":917},"accessibility-and-inclusive-visualization","make data visualizations accessible","Make data visualizations accessible and inclusive. Use when the user needs chart or diagram accessibility guidance, text alternatives for complex visuals, color and contrast review, keyboard support, reduced-motion behavior for animation or parallax, or an accessibility QA workflow for exported figures, UML-like diagrams, and dashboards.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[907,910,913,916],{"name":908,"slug":909,"type":15},"Accessibility","accessibility",{"name":911,"slug":912,"type":15},"Charts","charts",{"name":914,"slug":915,"type":15},"Data Visualization","data-visualization",{"name":26,"slug":27,"type":15},"2026-06-30T19:00:57.102",{"slug":919,"name":919,"fn":920,"description":921,"org":922,"tags":923,"stars":28,"repoUrl":29,"updatedAt":933},"agent-browser","automate browser interactions for agents","Browser automation CLI for AI agents. Use when the user needs to interact with websites, verify dev server output, test web apps, navigate pages, fill forms, click buttons, take screenshots, extract data, or automate any browser task. Also triggers when a dev server starts so you can verify it visually.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[924,927,930],{"name":925,"slug":926,"type":15},"Agents","agents",{"name":928,"slug":929,"type":15},"Browser Automation","browser-automation",{"name":931,"slug":932,"type":15},"Testing","testing","2026-04-06T18:41:03.44016",{"slug":935,"name":935,"fn":936,"description":937,"org":938,"tags":939,"stars":28,"repoUrl":29,"updatedAt":945},"agent-browser-verify","verify dev server output with automated browser","Automated browser verification for dev servers. Triggers when a dev server starts to run a visual gut-check with agent-browser — verifies the page loads, checks for console errors, validates key UI elements, and reports pass\u002Ffail before continuing.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[940,941,944],{"name":928,"slug":929,"type":15},{"name":942,"slug":943,"type":15},"Local Development","local-development",{"name":931,"slug":932,"type":15},"2026-04-06T18:41:17.526867",{"slug":947,"name":947,"fn":948,"description":949,"org":950,"tags":951,"stars":28,"repoUrl":29,"updatedAt":965},"agents-sdk","build AI agents on Cloudflare Workers","Build AI agents on Cloudflare Workers using the Agents SDK. Load when creating stateful agents, durable workflows, real-time WebSocket apps, scheduled tasks, MCP servers, or chat applications. Covers Agent class, state management, callable RPC, Workflows integration, and React hooks. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[952,953,956,959,962],{"name":925,"slug":926,"type":15},{"name":954,"slug":955,"type":15},"Cloudflare Workers","cloudflare-workers",{"name":957,"slug":958,"type":15},"SDK","sdk",{"name":960,"slug":961,"type":15},"Serverless","serverless",{"name":963,"slug":964,"type":15},"WebSockets","websockets","2026-04-06T18:39:51.717063",{"slug":967,"name":967,"fn":968,"description":969,"org":970,"tags":971,"stars":28,"repoUrl":29,"updatedAt":983},"ai-elements","build chat UIs with AI Elements","AI Elements component library guidance — pre-built React components for AI interfaces built on shadcn\u002Fui. Use when building chat UIs, message displays, tool call rendering, streaming responses, reasoning panels, or any AI-native interface with the AI SDK.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[972,973,974,977,980],{"name":23,"slug":24,"type":15},{"name":13,"slug":14,"type":15},{"name":975,"slug":976,"type":15},"shadcn\u002Fui","shadcn-ui",{"name":978,"slug":979,"type":15},"UI Components","ui-components",{"name":981,"slug":982,"type":15},"Vercel","vercel","2026-04-06T18:40:59.619419",{"slug":985,"name":985,"fn":986,"description":987,"org":988,"tags":989,"stars":28,"repoUrl":29,"updatedAt":1003},"ai-gateway","configure Vercel AI Gateway","Vercel AI Gateway expert guidance. Use when configuring model routing, provider failover, cost tracking, or managing multiple AI providers through a unified API.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[990,993,996,999,1002],{"name":991,"slug":992,"type":15},"AI Infrastructure","ai-infrastructure",{"name":994,"slug":995,"type":15},"Cost Optimization","cost-optimization",{"name":997,"slug":998,"type":15},"LLM","llm",{"name":1000,"slug":1001,"type":15},"Performance","performance",{"name":981,"slug":982,"type":15},"2026-04-06T18:40:44.377464",{"slug":1005,"name":1005,"fn":1006,"description":1007,"org":1008,"tags":1009,"stars":28,"repoUrl":29,"updatedAt":1015},"ai-generation-persistence","implement persistence patterns for AI generations","AI generation persistence patterns — unique IDs, addressable URLs, database storage, and cost tracking for every LLM generation",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1010,1011,1014],{"name":994,"slug":995,"type":15},{"name":1012,"slug":1013,"type":15},"Database","database",{"name":997,"slug":998,"type":15},"2026-04-06T18:41:08.513425",600,{"items":1018,"total":1213},[1019,1040,1061,1078,1094,1111,1130,1142,1156,1170,1182,1197],{"slug":1020,"name":1020,"fn":1021,"description":1022,"org":1023,"tags":1024,"stars":1037,"repoUrl":1038,"updatedAt":1039},"prior-auth-packet-builder","build healthcare prior authorization packets","Build a concise prior authorization packet from local case files and payer policy docs.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1025,1028,1031,1034],{"name":1026,"slug":1027,"type":15},"Documents","documents",{"name":1029,"slug":1030,"type":15},"Healthcare","healthcare",{"name":1032,"slug":1033,"type":15},"Insurance","insurance",{"name":1035,"slug":1036,"type":15},"Regulatory Compliance","regulatory-compliance",28169,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fopenai-agents-python","2026-04-16T05:11:39.180399",{"slug":1041,"name":1041,"fn":1042,"description":1043,"org":1044,"tags":1045,"stars":1058,"repoUrl":1059,"updatedAt":1060},"aspnet-core","build ASP.NET Core web applications","Build, review, refactor, or architect ASP.NET Core web applications using current official guidance for .NET web development. Use when working on Blazor Web Apps, Razor Pages, MVC, Minimal APIs, controller-based Web APIs, SignalR, gRPC, middleware, dependency injection, configuration, authentication, authorization, testing, performance, deployment, or ASP.NET Core upgrades.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1046,1049,1051,1054,1057],{"name":1047,"slug":1048,"type":15},".NET","dotnet",{"name":1050,"slug":1041,"type":15},"ASP.NET Core",{"name":1052,"slug":1053,"type":15},"Blazor","blazor",{"name":1055,"slug":1056,"type":15},"C#","csharp",{"name":20,"slug":21,"type":15},23787,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fskills","2026-04-12T05:07:02.819491",{"slug":1062,"name":1062,"fn":1063,"description":1064,"org":1065,"tags":1066,"stars":1058,"repoUrl":1059,"updatedAt":1077},"chatgpt-apps","build ChatGPT Apps SDK applications","Build, scaffold, refactor, and troubleshoot ChatGPT Apps SDK applications that combine an MCP server and widget UI. Use when Codex needs to design tools, register UI resources, wire the MCP Apps bridge or ChatGPT compatibility APIs, apply Apps SDK metadata or CSP or domain settings, or produce a docs-aligned project scaffold. Prefer a docs-first workflow by invoking the openai-docs skill or OpenAI developer docs MCP tools before generating code.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1067,1070,1073,1076],{"name":1068,"slug":1069,"type":15},"Apps SDK","apps-sdk",{"name":1071,"slug":1072,"type":15},"ChatGPT","chatgpt",{"name":1074,"slug":1075,"type":15},"MCP","mcp",{"name":9,"slug":8,"type":15},"2026-04-12T05:07:05.468097",{"slug":1079,"name":1079,"fn":1080,"description":1081,"org":1082,"tags":1083,"stars":1058,"repoUrl":1059,"updatedAt":1093},"cli-creator","build CLIs from API docs","Build a composable CLI for Codex from API docs, an OpenAPI spec, existing curl examples, an SDK, a web app, an admin tool, or a local script. Use when the user wants Codex to create a command-line tool that can run from any repo, expose composable read\u002Fwrite commands, return stable JSON, manage auth, and pair with a companion skill.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1084,1087,1090],{"name":1085,"slug":1086,"type":15},"API Development","api-development",{"name":1088,"slug":1089,"type":15},"CLI","cli",{"name":1091,"slug":1092,"type":15},"Codex","codex","2026-04-12T05:07:04.132762",{"slug":1095,"name":1095,"fn":1096,"description":1097,"org":1098,"tags":1099,"stars":1058,"repoUrl":1059,"updatedAt":1110},"cloudflare-deploy","deploy projects to Cloudflare","Deploy applications and infrastructure to Cloudflare using Workers, Pages, and related platform services. Use when the user asks to deploy, host, publish, or set up a project on Cloudflare.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1100,1103,1106,1107],{"name":1101,"slug":1102,"type":15},"Cloudflare","cloudflare",{"name":1104,"slug":1105,"type":15},"Cloudflare Pages","cloudflare-pages",{"name":954,"slug":955,"type":15},{"name":1108,"slug":1109,"type":15},"Deployment","deployment","2026-04-12T05:07:14.275118",{"slug":1112,"name":1112,"fn":1113,"description":1114,"org":1115,"tags":1116,"stars":1058,"repoUrl":1059,"updatedAt":1129},"define-goal","define and set measurable project goals","Help the user define a concrete, measurable goal before starting work, especially when they ask to use the goal tool, create a goal, set an objective, clarify success criteria, or turn a fuzzy intention into a quantitative outcome. Use this skill for goal creation and goal refinement only; it does not manage durable snapshots, decision logs, or long-running execution artifacts.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1117,1120,1123,1126],{"name":1118,"slug":1119,"type":15},"Productivity","productivity",{"name":1121,"slug":1122,"type":15},"Project Management","project-management",{"name":1124,"slug":1125,"type":15},"Strategy","strategy",{"name":1127,"slug":1128,"type":15},"Task Management","task-management","2026-05-23T06:17:16.870838",{"slug":1131,"name":1131,"fn":1132,"description":1133,"org":1134,"tags":1135,"stars":1058,"repoUrl":1059,"updatedAt":1141},"figma","translate Figma designs into code","Use the Figma MCP server to fetch design context, screenshots, variables, and assets from Figma, and to translate Figma nodes into production code. Trigger when a task involves Figma URLs, node IDs, design-to-code implementation, or Figma MCP setup and troubleshooting.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1136,1137,1139,1140],{"name":26,"slug":27,"type":15},{"name":1138,"slug":1131,"type":15},"Figma",{"name":23,"slug":24,"type":15},{"name":1074,"slug":1075,"type":15},"2026-04-12T05:06:47.939943",{"slug":1143,"name":1143,"fn":1144,"description":1145,"org":1146,"tags":1147,"stars":1058,"repoUrl":1059,"updatedAt":1155},"figma-code-connect-components","connect Figma designs to code components","Connects Figma design components to code components using Code Connect mapping tools. Use when user says \"code connect\", \"connect this component to code\", \"map this component\", \"link component to code\", \"create code connect mapping\", or wants to establish mappings between Figma designs and code implementations. For canvas writes via `use_figma`, use `figma-use`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1148,1149,1152,1153,1154],{"name":26,"slug":27,"type":15},{"name":1150,"slug":1151,"type":15},"Design System","design-system",{"name":1138,"slug":1131,"type":15},{"name":23,"slug":24,"type":15},{"name":978,"slug":979,"type":15},"2026-05-10T05:59:52.971881",{"slug":1157,"name":1157,"fn":1158,"description":1159,"org":1160,"tags":1161,"stars":1058,"repoUrl":1059,"updatedAt":1169},"figma-create-design-system-rules","generate design system rules from Figma","Generates custom design system rules for the user's codebase. Use when user says \"create design system rules\", \"generate rules for my project\", \"set up design rules\", \"customize design system guidelines\", or wants to establish project-specific conventions for Figma-to-code workflows. Requires Figma MCP server connection.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1162,1163,1164,1167,1168],{"name":26,"slug":27,"type":15},{"name":1150,"slug":1151,"type":15},{"name":1165,"slug":1166,"type":15},"Documentation","documentation",{"name":1138,"slug":1131,"type":15},{"name":23,"slug":24,"type":15},"2026-05-16T06:07:47.821474",{"slug":1171,"name":1171,"fn":1172,"description":1173,"org":1174,"tags":1175,"stars":1058,"repoUrl":1059,"updatedAt":1181},"figma-implement-design","translate Figma designs into application code","Translates Figma designs into production-ready application code with 1:1 visual fidelity. Use when implementing UI code from Figma files, when user mentions \"implement design\", \"generate code\", \"implement component\", provides Figma URLs, or asks to build components matching Figma specs. For Figma canvas writes via `use_figma`, use `figma-use`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1176,1177,1178,1179,1180],{"name":26,"slug":27,"type":15},{"name":1138,"slug":1131,"type":15},{"name":23,"slug":24,"type":15},{"name":978,"slug":979,"type":15},{"name":20,"slug":21,"type":15},"2026-05-16T06:07:40.583615",{"slug":1183,"name":1183,"fn":1184,"description":1185,"org":1186,"tags":1187,"stars":1058,"repoUrl":1059,"updatedAt":1196},"hatch-pet","create animated pets for Codex","Create, repair, validate, visually QA, and package Codex-compatible animated pets and pet spritesheets from character art, generated images, company or prospect brand cues, or visual references. Use when a user wants a lightweight-worker Codex pet workflow, a non-pixel custom pet style, a prospect or company mascot pet, or a full 8x9 animated pet atlas with transparent unused cells, QA contact sheets, and pet.json packaging. This skill composes the installed $imagegen system skill for visual generation and uses bundled scripts for deterministic spritesheet assembly.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1188,1191,1192,1195],{"name":1189,"slug":1190,"type":15},"Animation","animation",{"name":1091,"slug":1092,"type":15},{"name":1193,"slug":1194,"type":15},"Creative","creative",{"name":26,"slug":27,"type":15},"2026-05-02T05:31:48.48485",{"slug":1198,"name":1198,"fn":1199,"description":1200,"org":1201,"tags":1202,"stars":1058,"repoUrl":1059,"updatedAt":1212},"imagegen","generate and edit raster images","Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output should be a bitmap asset rather than repo-native code or vector. Do not use when the task is better handled by editing existing SVG\u002Fvector\u002Fcode-native assets, extending an established icon or logo system, or building the visual directly in HTML\u002FCSS\u002Fcanvas.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1203,1204,1205,1208,1211],{"name":1193,"slug":1194,"type":15},{"name":26,"slug":27,"type":15},{"name":1206,"slug":1207,"type":15},"Image Generation","image-generation",{"name":1209,"slug":1210,"type":15},"Images","images",{"name":9,"slug":8,"type":15},"2026-05-15T06:23:24.312127",675]