fd

name	fd
description	Frontend design mode for strong visual direction, UI polish, redesigns, landing pages, and production-grade interface work, including shadcn-based surfaces. Use when the user says `/fd` or explicitly asks for better design, styling, layout, visual quality, or UX polish.

FD

Use this as a frontend design and polish mode. The goal is not to make every UI louder; the goal is to make it feel intentionally designed.

Claude-First Mode

If local claude CLI is available, treat it as the design specialist for meaningful frontend work instead of relying on Codex's taste alone.

• Use a single default workflow: delegate the first pass with claude-design-bridge fd --apply, then inspect Claude's diff, fix any integration issues, and run verification yourself.
• Only use claude-design-bridge fd --plan when the user explicitly wants critique-only guidance without edits, or when apply mode is clearly unsafe for the task.
• Include the user request, relevant paths, constraints, and any established design language in the delegated prompt.
• Treat Claude's visual direction and implementation choices as the primary design authority, then use Codex to inspect, integrate, test, and clean up.
• Fall back to Codex-native design work only if the bridge is unavailable, unauthenticated, or clearly fails.

Post-Claude Audit

When Claude handled the first implementation pass, Codex should assume responsibility for the final integration quality.

• review the actual diff instead of trusting the visual pass blindly
• fix truncation, overflow, wrapping, density, spacing collisions, and awkward responsive breakpoints
• check keyboard/focus states, aria state integrity, and reduced-motion or contrast regressions when relevant
• preserve filtering, routing, data flow, and existing interaction logic unless the user explicitly asked for behavior changes
• catch SSR, hydration, typing, lint, and small-but-important maintainability issues that a design-first pass may miss
• keep the design intent, but tighten the engineering finish

Default Taste

Unless the user explicitly asks for a different direction, bias the design toward:

• Apple HIG-style clarity and restraint
• Jony Ive-style product thinking: simple, refined, modern, reduced, calm
• crisp hierarchy, generous spacing, careful materials, subtle motion, and high legibility
• elegance through reduction, not decoration

Core Rule

Choose a clear visual direction that fits the context, then implement it with enough craft that the result feels deliberate rather than generated.

First Pass

Before changing code:

• Inspect the existing product, codebase, tokens, components, layouts, and visual language.
• Decide whether this is an existing-system refinement or a new-surface design task.
• Identify the user-facing goal, the primary audience, the key constraint, and the one visual idea worth remembering.

If the product already has a strong design system, preserve it and improve within it unless the user explicitly asks for a bigger shift.

Adjust To The Surface

Tune the design to the kind of interface:

• Marketing or landing pages: push concept, typography, narrative, and memorable hero moments.
• Product UI or dashboards: prioritize hierarchy, density control, affordance, readability, and fast scanning over spectacle.
• Forms, settings, and CRUD surfaces: clarity first; polish should reduce friction, not compete with the task.
• Mobile-heavy views: simplify composition, tighten spacing logic, and make the primary action obvious.
• Data-heavy views: use typography, spacing, grouping, and emphasis to make information legible before adding decoration.

If the brief is ambiguous, bias toward clarity with one strong visual idea instead of stacking effects.

Design Direction

Pick and commit to one direction instead of mixing weak ideas:

• visual thesis in one sentence
• typography approach
• color and contrast strategy
• layout rhythm and spacing
• motion style
• one signature detail

Good directions can be restrained or bold: editorial, quiet luxury, industrial, playful, sharp enterprise, tactile utility, cinematic, brutalist, soft physical, retro-futurist, and so on. The important part is consistency and intent.

Execution Rules

• Typography: Avoid generic defaults when the surface is design-led. Use purposeful font pairings and hierarchy. If the product already uses a house style, sharpen it instead of replacing it casually.
• Color: Use semantic tokens or CSS variables. Favor a disciplined palette with a clear dominant tone and a few strong accents over muddy balance.
• Layout: Create rhythm with spacing, scale, alignment, and contrast. Use asymmetry, overlap, density shifts, or generous negative space when it serves the concept.
• Motion: Add a few meaningful animations instead of many weak ones. Prefer page-load staging, hover intent, reveal timing, and state transitions that support the interface.
• Backgrounds and details: Build atmosphere with gradients, textures, patterns, borders, lighting, shadows, or layered surfaces when appropriate. Avoid flat default canvases when the page needs character.
• States: Empty, loading, hover, active, selected, disabled, and error states must feel designed too.
• Accessibility: Keep contrast, focus visibility, keyboard behavior, readable sizing, and reduced-motion considerations intact.

Existing System Priority

When working inside an existing app or design system:

• use existing components before inventing custom markup
• preserve established spacing scales, tokens, and interaction patterns
• improve hierarchy, density, affordance, and polish without creating visual drift
• if shadcn or another component system is present, compose it well instead of fighting it

Shadcn Mode

When the surface is shadcn-based, fd handles it directly.

• inspect the installed shadcn primitives, tokens, CSS variables, and common layout patterns first
• prefer composing existing primitives before creating custom markup
• strengthen typography, spacing, density, and hierarchy before adding decorative effects
• preserve component APIs, token discipline, and product coherence
• use raw custom CSS only when the design needs it and the component layer cannot express it cleanly
• avoid visual drift, ad hoc spacing, and styling everything from scratch when an existing primitive fits

New Surface Priority

When designing a new page or major new surface:

• pick one strong concept early
• make the hero section or primary interaction memorable
• ensure the supporting sections repeat the same design logic
• avoid generic startup-page structure unless the brief truly calls for it

Avoid

• generic AI aesthetics
• purple-on-white gradient defaults
• overused fonts as a substitute for real design direction
• interchangeable SaaS hero sections
• default font stacks as the entire visual idea
• motion that adds noise rather than clarity
• decorative clutter without hierarchy
• breaking an established product language just to look different

Do not converge on the same fonts, palettes, or layout tropes every time.

Implementation Guidance

• Prefer the repo's existing frontend stack and patterns.
• Use CSS variables or existing tokens for colors, spacing, radii, shadows, and motion values.
• Avoid new dependencies unless the user approved them.
• Keep markup and styling maintainable; expressive does not mean messy.
• If a design effect is central, implement it properly instead of hinting at it with placeholder code.
• When delegating to Claude, use a focused prompt block like:

Task: <what the user wants>
Repo: <current cwd>
Relevant paths: <key files or folders>
Constraints: <design system, stack, responsiveness, no new deps, etc.>
What I need: inspect the code, implement the design changes directly, and run the smallest relevant verification.

If the surface is shadcn-based, expand Constraints with:

Existing system: shadcn/ui, current tokens, key primitives already in use
Constraints: keep component APIs coherent, no visual drift, no new deps unless approved

Verification

Before finishing:

• check the result on desktop and mobile widths when relevant
• verify the main interaction, not just the static look
• run the smallest relevant tests, lint, or build checks
• if the task is visually sensitive, use browser inspection or screenshots to catch layout regressions
• if Claude handled the first pass, inspect the resulting diff before finalizing and optionally run a follow-up claude-design-bridge fd --plan critique on the finished surface when the change is especially design-sensitive

Finish

Keep the final response focused on:

• chosen direction
• what changed visually and structurally
• verification run
• remaining rough edges or tradeoffs