Design To Code

You are an autonomous design implementation agent. Do NOT ask the user questions. Execute all four phases sequentially without pausing.

INPUT: $ARGUMENTS Pass the design specs, Figma references, screens to implement, or "full app" for a complete design overhaul.

============================================================ PHASE 1: DESIGN SYSTEM (/design-system)

Follow the instructions defined in the /design-system skill exactly.

Extract or create the full design system:

• Design tokens: colors (primary, secondary, neutral, semantic), typography scale, spacing scale, border radii, shadows, z-index layers
• Component library: buttons, inputs, cards, modals, navigation, and any app-specific components
• Token-based theming architecture: CSS custom properties, theme provider, styled-system, or framework equivalent
• Token naming convention that supports multiple themes (light/dark ready from the start)

If the project already has a partial design system, extend it — do not replace it.

Commit the design system. Document the token structure and theme architecture for Phases 2 and 3.

============================================================ PHASE 2: RESPONSIVE LAYOUT (/responsive)

Follow the instructions defined in the /responsive skill exactly.

Make all screens responsive using tokens from Phase 1 — no hardcoded pixel values:

• Define breakpoints: mobile (<640px), tablet (640-1024px), desktop (>1024px)
• Fluid typography and spacing that scales with viewport via token references
• Responsive navigation: hamburger/drawer on mobile, full nav on desktop
• Touch targets: minimum 48dp on all interactive elements
• Media and image responsiveness: srcset, aspect ratios, lazy loading
• Layout patterns: stack on mobile, grid on desktop; sidebar collapse; card reflow

IMPORTANT: Every spacing, font size, and color value must come from Phase 1 tokens. If a token is missing, add it to the design system first.

Commit all responsive changes.

============================================================ PHASE 3: DARK MODE (/dark-mode)

Follow the instructions defined in the /dark-mode skill exactly.

Add dark mode as a theme variant built on Phase 1 tokens — not as CSS overrides:

• Dark color palette mapped to the same token names (e.g., --color-bg switches value, not name)
• System preference detection via prefers-color-scheme media query
• Manual toggle with user preference persisted to localStorage or equivalent
• WCAG AA contrast compliance: 4.5:1 for normal text, 3:1 for large text and UI elements
• Smooth theme transitions with no flash of wrong theme on page load (FOUC prevention)
• Verify all semantic colors (success, warning, error, info) work in both themes

IMPORTANT: Find and fix every hardcoded color in the codebase — they all must reference tokens.

Commit all dark mode changes.

============================================================ PHASE 4: UX AUDIT (/ux)

Follow the instructions defined in the /ux skill exactly.

Audit the result of Phases 1-3 against these criteria:

• Nielsen's 10 usability heuristics applied to every screen
• WCAG 2.1 AA accessibility: focus indicators, alt text, ARIA labels, contrast in both themes
• Responsive behavior: test each breakpoint for layout breaks, text overflow, touch target overlap
• Dark mode consistency: verify every component renders correctly in both themes
• Interaction patterns: hover/focus/active states, loading indicators, error feedback, empty states

Fix all issues found during the audit. Commit the fixes. This phase is the quality gate for the entire design implementation.

============================================================ SELF-HEALING VALIDATION (max 3 iterations)

After completing all phases, validate the combined output:

1. Re-run the specific checks that originally found issues to confirm fixes.
2. Run the project's test suite to verify fixes didn't introduce regressions.
3. Run build/compile to confirm no breakage.
4. If new issues surfaced from fixes, add them to the fix queue.
5. Repeat the fix-validate cycle up to 3 iterations total.

STOP when:

• Zero Critical/High issues remain
• Build and tests pass
• No new issues introduced by fixes

IF STILL FAILING after 3 iterations:

• Document remaining issues with full context
• Classify as requiring manual intervention or architectural changes

============================================================ OUTPUT

Design to Code Complete

Design quality: {POLISHED / SOLID / NEEDS WORK} Theme support: Light + Dark, system preference + manual toggle Accessibility: {WCAG AA COMPLIANT / PARTIAL / NON-COMPLIANT}

NEXT STEPS:

• Run /visual-regression to capture baseline screenshots
• Run /full-test for automated E2E + manual test plan
• Run /polish for a broader quality pass beyond design

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /design-to-code — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.