Reference-Driven Web Redesign
Core Rule
Do not only describe the screenshot or page. Inspect, redesign, implement, and verify the actual UI whenever files are available.
Use the existing project stack by default. Use React and Tailwind only when the project already uses them or when the user asks for a new standalone implementation.
Required Reference
Read references/web-redesign-checklist.md before changing UI for screenshot reconstruction, landing page redesign, or AI-look cleanup.
Workflow
Confirm the working boundary.
- Identify the target project folder, framework, styling system, component structure, and run/build/test commands.
- Check git status before editing.
- Preserve unrelated user changes.
Analyze the current visual state.
- If a screenshot is provided, inspect layout, background, colors, typography, spacing, cards, buttons, image placement, and mood.
- If a live page exists, run it or open it and capture desktop and mobile screenshots when practical.
- Name what looks generic, template-like, or AI-generated.
Establish references.
- Use user-provided references first.
- If references are missing and browsing is allowed, use high-quality product or editorial references such as Awwwards, Dribbble, Seedance, Kling, Runway, or comparable real sites.
- Extract reusable patterns, not exact copyrighted layouts or copy.
Create editable design tokens.
- Centralize colors, typography, spacing, radii, shadows, borders, motion, and image treatments in the existing token/config pattern when one exists.
- Keep tokens small and meaningful. Do not scatter brand or visual constants through components.
Redesign from the first viewport outward.
- Start with the hero or primary screen.
- Prefer real product, place, object, state, or result visuals over abstract decoration.
- Build the page flow in this order when it fits the product: Hero, Feature, Showcase, Use case, CTA, Footer.
- Omit sections that do not serve the user's product or task.
Implement with production structure.
- Reuse existing components and naming conventions.
- Keep components focused and editable.
- Avoid generic gradients, decorative blobs, random icon grids, empty cards, excessive glassmorphism, and vague filler copy.
- Make responsive layout intentional rather than relying on shrink-only behavior.
Verify before reporting completion.
- Run the most relevant format, lint, typecheck, test, build, or app launch command available.
- Inspect desktop and mobile views when this is a visual task.
- Confirm text does not overlap or overflow, buttons remain usable, media loads, and the first viewport communicates the product clearly.
- Report changed files, verification results, and any remaining risk.
Output When Asked For A Plan Or Prompt Only
When the user asks only for a prompt, method, or Skill draft, provide:
- Design analysis checklist
- Editable design token outline
- Component/section structure
- Implementation prompt or Skill content
- Customization notes
Do not claim code has been implemented unless files were actually changed and verified.
1---2name: reference-driven-web-redesign3description: Redesign AI-looking websites, landing pages, product pages, app screens, or screenshots into polished responsive web experiences. Use when Codex or Claude Code is asked to recreate a visual style from a screenshot, remove generic AI-generated design, improve a landing page, build a web page from references, create React/Tailwind UI from visual direction, or turn visual analysis into production-ready frontend code.4---56# Reference-Driven Web Redesign78## Core Rule910Do not only describe the screenshot or page. Inspect, redesign, implement, and verify the actual UI whenever files are available.1112Use the existing project stack by default. Use React and Tailwind only when the project already uses them or when the user asks for a new standalone implementation.1314## Required Reference1516Read `references/web-redesign-checklist.md` before changing UI for screenshot reconstruction, landing page redesign, or AI-look cleanup.1718## Workflow19201. Confirm the working boundary.21 - Identify the target project folder, framework, styling system, component structure, and run/build/test commands.22 - Check git status before editing.23 - Preserve unrelated user changes.24252. Analyze the current visual state.26 - If a screenshot is provided, inspect layout, background, colors, typography, spacing, cards, buttons, image placement, and mood.27 - If a live page exists, run it or open it and capture desktop and mobile screenshots when practical.28 - Name what looks generic, template-like, or AI-generated.29303. Establish references.31 - Use user-provided references first.32 - If references are missing and browsing is allowed, use high-quality product or editorial references such as Awwwards, Dribbble, Seedance, Kling, Runway, or comparable real sites.33 - Extract reusable patterns, not exact copyrighted layouts or copy.34354. Create editable design tokens.36 - Centralize colors, typography, spacing, radii, shadows, borders, motion, and image treatments in the existing token/config pattern when one exists.37 - Keep tokens small and meaningful. Do not scatter brand or visual constants through components.38395. Redesign from the first viewport outward.40 - Start with the hero or primary screen.41 - Prefer real product, place, object, state, or result visuals over abstract decoration.42 - Build the page flow in this order when it fits the product: Hero, Feature, Showcase, Use case, CTA, Footer.43 - Omit sections that do not serve the user's product or task.44456. Implement with production structure.46 - Reuse existing components and naming conventions.47 - Keep components focused and editable.48 - Avoid generic gradients, decorative blobs, random icon grids, empty cards, excessive glassmorphism, and vague filler copy.49 - Make responsive layout intentional rather than relying on shrink-only behavior.50517. Verify before reporting completion.52 - Run the most relevant format, lint, typecheck, test, build, or app launch command available.53 - Inspect desktop and mobile views when this is a visual task.54 - Confirm text does not overlap or overflow, buttons remain usable, media loads, and the first viewport communicates the product clearly.55 - Report changed files, verification results, and any remaining risk.5657## Output When Asked For A Plan Or Prompt Only5859When the user asks only for a prompt, method, or Skill draft, provide:60611. Design analysis checklist622. Editable design token outline633. Component/section structure644. Implementation prompt or Skill content655. Customization notes6667Do not claim code has been implemented unless files were actually changed and verified.
Candy-Park