Recommend a stack from the product's operating needs. Inspect an existing repository before proposing replacement; continuity, migration cost, and maintainer knowledge are part of fitness.
Work
- Establish public discovery needs, interactive workload, offline needs, data ownership, authentication, integrations, hosting constraints, and who maintains it.
- Separate browser UI, server/API, database, and deployment decisions. A frontend framework does not provide the whole product architecture.
- Map every dependency category to the question it must answer: runtime (where code executes), framework (routing/rendering), API layer (browser-to-server exchange), data access (storage, schema, queries), auth (identity, sessions, checks), hosting (build, deploy, previews). Prefer a scaffolder's current compatibility rules over memory when naming products.
- Compare a primary option and a credible alternative against those constraints. Include keeping the existing stack when applicable.
- Check current official documentation for version-sensitive APIs, support, deployment adapters, licensing, or pricing that affect the recommendation.
- Explain the hardest tradeoff and the condition that would change the decision. Avoid claims about training-data popularity or universal performance advantages.
Deliver
A short decision record: choice, constraints served, cost accepted, deployment/data implications, uncertainty, revisit trigger. Recommend a small feasibility check when integration uncertainty dominates.
Follow this shape:
Recommended: ... Fallback: ... Confidence: High / Medium / Low Constraints served: ... Cost accepted: ... Deployment/data: ... Uncertainty: ... Revisit if: ...
Examples: a content-heavy site may benefit from prerendering or server rendering; a browser editor may favor a client-heavy runtime; an established Vue team may choose a Vue ecosystem solution. Vite is a build tool with SSR capabilities, not proof that SEO is impossible. Next.js is an option, not the default for every dashboard.
Do not scaffold or migrate a project when the request only asks for advice. Use $setup for an authorized foundation change.
Worked example
Recommended: Keep the existing Nuxt app; render marketing routes on the server and keep the dashboard client-heavy. Fallback: Move marketing to a static site generator and leave the dashboard unchanged. Confidence: Medium Constraints served: Marketing SEO and shared metadata; an authenticated dashboard; two maintainers who know Vue; per-PR previews already work on the current host. Cost accepted: New hires who know React learn Vue; no migration spend or feature freeze. Deployment/data: Same host and preview flow; server routes stay the API layer; database and auth unchanged. Uncertainty: Whether the planned canvas editor performs well in the current component model; run a one-day spike before committing. Revisit if: The canvas spike fails, or the team loses its Vue maintainers.
Gotchas
- Recommendations drift toward the framework most common in training data; a pick that would fit every project was not chosen for this one.
- Framework versions change APIs, rendering defaults, and hosting adapters faster than memory; say which claims you checked in current docs.
- Migration cost includes rewriting tests, retraining maintainers, and freezing features; keeping the current stack is a real option.
- A frontend framework quietly decides auth, data access, and hosting unless each layer gets its own line.
- An advice request is not a build request; do not scaffold, install, or migrate without authorization.
Boundaries
- Do not use when the product itself is undecided (who it serves, what it must do); use
$intentinstead. Open details are not a blocker: state them as assumptions and name what would change the choice. - Do not use for a throwaway prototype; use
$prototypeinstead and keep the existing stack.