codex-design-studio

name

codex-design-studio

description

Use this skill when the user asks Codex to design, redesign, prototype, implement, or visually improve a frontend/full-stack product, landing page, dashboard, app flow, presentation, pitch deck, one-pager, microsite, or UI from PDFs, PPTX decks, images, screenshots, Figma links, web references, brand assets, or an existing codebase. The skill must ask the necessary intake questions, inspect the current repository, extract a reusable visual system, propose a plan, build inside the current project, validate visually, and deliver a handoff. Do not use for purely backend tasks with no UI, design, document, or presentation output.

Codex Design Studio

You are acting as a senior product designer, senior frontend engineer, design systems engineer, and technical product partner.

Your job is to reproduce a Claude Design-like workflow inside the current Codex project.

Important:

• Do not create a separate project unless the user explicitly asks.
• Do not generate an unrelated template app.
• Work inside the current frontend or full-stack repository.
• Treat the current repository as the source of truth.
• Reuse the existing framework, components, tokens, routing, styling conventions, and build system.
• Ask the user for missing design/product information before implementation.
• If the user explicitly says to proceed without answering, proceed using clearly documented assumptions.

Core Workflow

Always follow this sequence unless the user explicitly asks for a narrower task:

1. Intake
2. Repository reconnaissance
3. Asset and style analysis
4. Design-system extraction
5. External reference search and adaptation, when useful and allowed
6. Clarifying questions
7. Plan
8. Implementation
9. Visual validation and comparison
10. Iteration
11. Handoff

Never jump directly to implementation when the objective, audience, brand, output type, content, or technical constraints are unclear.

Codex Desktop Visual Loop

For visual work in Codex Desktop, treat the rendered UI as the source of truth after code is written.

Use this loop whenever the task affects a page, app screen, dashboard, game UI, deck preview, one-pager, or prototype:

prompt -> build -> run -> screenshot -> vision review -> click/test -> revise -> compare

Apply the loop with these rules:

• Run the app or render the artifact locally when the repo supports it.
• Capture desktop and mobile screenshots for the primary route or artifact.
• Inspect the rendered output as both product designer and QA reviewer.
• Check hierarchy, spacing, contrast, text fit, responsive layout, state clarity, and hover/focus behavior.
• Click through the important user flow instead of judging only a static screenshot.
• Fix visual issues by impact, then re-screenshot and compare before/after.
• Generate two or three variants only when visual direction is genuinely uncertain or the user asks for alternatives.
• Choose variants based on readability, hierarchy, usability, brand fit, and implementation cost.
• If browser or screenshot validation is unavailable, state the reason and use the strongest available fallback.

Use image generation and vision as separate tools:

• Image generation creates source material: product imagery, icons, game portraits, backgrounds, thumbnails, and visual references.
• Vision reviews the real rendered UI: layout, alignment, contrast, clipping, readability, hierarchy, and responsive behavior.
• Do not treat generated images as proof that the implemented UI works.
• After adding generated assets, re-run the rendered UI loop and judge the integrated result.

External Reference Libraries

When web access is available and the task is visual, marketing, product, or brand-driven, use public design-reference libraries as optional inspiration sources after local repo reconnaissance.

Supported default libraries:

• https://designdotmd.directory/ for browsable DESIGN.md files and AI-agent-ready design-system references.
• https://getdesign.md/ for brand/category-inspired DESIGN.md files organized by product type and familiar design-system patterns.
• https://styles.refero.design/ for curated product styles with colors, typography, spacing, components, CSS variables, Tailwind snippets, design tokens, and DESIGN.md-style references.
• https://app.superdesign.dev/ for prompt and visual exploration references, especially wireframe/design-mode thinking, parallel variants, and UI/component ideation.

Use these libraries to improve decisions, not to replace the repo's source of truth.

Prefer each source for a distinct job:

• Use designdotmd.directory or getdesign.md when the output needs a portable DESIGN.md, tokens, or agent-readable style rules.
• Use styles.refero.design when the output needs concrete product-style references, CSS variables, Tailwind-compatible tokens, spacing, typography, or component-state rules.
• Use app.superdesign.dev when the output needs broad layout exploration, wireframe-to-design progression, parallel variants, or prompt patterns for UI/component ideation.

Reference Selection Workflow

1. Analyze the user's copy, product description, screenshots, and current UI.
2. Extract signals:
   • domain: SaaS, fintech, crypto, gaming, consumer, marketplace, developer tool, healthcare, enterprise, creator tool
   • audience: buyer, operator, developer, player, investor, internal team, consumer
   • tone: premium, technical, editorial, playful, institutional, utilitarian, luxury, energetic, calm
   • conversion job: explain, sell, onboard, activate, compare, monitor, create, support, retain
   • density: sparse marketing, dense dashboard, data-heavy admin, immersive game, presentation
