$npx -y skills add dgk-dev/dgk-gpt --skill fdFrontend 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.
| 1 | # FD |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## Claude-First Mode |
| 6 | |
| 7 | If local `claude` CLI is available, treat it as the design specialist for meaningful frontend work instead of relying on Codex's taste alone. |
| 8 | |
| 9 | - 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. |
| 10 | - 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. |
| 11 | - Include the user request, relevant paths, constraints, and any established design language in the delegated prompt. |
| 12 | - Treat Claude's visual direction and implementation choices as the primary design authority, then use Codex to inspect, integrate, test, and clean up. |
| 13 | - Fall back to Codex-native design work only if the bridge is unavailable, unauthenticated, or clearly fails. |
| 14 | |
| 15 | ## Post-Claude Audit |
| 16 | |
| 17 | When Claude handled the first implementation pass, Codex should assume responsibility for the final integration quality. |
| 18 | |
| 19 | - review the actual diff instead of trusting the visual pass blindly |
| 20 | - fix truncation, overflow, wrapping, density, spacing collisions, and awkward responsive breakpoints |
| 21 | - check keyboard/focus states, aria state integrity, and reduced-motion or contrast regressions when relevant |
| 22 | - preserve filtering, routing, data flow, and existing interaction logic unless the user explicitly asked for behavior changes |
| 23 | - catch SSR, hydration, typing, lint, and small-but-important maintainability issues that a design-first pass may miss |
| 24 | - keep the design intent, but tighten the engineering finish |
| 25 | |
| 26 | ## Default Taste |
| 27 | |
| 28 | Unless the user explicitly asks for a different direction, bias the design toward: |
| 29 | |
| 30 | - Apple HIG-style clarity and restraint |
| 31 | - Jony Ive-style product thinking: simple, refined, modern, reduced, calm |
| 32 | - crisp hierarchy, generous spacing, careful materials, subtle motion, and high legibility |
| 33 | - elegance through reduction, not decoration |
| 34 | |
| 35 | ## Core Rule |
| 36 | |
| 37 | Choose a clear visual direction that fits the context, then implement it with enough craft that the result feels deliberate rather than generated. |
| 38 | |
| 39 | ## First Pass |
| 40 | |
| 41 | Before changing code: |
| 42 | |
| 43 | - Inspect the existing product, codebase, tokens, components, layouts, and visual language. |
| 44 | - Decide whether this is an **existing-system refinement** or a **new-surface design** task. |
| 45 | - Identify the user-facing goal, the primary audience, the key constraint, and the one visual idea worth remembering. |
| 46 | |
| 47 | If the product already has a strong design system, preserve it and improve within it unless the user explicitly asks for a bigger shift. |
| 48 | |
| 49 | ## Adjust To The Surface |
| 50 | |
| 51 | Tune the design to the kind of interface: |
| 52 | |
| 53 | - **Marketing or landing pages**: push concept, typography, narrative, and memorable hero moments. |
| 54 | - **Product UI or dashboards**: prioritize hierarchy, density control, affordance, readability, and fast scanning over spectacle. |
| 55 | - **Forms, settings, and CRUD surfaces**: clarity first; polish should reduce friction, not compete with the task. |
| 56 | - **Mobile-heavy views**: simplify composition, tighten spacing logic, and make the primary action obvious. |
| 57 | - **Data-heavy views**: use typography, spacing, grouping, and emphasis to make information legible before adding decoration. |
| 58 | |
| 59 | If the brief is ambiguous, bias toward clarity with one strong visual idea instead of stacking effects. |
| 60 | |
| 61 | ## Design Direction |
| 62 | |
| 63 | Pick and commit to one direction instead of mixing weak ideas: |
| 64 | |
| 65 | - visual thesis in one sentence |
| 66 | - typography approach |
| 67 | - color and contrast strategy |
| 68 | - layout rhythm and spacing |
| 69 | - motion style |
| 70 | - one signature detail |
| 71 | |
| 72 | 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. |
| 73 | |
| 74 | ## Execution Rules |
| 75 | |
| 76 | - **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. |
| 77 | - **Color**: Use semantic tokens or CSS variables. Favor a disciplined palette with a clear dominant tone and a few strong accents over muddy balance. |
| 78 | - **Layout**: Create rhythm with spacing, scale, alignment, and contrast. Use asymmetry, overlap, density shifts, or generous negative space when it serves the concept. |
| 79 | - **Motion**: Add a few meaningful animations instead of many weak ones. Prefer page-load staging, hover intent, reveal timing, and state transitions that suppo |