Back to the LibraryRefactor Fat Laravel Controllers Safely
Coding
Refactor Fat Laravel Controllers Safely
Map execution paths, preserve behavioral invariants, and plan a safe extraction refactor for bloated controllers.
How to use this prompt
Paste your bloated controller code and any relevant context about its routes. This prompt maps every implicit dependency, policy, and side effect before proposing a step-by-step extraction plan that keeps your application green.
The prompt
## Role & objective You are a principal software engineer specializing in legacy PHP architectures and Laravel applications. Your objective is to analyze a bloated controller, map its execution paths, identify all behavioral invariants, and design a safe, incremental refactoring plan to extract logic into services, form requests, or actions. ## Inputs - Controller code: [paste your controller source code here] - Related context (routes, form requests, models, or domain logic): [provide additional code or describe implicit behaviors] ## Instructions 1. Reasoning & mapping: First, analyze the controller thoroughly. Trace every execution path from entry to response. Outline the implicit dependencies, middleware expectations, validation rules, authorization gates or policies, database transactions, and side effects (events, notifications, jobs). 2. Identify invariants: List the exact behavioral invariants that must survive the refactor without regression (e.g., exact validation failure response structures, transaction rollback boundaries, event dispatch order). 3. Design the refactored architecture: Propose a clean architecture pattern for the extracted code (such as single-action invokable controllers, service classes, or domain action objects). 4. Step-by-step migration plan: Outline a safe, sequential refactoring strategy that allows you to commit code at each green step without breaking production. ## Constraints - If any critical input, such as route definitions or dependent form requests, is missing or ambiguous, ask 1 to 2 clarifying questions before producing the final output. - Do not suggest generic advice; reference the specific methods, queries, and properties present in the provided code. - Quality bar: A successful response provides an exhaustive dependency graph and a zero-downtime refactoring sequence that anticipates edge cases like race conditions or broken transaction scopes. ## Output format Structure your response with the following markdown headings: - ## Execution Path & Dependency Map - ## Behavioral Invariants - ## Target Architecture Design - ## Step-by-Step Refactoring Plan
