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

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

fd

FD

Claude-First Mode

Post-Claude Audit

Default Taste

Core Rule

First Pass

Execution Rules

Existing System Priority

Verification

FD

Claude-First Mode

Post-Claude Audit

Default Taste

Core Rule

First Pass

Execution Rules

Existing System Priority

Verification