Laravel Blade UI Fix Prompt

Public field comparison

Laravel Blade UI Fix Prompt

Laravel Blade UI Fix Prompt

Use this prompt to fix Blade layout, styling, responsiveness, and frontend behavior without breaking existing Laravel logic.

Diagnose and implement evidence-backed Laravel Blade layout, styling, responsiveness, accessibility, and frontend behavior fixes while preserving application logic.

—

Use this prompt to guide Codex through a controlled Laravel Blade UI repair, including render-chain diagnosis, minimal code changes, regression protection, and evidence-based verification.

Laravel Change Review
Database Migration Planning
Zero-Downtime Deployment Review
Rollback Planning
Regression Testing
Production Readiness Checks

Blade layout and component defect diagnosis
Responsive Laravel view repairs
Blade form UI fixes with behavior preservation
Tailwind or Bootstrap conflict resolution in Blade views
Alpine.js or Livewire presentation-layer regression review
Accessibility-focused Blade interface corrections

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Goal and acceptance criteria
Current behavior and reproduction
Relevant files and evidence
Stack and commands
Constraints and authorization

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In Codex, replace every bracketed variable with project-specific information. Provide the relevant Blade views, layouts, components, CSS and JavaScript entry points, screenshots, reproduction steps, console or build errors, framework versions, repository constraints, and authorized test commands. Then run the prompt in the applicable repository workspace and review any proposed edits, command results, and unresolved verification items before approval.

Use this when you need a production-ready coding result in Codex & Coding, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

A Laravel account form overflows on mobile after a Tailwind update. Supply Codex with the route-facing Blade view, parent layout, shared form component, Vite and Tailwind configuration, before-and-after screenshots, viewport targets, reproduction steps, and permitted test commands. The result should trace the render chain, propose or apply a minimal class or markup correction, preserve CSRF and validation behavior, and report responsive and regression evidence without claiming unperformed browser checks.

Expert

Expert

Codex

Codex

coding

coding

laravel
codex
Codex & Coding
blade
frontend

laravel
blade
codex
frontend
responsive-design
accessibility
ui-debugging

Laravel Blade UI Fix Prompt | AMO.ng

Laravel Blade UI Fix Prompt | AMO.ng

Use this prompt to fix Blade layout, styling, responsiveness, and frontend behavior without breaking existing Laravel logic.

Use Codex to diagnose and fix Laravel Blade UI, responsive, accessibility, and frontend defects with controlled edits and evidence-based verification.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Codex & Coding specialist using Codex. Your task is: [Goal or task].
+Fix the specified Laravel Blade UI defect without changing application behavior outside the authorized scope.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+## Inputs
+- Goal and acceptance criteria: [Goal and acceptance criteria]
+- Current behavior and reproduction: [Current behavior and reproduction]
+- Relevant files and evidence: [Relevant files and evidence]
+- Stack and commands: [Stack and commands]
+- Constraints and authorization: [Constraints and authorization]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Laravel Blade UI Fix Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+## Input gate
+Before proposing or editing code, confirm that the supplied material identifies the affected page or component, the observed defect, the intended result, and the relevant Blade render path. Useful evidence includes Blade views and components, parent layouts, CSS or JavaScript entry points, screenshots at named viewport sizes, browser-console output, failed requests, framework versions, and reproducible test or build commands.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+Ask concise clarification questions only when a missing fact blocks a safe diagnosis, such as an unidentified view, ambiguous intended behavior, unavailable component state, or conflicting acceptance criteria. If useful work can continue, state the limitation and proceed with a bounded inspection. Never invent file contents, framework versions, browser observations, command results, or design requirements.
 
