AI Software Engineering Command Center™

Add a dark mode to my React app. Make it look professional and don't break anything. Use the existing styling system if possible. Make sure it works on mobile too.

PRODUCTION CODING PROMPT Task

Implement a production-ready dark mode system for the existing React application while preserving current functionality, design-system conventions, and responsive behavior.

1. Repository Inspection

Before modifying code:

Identify the React framework and version. Locate the existing styling system. Identify global theme variables/tokens. Identify layout and component styling conventions. Determine whether a theme provider, context, CSS variables, Tailwind configuration, or equivalent system already exists. Inspect existing responsive breakpoints. Identify components that use hard-coded colors and may not automatically adapt.

Do not introduce a new styling framework if an existing system can support the requirement.

2. Scope

In scope:

Light/dark theme support Theme state management Theme persistence Theme-aware global colors Existing components adapting to the theme Mobile compatibility Theme toggle UI Accessible theme controls

Out of scope:

Rebuilding the component library Replacing the existing CSS architecture Unrelated visual redesign Changing business logic Rewriting components unnecessarily 3. Implementation Requirements Reuse the existing styling architecture whenever practical. Prefer centralized theme tokens over scattered hard-coded colors. Avoid duplicating component styles unnecessarily. Preserve existing light-mode appearance as closely as possible. Ensure dark mode provides sufficient contrast. Persist the user's theme preference using the project's existing storage conventions. Avoid hydration or flash-of-incorrect-theme issues where applicable. Respect existing responsive behavior. Keep the implementation modular and maintainable. 4. Edge Cases

Handle:

First-time users Returning users with saved preferences System-theme preference if supported Missing theme preference Components containing hard-coded background colors Modal/dropdown states Form controls Disabled states Loading states Error states 5. Accessibility

Verify:

Text contrast Interactive element contrast Focus states Keyboard accessibility Theme toggle labeling Screen-reader accessibility

Do not rely exclusively on color to communicate state.

6. Acceptance Criteria

The implementation is complete only when:

Light mode continues to work. Dark mode can be enabled and disabled. Theme preference persists correctly. Existing major components adapt correctly. Mobile layouts remain functional. No unrelated files or functionality are changed. Existing tests continue to pass. Appropriate new tests are added where practical. No obvious contrast/accessibility regressions are introduced. 7. Verification

After implementation:

Run the existing test suite. Run the project's lint/type-check commands when available. Verify both themes across primary screens. Check responsive layouts. Check interactive states. Report any unresolved issues instead of claiming success. 8. Final Response

Return:

Implemented

Files changed Main architectural decisions Tests executed Verification results

Potential Issues

Remaining limitations Any assumptions made Any manual verification still required

Do not claim the task is complete if verification failed.