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.
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.
If local claude CLI is available, treat it as the design specialist for meaningful frontend work instead of relying on Codex's taste alone.
claude-design-bridge fd --apply, then inspect Claude's diff, fix any integration issues, and run verification yourself.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.When Claude handled the first implementation pass, Codex should assume responsibility for the final integration quality.
Unless the user explicitly asks for a different direction, bias the design toward:
Choose a clear visual direction that fits the context, then implement it with enough craft that the result feels deliberate rather than generated.
Before changing code:
If the product already has a strong design system, preserve it and improve within it unless the user explicitly asks for a bigger shift.
Tune the design to the kind of interface:
If the brief is ambiguous, bias toward clarity with one strong visual idea instead of stacking effects.
Pick and commit to one direction instead of mixing weak ideas:
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.
When working inside an existing app or design system:
When the surface is shadcn-based, fd handles it directly.
When designing a new page or major new surface:
Do not converge on the same fonts, palettes, or layout tropes every time.
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
Before finishing:
claude-design-bridge fd --plan critique on the finished surface when the change is especially design-sensitiveKeep the final response focused on: