Vite · apply by default
/vite-setup
Configure Vite for the framework and project requirements
Use to add or repair Vite project wiring, including moving an existing webpack or Create React App project to Vite; vite-upgrade changes an existing version and migrate plans multi-step platform transitions beyond the bundler.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select vite-setup from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv vite-setup, /just-vibe vite-setup and /jv:vite-setup in Claude. See shortcut setup and context examples.
/just-vibe:vite-setup Set up Vite for this existing React app without replacing source files./just-vibe:vite-setup Configure Vite in an existing React workspace served under /dashboard/./just-vibe:vite-setup Inspect setup requirements without installing dependencies or overwriting source.What the agent does
- Inspect the existing setup, package manager, workspace root, framework plugin and Node support.
- Choose compatible plugins and establish dev, build and preview scripts using project conventions, preserving existing source and entry files.
- Validate the development, production and subpath paths.
Inputs
- framework, language, project location, deployment shape, and dependency constraints.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Vite configuration and required scripts/integration; no app redesign or unrelated toolchain replacement.
- Writes
- Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
- Mode
- Apply; framework, language, project location, deployment shape, and dependency constraints.
- Prerequisites
- Project manifests, lockfile, Vite/framework/plugin versions, and existing build scripts. Verify current version-specific documentation when changing configuration. Requested isolated verification may generate disposable build/cache artifacts; inspect their scripts first and preserve product files.
Expected output
- Working setup with dependency, configuration and script changes, usage, and dev/production/subpath check results.
How the work is checked
- The existing app builds; deploying under the requested base path resolves assets correctly.
When to stop or clarify
- Do not overwrite an existing project with a template. Respect no-new-dependency constraints and unsupported framework combinations.
Handling missing context
- Infer
- Read manifests, lockfile, installed Vite/plugins, entry points, aliases, modes and current build scripts.
- Assume
- Preserve existing tooling and base-path conventions; in apply mode, make a local focused change when the brief identifies the behavior, and otherwise propose it.
- Ask
- Ask if the intended serving subpath or deployment target cannot be inferred and would change generated URLs; do not ask for versions present in the lockfile.
Technical guidance
- Evidence
- Inspect framework, installed Node/Vite/plugin versions, workspace scripts, module format and deployment base path.
- Method
- Adapt the existing build convention; align dev entry, production output and asset resolution using supported version-specific settings.
- Pitfall
- Copying a config for another major or adding a second package manager can create a setup that only works on one machine.
- Check
- Verify dev startup, production build and a direct nested route against generated output with the chosen package manager.
Situational decisions
When an existing app already has a bundler or non-root deployment path: Plan an explicit transition and base-path handling rather than copying a new template over it.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.