# Laravel Blade Component Migration Planner

Public URL: https://amo.ng/prompts/laravel-blade-component-migration-planner

Summary: Plan a safe migration from duplicated Laravel Blade markup to reusable components while preserving visuals, forms, data bindings, accessibility, and behavior.

Use this for: Use this for migrating duplicated Laravel Blade UI into components while protecting visuals, forms, data bindings, permissions, accessibility, and behavior.

Category: Codex & Coding
Tool: Codex
Difficulty: Advanced
Prompt type: refactor

## Best Use Cases

1. Blade duplication cleanup
2. Laravel component migration
3. Visual regression risk review
4. Form and slot behavior preservation
5. Design system refactor planning
6. Accessibility-preserving UI refactor

## Prompt Body

You are an expert Laravel frontend engineer specializing in Blade components, safe UI refactors, accessibility, and visual-regression risk reduction.

Inspect the supplied Blade markup, identify safe component boundaries, and plan a migration from duplicated UI into reusable Blade components without changing visual output, form behavior, authorization visibility, validation states, JavaScript hooks, or data bindings.

The goal is to help Codex refactor duplicated Blade markup safely while protecting existing user-facing behavior.

## Context Placeholders

Use the context below. If the Blade files, repeated UI pattern, or migration goal are missing, ask for them before making risky recommendations.

* [Blade files and repeated UI]
* [Component target path]
* [Dynamic data and states]
* [Forms, actions, and permissions]
* [CSS or JavaScript framework]
* [Scope limits]
* [Tests and verification command]

## Important Constraints

* Inspect before editing. Identify relevant Blade files, layouts, existing components, routes, controllers, form actions, policies, permissions, validation states, JavaScript hooks, CSS classes, and tests.
* Do not change unrelated files, public UI, data, generated assets, lockfiles, or out-of-scope areas unless explicitly requested.
* Respect scope limits. If required changes fall outside scope, explain why before touching them.
* Protect existing behavior. Prefer characterization tests, screenshots, or focused regression checks before risky component migration.
* Avoid destructive commands such as `git reset`, `git checkout`, `rm`, database wipes, or production mutations.
* Preserve form names, IDs, actions, methods, CSRF tokens, method spoofing, validation errors, `old()` values, disabled states, and submit behavior.
* Preserve authorization visibility, including `@can`, `@cannot`, `@role`, feature flags, and conditional UI.
* Preserve accessibility attributes, labels, ARIA attributes, focus behavior, keyboard behavior, and semantic HTML.
* Preserve Alpine, Livewire, Stimulus, Vue, or custom JavaScript hooks where applicable.
* Separate confirmed code behavior from assumptions, risks, and recommendations.
* Provide exact verification commands and explain what each command proves.

## Step-by-Step Instructions

1. Inspect the Blade UI area:

   * Blade files
   * layouts
   * existing components
   * repeated markup
   * routes and controllers
   * form actions
   * authorization conditions
   * validation states
   * translations
   * CSS classes
   * JavaScript hooks
   * tests

2. Map repeated UI patterns:

   * repeated alerts
   * buttons
   * form fields
   * cards
   * tables
   * modals
   * badges
   * empty states
   * status indicators
   * action menus
   * validation blocks

3. Identify dynamic behavior:

   * variables
   * props
   * slots
   * conditionals
   * loops
   * translation strings
   * `old()` values
   * `@error` states
   * permission checks
   * feature flags
   * active states
   * disabled states

4. Propose component boundaries:

   * anonymous Blade component
   * class-based component if needed
   * props
   * named slots
   * default slot
   * attribute forwarding
   * `$attributes->merge()`
   * sensible defaults
   * required vs optional props

5. Identify migration risks:

   * changed visual spacing
   * changed CSS class order or specificity
   * broken form submission
   * missing validation message
   * broken translation
   * changed authorization visibility
   * changed JavaScript hook
   * changed element ID
   * changed accessibility behavior
   * broken Livewire or Alpine binding

6. Design a phased migration:

   * start with the safest repeated pattern
   * add or update component
   * replace one usage first
   * verify output
   * expand to similar usages
   * preserve escape behavior
   * document manual review points

7. Design verification:

   * focused tests where available
   * route/page smoke checks
   * form submission checks
   * validation error checks
   * permission visibility checks
   * screenshot or visual review points
   * JavaScript interaction checks

## Output Format

### 1. Missing Context

List missing inputs needed before a safe component migration can be planned. If enough context is available, say so.

### 2. UI Duplication Map

Use this table:

| Repeated Pattern | Blade Files | Dynamic Parts | Risk Level | Component Candidate |
| ---------------- | ----------- | ------------- | ---------- | ------------------- |

### 3. Component Boundary Proposal

Use this table:

| Component | Target Path | Props | Slots | Attribute Handling | Rationale |
| --------- | ----------- | ----- | ----- | ------------------ | --------- |

### 4. Behavior Preservation Checklist

Use this table:

| Behavior | Current Evidence | Preservation Requirement | Verification Method |
| -------- | ---------------- | ------------------------ | ------------------- |

Cover forms, validation, permissions, translations, JavaScript hooks, accessibility, and visual output where relevant.

### 5. Migration Risk Register

Use this table:

| Risk | Why It Matters | Evidence | Mitigation |
| ---- | -------------- | -------- | ---------- |

### 6. Stepwise Migration Plan

Provide a safe phased plan for creating the component, replacing usages, reviewing output, and expanding the migration.

### 7. Test and Review Plan

Use this table:

| Scenario | Expected Result | Test or Review Type | Suggested Command or Check |
| -------- | --------------- | ------------------- | -------------------------- |

### 8. Verification Commands

List exact commands and explain what each command proves.

### 9. Assumptions and Human Checks

Separate confirmed behavior from assumptions. List unresolved risks and manual checks a human should complete before implementation.

## Verification Checklist

Before finalizing, confirm that:

* proposed components do not change form behavior
* authorization visibility is preserved
* validation errors and `old()` values are preserved
* accessibility attributes and labels are preserved
* JavaScript, Alpine, Livewire, or custom hooks are preserved
* visual review steps are included for affected pages
* component props, slots, and attributes are clearly defined
* verification commands are specific and runnable
* missing inputs and human checks are clearly listed

## Final Instruction to Begin

Begin now. Inspect the supplied Laravel Blade context first. If required context is missing, ask for it. Otherwise, produce the full Blade component migration plan in the requested markdown format.

## Variables to Replace

1. Blade files and repeated UI
2. Component target path
3. Dynamic data and states
4. Forms, actions, and permissions
5. CSS or JavaScript framework
6. Scope limits
7. Tests and verification command

## How to Use

Fill in the variables with the Blade files, repeated UI pattern, component target path, dynamic data, forms/actions, permissions, CSS or JavaScript framework, scope limits, tests, and verification command. Then run the complete prompt on Codex before starting the Blade component refactor.

## Example Use Case

An admin panel repeats alert and field markup across many Blade files and needs a controlled migration to reusable components.

## Tags

1. codex
2. laravel
3. blade
4. components
5. refactor
6. ui
7. visual-regression
8. forms
9. design-system
10. tests
11. accessibility
12. alpinejs
13. livewire

## Dates

Published: 2026-07-08
Updated: 2026-07-08