AgentStack
SKILL verified MIT Self-run

Migrate Component

skill-davila7-claude-with-skills-migrate-component · by davila7

Migrate a UI component from one framework to another, preserving behavior and tests.

No reviews yet
0 installs
16 views
0.0% view→install

Install

$ agentstack add skill-davila7-claude-with-skills-migrate-component

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Migrate Component? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Migrate component

Migrate the $0 component from $1 to $2.

Step 1: Read the current implementation

Find and read the current $0 component file. Search for it:

  • In src/components/, components/, app/components/, or similar common locations
  • Using grep -r "$0" --include="*.$1*" -l if the framework extension is known (e.g., .vue, .jsx)

Read all files that make up the component:

  • The main component file
  • Any associated style files (.css, .scss, .module.css)
  • Any associated test files (*.test.*, *.spec.*)

If you cannot find the component, stop and ask the user for the file path.

Step 2: Understand props, state, and behavior

Before writing any code, document:

  • All props the component accepts (name, type, default value, whether required)
  • All internal state (what it tracks and how it changes)
  • All events the component emits or callbacks it invokes
  • Side effects (data fetching, subscriptions, DOM manipulation)
  • The rendered structure (what it produces visually or structurally)

This documentation becomes the specification the new implementation must satisfy.

Step 3: Write the equivalent in $2

Write the $0 component in $2, matching the same public API:

  • Same prop names and types
  • Same event names and payloads
  • Same rendered structure (or nearest equivalent in $2)
  • Same behavior for all documented state transitions

Use idiomatic $2 patterns. Do not transliterate $1 patterns directly into $2 if $2 has a better way to express the same thing.

Step 4: Update tests

Rewrite any tests associated with the original component to use $2 testing conventions:

  • Update imports to point to the new component file
  • Update any framework-specific test utilities (e.g., mount from $1 to the $2 equivalent)
  • Preserve all test cases — every behavior tested in $1 must be tested in $2

Step 5: Report what changed and what needs manual review

Produce a brief report:

Changed:

  • List of files created or modified

Preserved:

  • Confirmation that all props, events, and behaviors have equivalents

Needs manual review:

  • Any behavior that could not be automatically preserved (e.g., a lifecycle hook that has no direct equivalent in $2)
  • Any $1-specific third-party libraries used in the original that may not have $2 equivalents
  • Performance characteristics that may differ between frameworks

Do not delete the original $1 component file. Leave that for the user to remove after verifying the migration.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.