fd

# 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 nee