From laravel-superpowers
Use in Laravel projects BEFORE designing or implementing any feature, endpoint, or architectural change. Guides Laravel-specific design decisions: which layer owns the logic, Eloquent relationships, Event/Listener patterns, Policy/Gate design, queuing decisions. In Laravel codebases, invoke this alongside superpowers:brainstorming for the framework-specific layer. ALWAYS trigger when adding new functionality, designing a new endpoint, planning a new model relationship, or choosing between architectural patterns in Laravel.
npx claudepluginhub altraweb/laravel-superpowers --plugin laravel-superpowersThis skill uses the workspace's default tool permissions.
Generic brainstorming surfaces requirements and design. This skill adds the **Laravel-specific layer**: which of Laravel's tools to use, where the logic lives, and how the pieces connect.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Generic brainstorming surfaces requirements and design. This skill adds the Laravel-specific layer: which of Laravel's tools to use, where the logic lives, and how the pieces connect.
Run this after the generic superpowers:brainstorming flow surfaces what you're building, before any code.
Do NOT write code or an implementation plan until you've answered the key architectural questions below. Architectural decisions are much cheaper to change on paper than in code.
php artisan route:list # what routes exist already?
php artisan model:show ModelName # what does the model look like?
ls app/Actions/ app/Services/ # what patterns are already in use?
ls app/Http/Controllers/ # what naming convention?
The most important question: what patterns does this project already use? Follow them. Don't introduce a new architecture pattern unless the existing one is clearly broken.
Ask and answer each of these before proposing implementation:
| Option | Use When |
|---|---|
| Controller | Simple CRUD, no business logic beyond validation |
| Form Request | The logic is purely about validating and authorizing the request |
Action class (app/Actions/CreatePost.php) | Single-purpose business operation, reusable, needs testing in isolation |
Service class (app/Services/BillingService.php) | Multiple related operations grouped together, or external API wrapping |
| Eloquent Model method | Logic is inherently about that model's data (scopes, accessors, relationship-based) |
Job (app/Jobs/) | The operation is slow (>200ms), can fail and retry, or must be async |
| Event + Listener | Side effects that should be decoupled (send email after payment, update stats after login) |
Recommendation heuristic:
For any new model or relationship:
hasOne, hasMany, belongsTo, belongsToMany, morphTo?withCount, withSum, or other aggregates?php artisan model:show ExistingModel # see existing relationships
Queue it if:
Don't queue it if:
| Scenario | Tool |
|---|---|
| Simple role check | Gate::define() in AuthServiceProvider |
| Resource-level permission (can this user update this post?) | Policy class |
| Row-level scope (only see own posts) | Eloquent global scope or local scope |
| Multi-tenant access | Middleware + Eloquent scope combination |
Always write a test for the authorization path (both allowed and denied case).
| Scenario | Tool |
|---|---|
| Simple, used in one place | Inline in controller: $request->validate([...]) |
| Complex, or reused | Form Request: php artisan make:request StorePostRequest |
| API — consistent error format | Form Request (auto-returns 422 with JSON errors for API requests) |
Form Requests also handle authorization (authorize() method) — useful to keep auth + validation co-located.
Present the options with trade-offs and a clear recommendation.
Format:
Option A — [Name]
Option B — [Name]
Recommended: Option [X] because [reason]
For the chosen approach, list every side effect explicitly:
Side effects that aren't listed here will be forgotten until production.
Before writing code, draft the test cases:
This shapes the implementation — you'll know exactly what you're building toward.
| Mistake | Better Approach |
|---|---|
| Fat controllers (50+ line methods) | Extract to Action or Service |
| Business logic in Blade templates | Move to controller/service, pass data down |
env() outside config files | Always config('key') in application code |
| Relationship queries in loops | Eager load with with() |
| Synchronous external API calls in request lifecycle | Queue via Job |
Using User::all() anywhere | Always paginate or limit |
$request->all() for mass assignment | Explicit $request->validated() or $request->only([...]) |
| Checking auth in controller manually | Delegate to Policy + authorize() |
Actions (popularized by Loris Leiva):
execute() or handle() methodRepository Pattern (use sparingly in Laravel):
CQRS (Command/Query separation):
Event-Driven side effects (Laravel native):
OrderPlaced event → SendOrderConfirmation, UpdateInventory, NotifyWarehouse listenersAfter alignment, write a brief design note to docs/laravel/YYYY-MM-DD-<feature>-design.md:
Then proceed to implementation with superpowers:writing-plans or superpowers:executing-plans.