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.

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.
• 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

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