A slow linter wasn't the problem

My commands were spread across ESLint, Prettier, TypeScript, a test runner, and package.json scripts. When I let an agent into the project, its first job was figuring out which command was the right one. I wrote instructions to explain that. Now I had another file to maintain. Excellent time saver, right?

It wasn't just the number of files. Once, my local setup and CI checked a generated file differently. The agent saw one result; the pipeline saw another. Faster component generation doesn't fix that.

Vite+ brings everyday tasks under vp: Vite for development and builds, Vitest for tests, Oxlint and Oxfmt for checks, tsdown for libraries, and Vite Task for tasks. You can keep their configuration in vite.config.ts. You still have package.json, tsconfig, and, depending on the project, framework configuration. “One file for absolutely everything” would look good on a banner and bad in a real repo.

For a React app, these are the commands I need after creating the project:

Shell

1vp create vite -- --template react-ts 2cd project-name 3vp install 4vp dev 5vp check 6vp test 7vp build

The commands above assume vp is available globally. A global install is optional; you can also run Vite+ as a local dependency through a package manager. vp install uses the package manager selected for the project, so Vite+ doesn't replace npm or pnpm.

Creating a project with vp create.

I don't let the agent guess what “done” means

The Vite+ docs include a prompt for AI assistants. It's a useful starting point, but I adapt it to the project. My goal is concrete: the agent should use Vite+ to set up the app and not quietly abandon it after generating the first page.

Text

Create a new React + TypeScript app on Vite using Vite+. First read the current `vp create` guide and run `vp help create`. Inspect the target directory and do not overwrite existing files. Choose the current stable Vite+ release and one package manager. Create the project with `vp create` using the React + TypeScript template. Keep its single lockfile. Do not add another linter or formatter unless there is a specific reason. After setup, run `vp install`, `vp check`, and relevant tests with `vp test`, and run a production `vp build`. Add a test for the behavior you implemented. If a check fails, fix the cause and rerun it. In your final report, list the Vite+ version, commands, and actual results.

I don't require a global install via curl in every project. For a one-off setup, something like npx --package=vite-plus@1.3.0 vp create is enough; in an established project, the agent can run the local CLI through the selected package manager. I don't ban create-vite, either: vp create vite uses that template. What matters is that the agent follows the intended setup and keeps one consistent toolchain.

When I gave an agent free rein, I ended up with both Prettier and Oxfmt, three lockfiles, and unreliable CI. Banning a second formatter and requiring one lockfile aren't aesthetic preferences. They're two mistakes I don't want to clean up again.

One command gives me fast feedback

After changing code, I run vp check. It checks formatting and lint; it checks TypeScript when both typeAware and typeCheck are enabled in the configuration. A new project created with vp create enables them by default. In an existing project, I verify that setting instead of assuming a green result also means the types are sound.

Here's the difference from my old workflow:

Shell

1# Before: it depended on each project's scripts. 2npm run format:check 3npm run lint 4npm run typecheck 5 6# Now, in a project with the corresponding Vite+ configuration. 7vp check

vp check --fix can repair some findings automatically. After that, I read the diff and run the check again. A green lint result still doesn't tell me whether the app does the right thing. I need vp test for behavior and vp build to verify the application builds.

I also put that rule in the repo's agent instructions. When I return to a project a week later, a new agent won't remember yesterday's chat. The repo still knows its commands.

Markdown

1## Checks before completing a task 2 3- After changing code, run `vp check` and fix any errors. 4- After changing behavior, run the relevant tests with `vp test`. 5- Before handing off a Vite app, run `vp build`. 6- Review the diff after automatic fixes. 7- Report the actual results; don't call a failed run complete.

Local instructions and Git hooks help, but they can be bypassed or disabled. I run the same checks in CI. On an experiment where I let an agent work unattended, human review before merging was still my responsibility.

What I measured

In a monorepo, CI went from 4 minutes to 50 seconds after I changed the workflow. A pre-commit check dropped from 11 seconds to under 2. Those are results from my projects, not a benchmark comparing Vite+ with another toolchain under identical conditions. Part of the gain comes from what runs and which files it checks; you won't automatically get those CI times with a different configuration.

GitHub Actions: the classic toolchain benchmark took 10.441 s.

GitHub Actions: the Vite+ benchmark took 1.356 s.

For quick checks of changed files, I use vp staged and Git hooks managed with vp hooks. When different projects behave differently, vp toolchain shows me their active versions. vp toolchain --global shows the global installation. That's more useful for debugging than my old method: “I definitely updated it.”

Checking the staged file with vp staged.

vp toolchain shows the active tool versions in the project.

There are two things to distinguish in a monorepo. vp run executes a package.json script or a task defined in vite.config.ts, and it can order work according to workspace dependencies. Caching is not enabled automatically for package.json scripts. You can enable it with, for example, vp run --cache build. Tasks defined in vite.config.ts are cached by default. I won't turn my CI timing into a promise that vp run alone makes every build faster.

Where it got awkward

vp migrate ran on an older monorepo for about 4 minutes. It converted my ESLint, Prettier, and original tsup build setup, and nothing broke in my case. That doesn't mean every migration takes four minutes. You have to compare the result with the old lint, tests, hooks, and build output. Plugins and custom rules may still need manual work.

Another trap is the difference between a built-in command and a project script. vp build runs a Vite app build. vp run build runs the build script from package.json or a task with that name. In a Next.js project, the agent must not assume vp build replaces next build. The same distinction applies to vp dev and vp run dev. Vite+ can work with other templates, but that doesn't change what those commands do.

The third issue is version management. The global vp env can manage Node.js and package managers. I have three projects on three Node versions, and it made switching easier for me; if you don't want that, you can turn it off with vp env off. vp upgrade updates the global CLI, not the local vite-plus package in every project automatically. I wrote that explicitly in my agent instructions because the command name invites the opposite assumption.

Who gets Vite+ in my first prompt

Anyone starting a new Vite app with AI doing the setup. The cost of standardizing is small here: choose one toolchain, put the check commands in the repo and CI, and the agent has a clear path from a code change to verification. Across three weeks and four projects, the main benefit for me was that I stopped explaining the basic commands over and over.

I wouldn't blindly migrate a large existing app with a working build and test suite. For a framework with its own build, I'd first decide which parts of Vite+ I actually want to use. And if I already had a well documented, fast, stable stack, the promise of “one command” alone wouldn't convince me to replace it.

Next time you start a Vite project, put vp create in the first prompt and ask for the outputs of vp check, tests, and the build as part of the definition of done. A screenshot of the finished app is nice. Passing checks tell you more.