Stack fit
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: Next.js (App Router)
Fallback: React + Vite SPA with a thin API
Confidence: High
Constraints served: Marketing SEO and shared metadata plus an authenticated dashboard in one product; team deploys on Vercel and wants per-PR previews.
Cost accepted: Server/client boundary discipline; avoid use client creep on the marketing surface.
Deployment/data: app/(marketing) and app/(dashboard) groups; server components for initial data, TanStack Query for client freshness; Tailwind v4 tokens.
Uncertainty: Dashboard interactivity may outgrow server rendering; run a small client-island spike if canvas editing appears.
Revisit if: The dashboard becomes a canvas-heavy tool where instant HMR and a custom runtime matter more than SEO.
Gotchas
- Advise only when asked; do not scaffold or migrate without authorization.
- Inspect the existing repository before proposing replacement; account for migration cost and maintainer knowledge.
- Separate browser UI, server/API, database, and deployment decisions; do not let one framework dictate all four.
- Verify version-sensitive claims in current official docs; do not justify by popularity or universal performance.
- State the hardest tradeoff and revisit trigger; do not present the recommendation as unconditional.
Boundaries
- Do not use when product intent or requirements are unresolved — clarify with
$intent or $requirements first; a stack choice without them is speculative.
- Do not use for a throwaway prototype — use
$prototype instead.
1---2name: stack3description: Choose or revisit a product stack using rendering, data, deployment, and maintenance constraints. Use when comparing frameworks, when SEO, auth, or deploy targets constrain the choice, or when revisiting an existing stack.4---56# Stack fit78Recommend 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.910## Work1112- Establish public discovery needs, interactive workload, offline needs, data ownership, authentication, integrations, hosting constraints, and who maintains it.13- Separate browser UI, server/API, database, and deployment decisions. A frontend framework does not provide the whole product architecture.14- 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.15- Compare a primary option and a credible alternative against those constraints. Include keeping the existing stack when applicable.16- Check current official documentation for version-sensitive APIs, support, deployment adapters, licensing, or pricing that affect the recommendation.17- Explain the hardest tradeoff and the condition that would change the decision. Avoid claims about training-data popularity or universal performance advantages.1819## Deliver2021A short decision record: **choice, constraints served, cost accepted, deployment/data implications, uncertainty, revisit trigger**. Recommend a small feasibility check when integration uncertainty dominates.2223Follow this shape:2425**Recommended:** ...26**Fallback:** ...27**Confidence:** High / Medium / Low28**Constraints served:** ...29**Cost accepted:** ...30**Deployment/data:** ...31**Uncertainty:** ...32**Revisit if:** ...3334Examples: 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.3536Do not scaffold or migrate a project when the request only asks for advice. Use `$setup` for an authorized foundation change.3738## Worked example3940**Recommended:** Next.js (App Router)41**Fallback:** React + Vite SPA with a thin API42**Confidence:** High43**Constraints served:** Marketing SEO and shared metadata plus an authenticated dashboard in one product; team deploys on Vercel and wants per-PR previews.44**Cost accepted:** Server/client boundary discipline; avoid `use client` creep on the marketing surface.45**Deployment/data:** `app/(marketing)` and `app/(dashboard)` groups; server components for initial data, TanStack Query for client freshness; Tailwind v4 tokens.46**Uncertainty:** Dashboard interactivity may outgrow server rendering; run a small client-island spike if canvas editing appears.47**Revisit if:** The dashboard becomes a canvas-heavy tool where instant HMR and a custom runtime matter more than SEO.4849## Gotchas5051- Advise only when asked; do not scaffold or migrate without authorization.52- Inspect the existing repository before proposing replacement; account for migration cost and maintainer knowledge.53- Separate browser UI, server/API, database, and deployment decisions; do not let one framework dictate all four.54- Verify version-sensitive claims in current official docs; do not justify by popularity or universal performance.55- State the hardest tradeoff and revisit trigger; do not present the recommendation as unconditional.5657## Boundaries5859- Do not use when product intent or requirements are unresolved — clarify with `$intent` or `$requirements` first; a stack choice without them is speculative.60- Do not use for a throwaway prototype — use `$prototype` instead.
mattjmdesign