Use for deep Laravel project analysis: boot flow, request lifecycle, container usage, Eloquent/data flow, async systems, and Laravel-specific failure patterns.
Scanned 6/5/2026
Install via CLI
openskills install event4u-app/agent-config---
model_tier: high
name: project-analysis-laravel
description: "Use for deep Laravel project analysis: boot flow, request lifecycle, container usage, Eloquent/data flow, async systems, and Laravel-specific failure patterns."
domain: discovery
workspaces:
- engineering
packs:
- laravel
trust:
level: professional
install:
default: false
removable: true
---
# project-analysis-laravel
## When to use
Use this skill when:
* The project uses Laravel
* A deep Laravel-specific architecture or runtime analysis is needed
* `universal-project-analysis` routes here after framework detection
* A broad issue spans routes, middleware, services, models, queues, config, or infrastructure
Do NOT use when:
* The task is a small isolated Laravel coding change
* The issue is already narrowed to a specific specialist skill
* The project is not actually Laravel
## Core principles
* Installed Laravel version controls behavior
* Boot order matters
* Middleware order matters
* Container behavior must be traced, not assumed
* Eloquent behavior often hides real execution cost
* Async boundaries create hidden state problems
## Procedure
### 1. Confirm Laravel version and runtime
Check: `composer.lock`, `composer.json`, `artisan --version`, PHP version and runtime environment.
Validate: Laravel version is explicit, major supporting packages are identified, deployment/runtime shape is known.
### 2. Analyze boot and configuration
Inspect: service providers, provider registration order, config files, cached config/route state, middleware registration, route groups and prefixes, env/config interaction.
Check:
* config caching risks
* `env()` usage outside config
* provider misuse
* route cache assumptions
* driver choices for queue/cache/mail/session/filesystem
### 3. Trace request-to-response flow
Trace: route → middleware → FormRequest/validation → controller → service/action → model/repository/query → events/observers → response transformation.
Validate: authorization path is visible, validation path is visible, transaction boundaries are visible, hidden side effects are identified.
### 4. Analyze data and Eloquent flow
Inspect: migrations, model relationships, casts/enums/json usage, soft deletes, nullable assumptions, eager/lazy loading, indexes and query shape.
Check:
* N+1 risks
* mismatches between schema and model assumptions
* unexpected model event behavior
* wrong relationship direction or ownership
### 5. Analyze async and infrastructure flow
Inspect: queued jobs, event listeners, scheduled commands, broadcasting, cache invalidation, mail/notification side effects, external HTTP integrations.
Check:
* serialization risks
* tenant/user context loss
* idempotency
* retry loops
* stale cache / eventual consistency
* side effects inside transactions
### 6. Analyze test posture
Check: feature tests, unit tests, integration coverage, factories/seeders/fakes, missing tests on critical paths.
Validate: risky paths have test coverage, async behavior has meaningful tests, infrastructure assumptions are testable.
### 7. Validate Laravel analysis quality
Check:
* boot flow is explicit
* request/data/async boundaries are mapped
* Laravel version-specific behavior was considered
* hidden framework side effects are identified
* next specialist skill is clear where needed
## Output format
1. Laravel version and runtime summary
2. Boot/config findings
3. Request-to-response flow
4. Data/Eloquent findings
5. Async/infrastructure findings
6. Test posture
7. Key risks and next steps
## Gotcha
* Laravel hides complexity behind convenient abstractions.
* Middleware, observers, facades, and Eloquent can make execution flow look simpler than it is.
* Cached config/routes can make the real runtime differ from the source code.
## Do NOT
* Do NOT assume Laravel behavior without version context
* Do NOT stop at controller/service level if observers, jobs, or events are involved
* Do NOT ignore middleware order
* Do NOT ignore config/cache/runtime differences
* Do NOT treat Eloquent convenience as proof of correctness or performance
No comments yet. Be the first to comment!