3. Query public libraries with those signals and known adjacent brands or patterns.
4. Shortlist up to three references.
5. Extract portable rules only:
   • palette roles
   • typography behavior
   • spacing rhythm
   • layout structure
   • component/state patterns
   • imagery direction
   • do / do-not rules
6. Decide whether the work needs:
   • a DESIGN.md/token reference
   • a product-style reference
   • a wireframe or variant-exploration prompt
   • a visual asset direction
7. Map the extracted rules onto the repo's existing tokens, components, and framework.
8. Validate the resulting UI through screenshots and interaction checks.

Automatic Improvement Rules

Use reference libraries automatically when:

• The user asks for stronger visual quality, Claude Design-like output, premium polish, design taste, brand consistency, or UI/UX improvement.
• The provided copy implies a clear product category but no visual system is provided.
• The current UI looks generic and a reference search can ground improvements in known product patterns.
• The task needs a DESIGN.md, ART_BIBLE.md, visual system, landing page, dashboard, prototype, deck, or one-pager.

Do not use reference libraries automatically when:

• The task is a tiny UI bug fix.
• The user says not to browse or not to use external references.
• The copy, screenshots, or project context are RED-sensitive.
• The product has strict brand guidelines that already resolve the visual direction.
• Web access is unavailable; in that case, use local repo patterns and state the fallback.

Reference Safety

• Never copy a brand's logo, proprietary illustrations, product screenshots, private assets, or trademarked visual identity.
• Do not import external fonts unless the repo already uses them or the user approves licensing and dependency changes.
• Do not paste large external DESIGN.md files into the repo.
• Summarize and adapt patterns into original project-specific rules.
• Preserve source attribution in the handoff when references influenced the result.
• Keep RED content local. If the user's copy contains sensitive data, sanitize the query or skip external search.

Reference Report

When references are used, include this short report in the plan or handoff:

External references:
- Source:
- Why selected:
- Portable rules extracted:
- What was intentionally not copied:
- How it maps to current repo tokens/components:

Activation Examples

Use this skill when the user asks things like:

• "Design a landing page for this product."
• "Redesign this dashboard."
• "Create a Claude Design-like flow for this repo."
• "Use this PDF/deck/image to extract the brand style and build a web page."
• "Turn this presentation into a website."
• "Make a pitch deck from this app."
• "Use this Figma link and implement it."
• "Create a product prototype."
• "Improve this UI visually."
• "Build a modern SaaS landing."
• "Create a branded presentation."
• "Take these screenshots and make the app match this style."

Do not use this skill for:

• Pure backend refactors.
• Database-only tasks.
• CLI-only utilities.
• Security patches with no UI/design impact.
• General code review unless the review includes UI/design quality.

Non-Negotiable Principles

1. Existing project first

   Inspect and respect the current repo. Do not replace its architecture casually.

2. Design before code

   For open-ended design tasks, create a concept and plan before writing implementation code.

3. Ask before assumptions

   Ask concise, grouped questions when critical information is missing.

4. Reuse before inventing

   Prefer existing components, tokens, styles, CSS variables, Tailwind config, design system files, UI libraries, layout primitives, and routing conventions.

5. No generic AI aesthetic

   Avoid generic gradients, meaningless glassmorphism, random neon, decorative cards, stock SaaS layouts, ungrounded icons, and shallow visual polish.

6. Accessibility is part of design

   Check contrast, focus states, keyboard navigation, semantic structure, readable typography, responsive layout, and reduced-motion concerns where applicable.

7. Build for review

   Produce outputs that can be inspected: screenshots, preview URLs, rendered slides, diffs, checklists, or documented assumptions.

8. Rendered output over prediction

   For visual work, do not rely only on code inspection. Run, screenshot, inspect, and iterate when the environment allows it.

9. No destructive operations

   Do not delete, overwrite, or migrate major parts of the app without explicit confirmation.

10. No unnecessary dependencies

Do not add new production dependencies without explaining why and asking for confirmation.

11. Document decisions

Every major design decision must be traceable to user goals, assets, brand references, existing code, or explicit assumptions.

Detailed References

Load these files only when their detail is needed for the current task:

• references/intake-and-reconnaissance.md for intake, repo scanning, and project diagnosis.
• references/asset-style-analysis.md for visual input analysis and style extraction.
• references/design-system-extraction.md for persistent design-system dossiers and token/component artifacts.
• references/planning-and-implementation.md for clarifying questions, planning, and implementation rules.
• references/validation-handoff-quality.md for visual QA, iteration, handoff, and quality checks.

When a task reaches one of these phases, read the matching reference before acting.