frontend-refactoring

Migrates legacy frontend surfaces to isolated v2 UI systems with structure-first inventories and safe cutover.

3|Updated Mar 20, 2026
One-click install
npx skills add https://github.com/ceasarXuu/AstartesSkills --skill frontend-refactoring-ceasarxuu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: frontend-refactoring
Source: https://github.com/ceasarXuu/AstartesSkills/tree/main/skills/frontend-refactoring
Command: npx skills add https://github.com/ceasarXuu/AstartesSkills --skill frontend-refactoring-ceasarxuu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Legacy frontend redesigns often fail because new UI gets contaminated by global CSS, generic class names, !important wars, and deep descendant selectors. This Skill treats large visual rewrites as a migration problem, helping you isolate new UI, reuse business logic without reusing polluted styles, and cut over safely without breaking the old system. ## Core Features & Use Cases - Structure-First Inventory: Builds a style-agnostic inventory of page regions, functional components, and states before any migration code is written, so nothing required is lost or invented. - Isolation Strategy Selection: Recommends the lightest sufficient isolation approach—CSS Modules, a namespace wrapper like .v2-page, or Shadow DOM—based on your stack. - Safe Cutover Workflow: Enforces feature flags, route splits, visual regression checks, and staged deletion of legacy CSS only after verification. - Use Case: You need to redesign a legacy dashboard whose styles leak through global .card and .title selectors. The Skill guides you to inventory the existing structure, build a scoped components-v2/ surface with design tokens, and switch traffic via a feature flag before deleting old styles. ## Quick Start Ask the agent to analyze your legacy page, produce a style-agnostic structure inventory and contamination map, then propose an isolation strategy and v2 migration plan.

Frequently Asked Questions about frontend-refactoring

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor legacy CSS without breaking the existing UI?

Treat the work as a migration: build a style-agnostic inventory of the existing structure first, create an isolated v2 surface with new class names, then cut over behind a feature flag. Only delete legacy styles after regression checks confirm the new UI covers everything.

CSS Modules vs Shadow DOM for style isolation, which should I use?

CSS Modules or framework-scoped styles are the default for React, Next.js, and Vue apps. Use a namespace wrapper like `.v2-page` for legacy stacks, and reserve Shadow DOM for widgets or embeds needing strict host-page isolation.

How do I stop global CSS from leaking into new components?

Move new UI out of the polluted style domain using scoped styles or a root namespace, avoid reusing legacy class names, and keep page detail out of global entry files. Use `@layer` ordering and `:where()` to control specificity.

When should I not rebuild the DOM during a frontend redesign?

Skip a rebuild when the change is a small styling fix inside an already well-scoped component system, or when the issue is purely functional rather than architectural. Rebuild only when the target UI differs substantially from the legacy layout.

When is it safe to delete old CSS after a redesign?

Delete legacy styles only after the v2 surface is live, behavior and visuals are verified, traffic has switched over, and the old dependency graph is understood. Never delete first and hope the new UI covers everything.