---
description:
globs:
alwaysApply: false
---
You are an AI assistant tasked with helping a development team migrate legacy components to a new design system. Your goal is to analyze the current codebase, identify areas that need updating, and provide a detailed plan for the migration process. This task will be completed in three phases: a comprehensive analysis, a detailed plan creation, and a checklist creation.
You will be working with the following inputs:
<component_name>{{COMPONENT_NAME}}</component_name>: The name of the target design-system component
<folder_path>{{FOLDER_PATH}}</folder_path>: The path to the folder containing the legacy components
<component_docs>{{COMPONENT_DOCS}}</component_docs>: The official documentation for the target design-system component
<component_code>{{COMPONENT_CODE}}</component_code>: The source files of the target design-system component
<usage_graph>{{USAGE_GRAPH}}</usage_graph>: A graph showing the usage of the legacy component in the specified folder
<library_data>{{LIBRARY_DATA}}</library_data>: Information about library type
# Phase 1: Comprehensive Analysis
1. Review all provided inputs: COMPONENT_DOCS, COMPONENT_CODE, USAGE_GRAPH, and LIBRARY_DATA.
2. Analyze the current codebase, focusing on:
a. The approved markup and API for the target component
b. The actual implementation of the design-system component
c. All files (templates, TS, styles, specs, NgModules) that reference the legacy component
d. Dependencies and library information
3. Create a comprehensive summary of the analysis, including:
a. Total number of files affected
b. Assessment of migration complexity (Low, Medium, High)
c. Any potential non-viable migrations that may require manual rethinking
d. Key decisions or assumptions made during the analysis
e. Insights gained from examining the component files
f. Implications of the LIBRARY_DATA on the migration process
Write your comprehensive analysis in <comprehensive_analysis> tags.
# Phase 2: Detailed Plan Creation
Please think about this problem thoroughly and in great detail. Consider multiple approaches and show your complete reasoning. Please perform a thourough and Based on your comprehensive analysis, create a detailed migration plan:
1. For each affected file:
a. Compare the old markup against the design-system exemplar from the COMPONENT_DOCS.
b. Classify the migration effort as:
- Simple swap (straight replacement with no loss of behavior, styling, responsive rules, animation, click/test-ID, or accessibility attributes)
- Requires restructure (minor code or CSS tweaks needed to preserve behaviors or visuals that the design-system component lacks)
- Non-viable (needs manual rethink)
c. Assign a complexity score on a scale of 1-10, adding:
- +1 per removed animation or breakpoint
- +2 per business variant that needs to be rebuilt
2. Create an actionable plan ordered by effort, including:
a. File path & type
b. Refactor classification
c. Concrete edits needed (template, TS, styles, NgModule, spec)
d. Verification notes (2-3 static checks that can be performed by reading files only)
e. Complexity score
3. If any items are classified as non-viable, explicitly highlight these in a separate section of your plan.
4. Review your detailed plan against the COMPONENT_DOCS to ensure all recommendations align with the official documentation.
5. Identify any ambiguities in your plan that could be interpreted multiple ways and list these in a separate section.
Write your detailed migration plan in <migration_plan> tags.
# Phase 3: Checklist Creation
After the user approves the plan and clarifies any ambiguities:
1. Create a checklist that lists only actual changes as checkboxes.
2. Create a "check" phase where all verifications (2-3 static checks that can be performed by reading files only) are listed as checkboxes.
3. Ensure the checklist is comprehensive and follows directly from the approved migration plan.
Write your checklist in <checklist> tags.
Your final output should include only the following:
1. The <comprehensive_analysis> block
2. The <migration_plan> block
3. The following approval request: "š ļø Approve this plan or specify adjustments?"
4. If applicable, an ambiguity safeguard: "ā The plan contains ambiguities: [short description]. Please clarify."
After the user approves the plan and clarifies any ambiguities, provide only the <checklist> block in your response. Also, remember to save the checklist in a file at .cursor/tmp/refactoring-checklis-{{FOLDER_PATH}}.md.