Respect explicit user choices and required platform, runtime, and compatibility contracts. Surface conflicts rather than silently replacing a requirement.
Compare actual libraries and tools before choosing a language. A domain label or popularity ranking is not evidence of feature coverage.
Include alpha, beta, release candidate (RC), preview, and nightly versions when they are credible candidates. Do not exclude them by release label alone; compare required capabilities, known gaps, compatibility, maintenance, and upgrade/rollback costs against stable alternatives. A newer label alone is not a reason to adopt one either.
Keep supported existing choices unless the requested change justifies replacing them. For a rewrite, compare retaining or incrementally adapting the current stack.
Prefer mise for Node.js and pnpm/Yarn versions when the backend fits. Use Corepack for required Corepack behavior or a verified compatibility exception; check selector precedence, integrity, command ownership, and CI through the toolchain reference before adoption.
Default to TypeScript over JavaScript for newly authored JS-ecosystem code, including Node.js utilities, build/release scripts, tests, and Electron code. Small size, direct execution, or avoiding a build step alone does not justify JavaScript. Choose JavaScript only for an explicit user choice or a concrete compatibility or technical-cost constraint; explain the exception and scope it to the affected files. See TypeScript.
Across different ecosystems, use TypeScript/Rust preferences when technical fit and lifecycle costs are comparable. Exclude team experience, familiarity, staffing, and training cost.
For lightweight Node.js scripts, prefer native TypeScript execution when the supported runtime and erasable syntax fit. Use tsx for a concrete transform or resolution need. Both paths require @tsconfig/strictest, application-owned @total-typescript/ts-reset, and independent type checking; see the TypeScript reference for setup and publication boundaries.

These rules apply to every reference and diagram. Diagram leaves identify candidates, not mandates; investigate cases the diagrams do not cover.

Workflow

flowchart TD
    A[Request] --> B{New project, whole-system change,<br/>or explicit stack evaluation?}
    B -->|No| C[Use the focused workflow;<br/>keep the current stack]
    B -->|Yes| D[Identify required capabilities<br/>and fixed contracts]
    D --> E[Compare ecosystem evidence<br/>and technical costs]
    E --> F{Enough evidence to decide?}
    F -->|Yes| G[Recommend a fitting choice;<br/>apply preferences when comparable]
    F -->|No| H[Check the decisive capability<br/>or state what remains provisional]

Establish the deliverable, required operations, target platforms, distribution, and contracts. Resolve unknowns only when they could materially change the choice.
Read language selection, then only the relevant references below. Compare credible alternatives on feature coverage, ecosystem maintenance, integration, deployment, and technical maintenance costs.
Verify decisive claims against version-matched official sources. If capability coverage is uncertain, use a small representative check. Select compatible versions from the relevant release channels; record the channel, exact tested version, adoption evidence, and unresolved risks. Plan reproducible pins in project config and lockfiles, especially for prereleases and nightlies.
Return the choice, main tradeoffs, supporting links, open questions, and checks needed before adoption. For a rewrite or port, include parity, migration, and rollback. Selection alone does not authorize installation, implementation, or Git changes.

References

Read when	Reference
Choosing languages or researching an unfamiliar domain	Languages and ecosystem fit
Selecting environments, hooks, workspaces, or release tooling	Toolchain
Selecting Node.js and pnpm/Yarn version ownership or evaluating Corepack	Node.js package managers
TypeScript libraries or web tooling are involved	TypeScript
Choosing web frameworks, rendering, styles, or shared state	Web
Selecting a renderer for Mermaid diagram source	Diagram rendering
Selecting syntax highlighting for code display	Syntax highlighting
Choosing internationalization runtime or locale-management tooling	Internationalization
Choosing service capabilities and integration boundaries	Backend
React is a candidate or already selected	React
Evaluating Rust	Rust
Evaluating Go	Go
Evaluating shared application UI with Flutter/Dart	Flutter
Evaluating Android, JVM, or Kotlin Multiplatform	Kotlin
Evaluating Apple applications and native integrations	Swift

For React applications, use the web and TypeScript references alongside React. For mixed stacks, read the relevant ecosystem references and define the boundary. Technical sources were reviewed on 2026-10-27; recheck relevant releases and integrations.

Output and evidence

Lead with the recommendation. Use a short comparison when alternatives matter: required capability, candidate, evidence, and technical cost. Separate verified support, assumptions, and personal preferences; date decisive external evidence. Use the repository's decision record format when available.

Scale investigation to the decision. A design request needs justified choices and a verification plan, not installation of the proposed stack. Reference validation lists describe adoption checks: packed consumers for libraries, production routes for sites, and target execution for native tools. Report checks actually run separately from planned checks.

Related skills

vp-autodev when the selected design proceeds through authorized implementation and delivery.
vp-deps-migrate when an isolated dependency replacement or migration mechanics own the next step.
vp-typescript-best-practices when implementing or reviewing TypeScript type boundaries.
vp-design-reasoning when conceptual boundaries, workflow ownership, or architecture scenarios need clarification before or alongside technology selection.

vp-stack-selection

Stack Selection

Decision rules