event4u-app analysis-skill-router
A chooser, not a worker. It answers exactly one question — which skill — and then gets out of the way. How to actually carry out the work belongs to whichever skill this picks; a chooser that also explains the work reads like its own fallback target, which is the defect this file was cut back from.
When to use
Use this skill when:
- A request may need deep analysis
- It is unclear which analysis skill should be used
- Multiple analysis skills could plausibly apply
- The stack/framework is known but the correct analysis path is unclear
analysis-autonomous-modeneeds a routing decision
Do NOT use when:
- The correct specialist skill is already obvious
- The task is not an analysis task
- The task is normal implementation work without investigation needs
Procedure
1. Classify the scope
Pick one: full project · architecture review · broad multi-layer debugging · framework-specific deep dive · narrow root cause · performance/security specialist · simple local issue.
Broad scope requires a reason. At least one must hold, or the answer is a narrow specialist: the user asked for breadth · the system is unknown · the issue spans layers · architecture must be reconstructed · the cause is non-local.
2. Detect the framework
Laravel · Symfony · Zend/Laminas · Node/Express · React · Next.js · unknown or mixed.
3. Read the decision table
| Signal | Route to |
|---|---|
| Full audit, or unclear stack | universal-project-analysis |
| Unknown system, discovery-focused | project-analysis-core |
| Concrete problem, several plausible causes | project-analysis-hypothesis-driven |
| Bug-focused, not full-project | bug-analyzer |
| Laravel | project-analysis-laravel |
| Symfony | project-analysis-symfony |
| Zend/Laminas | project-analysis-zend-laminas |
| Node/Express | project-analysis-node-express |
| React state / render / hooks | project-analysis-react |
| Next.js SSR / cache / hydration | project-analysis-nextjs |
| Bottleneck | performance-analysis |
| Security concern | security-audit |
Tie-break: the narrowest row that still covers the request wins.
Output format
- The selected skill.
- The signal from step 1–2 that selected it.
- Why the next-broader row lost, when one was plausible.
- Any skill to chain afterwards — or "none".
One or two lines total. A routing verdict longer than the request it routes is itself a routing failure.
Examples
| Request | Route |
|---|---|
| "Analyze this whole Laravel project" | universal-project-analysis, chain project-analysis-laravel |
| "Hydration mismatch in Next.js" | project-analysis-nextjs — no full-project step |
| "Could be cache, queue, or a version mismatch" | project-analysis-hypothesis-driven |
| "Change one React component" | none — implementation skill |
Gotcha
- Size adjectives read as scope. "Our whole Laravel app is slow" picks the broad row on the word "whole", and the audit then spends its passes rediscovering a stack the request already named. The step-2 framework signal outranks size words — those are how frustration sounds, not scope.
- Breadth feels safe and costs sharpness. The most expensive choice is rarely the best one once the problem is already localised.
- Steps 1 and 2 disagreeing is a question, not a tie-break. Ask which the user meant instead of picking the broader row to be safe.
Do NOT
- Do NOT default to
universal-project-analysis - Do NOT choose a generic skill when a framework-specific row fits
- Do NOT confuse discovery with root-cause investigation
- Do NOT re-import procedure, validation checklists, or output contracts from the skills in the table — that is what this file was cut back from