| name | project-analysis-symfony |
| description | Use for deep Symfony project analysis: kernel/bootstrap, container wiring, routing/request flow, Doctrine, security, Messenger, and Symfony-specific failure patterns. |
| source | package |
project-analysis-symfony
When to use
Use this skill when:
- The project uses Symfony
- A deep Symfony-specific analysis is needed
universal-project-analysis routes here after framework detection- The issue spans kernel boot, DI, Doctrine, security, or Messenger
Do NOT use when:
- The task is a small isolated Symfony code change
- The issue is already narrowed to a different specialist skill
- The project is not actually Symfony
Core principles
- Symfony behavior is highly container-driven
- Environment-specific config changes meaningfully affect runtime
- Service wiring and priority/order issues are common
- Doctrine and Messenger often hide critical operational behavior
- Security configuration must be traced end-to-end
Procedure
1. Confirm Symfony version and app shape
Check: composer.lock, composer.json, Symfony packages/components, PHP version, environment config structure.
Validate: Symfony version is explicit, major bundles/components are identified, environment-specific config layout is known.
2. Analyze kernel and container boot
Inspect: Kernel bootstrap, bundle registration, compiler passes, services.yaml, autowiring/autoconfigure patterns, manual aliases/bindings, cache warmup/compiled container assumptions.
Check:
- autowiring conflicts
- decoration order
- tagged service priority
- circular dependency symptoms
- private/public service misuse
3. Trace request-to-response flow
Trace: route → request listeners/subscribers → controller → service layer → repository/Doctrine → serializer/forms → response.
Validate: request lifecycle is visible, security checks are visible, serializer/form behavior is explicit, response transformation path is clear.
4. Analyze Doctrine and persistence
Inspect: entity mapping, repositories, lifecycle callbacks, subscribers/listeners, migration posture, DQL/QueryBuilder/native SQL usage.
Check:
- schema drift
- proxy/lazy-loading issues
- N+1 behavior
- wrong lifecycle hook usage
- transaction boundaries
5. Analyze security and Messenger
Inspect: firewalls, authenticators, voters, access rules, Messenger transports, handler routing, retry/failed-message behavior.
Check:
- auth flow correctness
- firewall separation/context sharing
- voter assumptions
- failed-message handling
- serialization/transport issues
6. Validate Symfony analysis quality
Check:
- kernel/container behavior is explicit
- request/security/doctrine paths are mapped
- version-specific Symfony behavior was considered
- Messenger/security risks are evidence-based
- next specialist skill is clear if needed
Output format
- Symfony version and app summary
- Kernel/container findings
- Request/security flow
- Doctrine findings
- Messenger/async findings
- Key risks and next steps
Gotcha
- In Symfony, configuration and service wiring often explain more than the controller code.
- Compiler passes, decorators, tags, and priorities can change behavior in non-obvious ways.
- Doctrine and Messenger issues often appear as "application bugs" but originate in framework integration details.
Do NOT
- Do NOT analyze Symfony without explicit version context
- Do NOT ignore service wiring and container behavior
- Do NOT treat Doctrine entities as simple data objects without lifecycle effects
- Do NOT skip security/firewall flow when access issues exist
- Do NOT ignore Messenger transport and retry behavior in async problems
