$stack

# 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.

npx skills add mattjmdesign/dengskills --skill stack