−Do not give generic advice. Optimize for a production-quality coding outcome.
+## Codex operating boundaries
+Use Codex to inspect only the files and evidence available in the current workspace or supplied context. Trace references across Blade layouts, includes, components, slots, stacks, asset entry points, and directly related frontend code when access exists.
+
+Default to inspection and a proposed patch. Modify files or run commands only when the supplied authorization permits it and the operation is available in the environment. Do not deploy, publish, merge, push, alter production data, modify environment secrets, install dependencies, clear shared caches, or make unrelated backend changes. Require explicit human approval before destructive commands, dependency changes, broad refactors, generated-file replacement, or any production-facing action.
+
+Stop and report the blocker if credentials or secrets appear in output, the required fix would weaken authorization or validation, the repository state is unexpectedly dirty in affected files, the defect depends on unavailable runtime state, or the requested visual change conflicts with security, accessibility, or preserved application behavior.
+
+## Evidence rules
+Maintain these distinctions throughout the work:
+- Supplied fact: information directly present in the inputs.
+- Inspected observation: content directly observed in an accessible file or tool result.
+- Execution evidence: an actual command, test, build, browser check, or screenshot comparison produced during this run.
+- Assumption: a low-risk premise used to make bounded progress.
+- Hypothesis: a possible cause that still requires confirmation.
+- Unknown or conflict: missing or contradictory information that remains unresolved.
+
+A screenshot may demonstrate appearance but not prove route, form, authorization, or server-side behavior. Static code inspection may identify a likely fix but does not prove runtime rendering. Do not describe work as fixed, tested, responsive, accessible, approved, or deployed unless the corresponding action occurred and evidence is reported.
+
+## Blade UI repair workflow
+1. Establish the change contract
+   - Convert the requested result into observable acceptance conditions, including affected routes or states, target viewport widths, supported themes, interaction states, and elements that must remain unchanged.
+   - Record the authorized files, permitted commands, and prohibited actions.
+
+2. Map the render and asset chain
+   - Identify the route-facing view and its parent layout, Blade components, includes, slots, sections, stacks, and conditional directives.
+   - Identify the styling and behavior source actually used by the page, such as Tailwind CSS, Bootstrap, custom CSS, Vite entry points, Alpine.js, Livewire, or plain JavaScript. Do not assume a package is active merely because it exists in the repository.
+   - Note responsive breakpoints, container rules, display utilities, specificity, asset loading order, and component state that could explain the defect.
+
+3. Protect Laravel behavior
+   - Preserve route targets, HTTP methods, CSRF directives, form field names, old-input handling, validation-error rendering, authorization and authentication directives, localization keys, escaped output, component props, Livewire bindings, Alpine directives, and JavaScript hooks unless the requested change explicitly requires an authorized modification.
+   - Flag any proposed change that could alter server-side branching, request payloads, permissions, or persistence rather than silently treating it as a visual edit.
+
+4. Diagnose the root cause
+   - Reproduce the defect when an authorized runtime and reliable steps are available. Otherwise perform a static diagnosis and mark runtime behavior unverified.
+   - Compare the computed render structure implied by Blade with the relevant CSS and JavaScript behavior. Check malformed HTML, invalid nesting, missing asset imports, conflicting utility classes, specificity, overflow, fixed dimensions, stacking context, focus state, conditional rendering, hydration or initialization order, and stale compiled assets where relevant.
+   - Rank competing hypotheses by evidence and select the smallest defensible correction.
+
+5. Design and apply the minimal change
+   - Prefer a localized, convention-compatible fix over duplicated markup, global overrides, broad `!important` rules, or unrelated refactoring.
+   - Reuse the project's existing component, utility, naming, and breakpoint conventions. Explain any trade-off involving maintainability, browser support, visual fidelity, accessibility, or bundle impact.
+   - If edits are authorized, inspect the current repository state, change only scoped files, and retain a reviewable diff. If edits are not authorized or unavailable, provide a proposed patch without claiming it was applied.
+
+6. Verify proportionately
+   - Blade and asset integrity: run only authorized project commands that can detect template compilation, syntax, lint, type, test, or asset-build failures. Record the exact command, exit status, and relevant output.
+   - Functional preservation: check affected routes, links, form action and method, CSRF handling, field names, validation errors, conditional states, component props, Livewire or Alpine behavior, and browser-console or network errors where applicable.
+   - Responsive behavior: evaluate the named viewport widths and critical content states for overflow, clipping, overlap, wrapping, alignment, readable spacing, and touch-target usability. Include expected and actual observations for each tested viewport.
+   - Accessibility: check semantic structure, labels, keyboard operation, visible focus, error association, alternative text where relevant, contrast implications, reduced-motion behavior, and ARIA state consistency. Do not claim standards conformance from an incomplete check.
+   - Regression scope: inspect shared layouts and components for other consumers. Run the narrowest relevant automated tests first, then broader authorized checks when risk justifies them.
+   - Reconcile every acceptance condition as passed with evidence, failed, blocked, or not run. A proposed or unexecuted check cannot be marked passed.
+
+7. Prepare the handoff
+   - Identify changed or proposed files, residual risks, unresolved questions, manual review needs, and the smallest safe next action.
+   - Provide a rollback method limited to the scoped changes. Do not recommend deleting unrelated work or resetting a repository with uncommitted changes.
+
+## Required output
+### Scope and status
+Provide the affected page or component, observed defect, intended behavior, authorized mode, inspected materials, and overall state chosen from proposed, partially executed, executed but unverified, verified, or blocked.
+
+### Render-chain diagnosis
+List the relevant route-facing view, layout, components or includes, asset entry points, frontend framework features, confirmed root cause, and rejected or unresolved hypotheses. Attach an evidence classification to each material conclusion.
+
+### Change set
+For each changed or proposed file, report its purpose, precise modification, reason, application state, behavior intentionally preserved, and regression exposure. Include a concise unified diff or exact replacement snippets when the environment did not apply edits.
+
+### Verification matrix
+Use columns for acceptance condition, check or command, expected observation, actual observation, evidence, and status. Cover template or build integrity, target visual states, responsive viewports, interaction behavior, Laravel form or directive preservation, accessibility, and shared-component regression as applicable.
+
+### Risk, recovery, and approvals
+Report residual risks, stop conditions encountered, rollback steps, commands or checks not run, unavailable evidence, and any human approval required before further edits, dependency changes, merge, deployment, or production action.
+
+### Next safe action
+End with one concrete action that advances the repair without overstating completion.