viteplus
VitePlus
Move a frontend repo closer to the stock VitePlus toolchain without blindly deleting repo-specific release or runtime logic. VitePlus is in alpha — verify behavior against installed vp --version and the latest release notes rather than memorized command shapes.
Migration Targets
Default to this destination unless a repo-specific boundary clearly blocks it. If you keep an old command shape, document the reason.
- CI uses
voidzero-dev/setup-vp@v1; the action owns Node and package-manager bootstrap, then runsvp install,vp check,vp test,vp build - test files use
vite-plus/test(andvite-plus/test/browser/contextfor browser mode) - scripts prefer
vp test,vp test watch,vp test run --coverage,vp pack,vp build,vp update, andvp run <script>(orvpr <script>) over direct package-manager, raw Vitest, or tsdown wiring - hooks use
vp config,.vite-hooks, andvp stagedinstead of custom Husky orlint-staged - single-source config in
vite.config.ts: no parallelvitest.config.ts,.oxlintrc*,.oxfmtrc*, ortsdown.config.ts - contributor docs move to the new
vpcommands in the same change
Workflow
- Confirm the project is on Vite 8+ and Vitest 4.1+ — VitePlus refuses older versions.
- Audit current scripts, workflows, Vite config, test imports, release flow, package manager, and packaging.
- Read references/bootstrap.md for entrypoints (
vp create,vp migrate), local guidance-file discovery, and validation path. - Pick the shape and load only that reference: references/packages.md for standalone packages, or references/monorepos.md for workspaces.
- Migrate scripts,
vite.config.ts, test imports, hooks, and packaging together. Verify withvp check && vp testbefore moving on. - Update CI per references/ci-cd.md.
- Update tests and coverage per references/testing.md.
- Check references/commands.md before changing command invocations. Load references/known-issues.md only on unexpected behavior or when upgrading VitePlus.
- Keep repo-specific release, binary, or packaging steps Vite+ does not replace.
- To adopt a newer Vite+ release:
vp upgrade(global), thenvp update vite-plus @voidzero-dev/vite-plus-core @voidzero-dev/vite-plus-test(project). Confirm withvp outdated. - End-to-end validation:
vp env current && vp install && vp check && vp test, then verifyvp buildartifacts,vp test run --coverage, andvp stagedon a staged change.
Concrete examples:
- uses: voidzero-dev/setup-vp@v1
with:
node-version-file: ".node-version"
cache: true
- run: vp install
- run: vp check
- run: vp test
- run: vp build
import { defineConfig } from 'vite-plus'
export default defineConfig({
lint: {
options: { typeAware: true, typeCheck: true },
},
staged: {
"*.{js,ts,tsx,vue,svelte}": "vp check --fix",
},
})
# package.json scripts
-"test": "vitest run --coverage",
-"test:watch": "vitest",
+"test": "vp test run --coverage",
+"test:watch": "vp test watch",
Guardrails
- Prefer
vp create/vp migrate --agent <name> --editor <name>over hand-rolling agent or editor config. - Do not delete release workflows, binary packaging, or publish steps just to look more "stock."
- If
vp checkis not running type-aware lint or type checks, confirmlint.options.typeAwareandlint.options.typeCheckinvite.config.ts, and check forcompilerOptions.baseUrlintsconfig.json—tsgolintdoes not supportbaseUrland VitePlus silently skips type-aware checks when it is present.
Known Caveats
See references/known-issues.md for current upstream caveats (hook runners, single-file vp check --fix, SSR instanceof failures, Cloudflare Workers tests, @vitest/coverage-v8 mixed-version warnings).
More from uinaf/skills
verify
Self-check your own completed change before handing off to `review` — the pre-review sanity pass. Use when you want to verify your change, test it end-to-end, run the repo's guardrails (lint, typecheck, tests, build), exercise the real surface with evidence, and catch obvious self-correctable issues you can fix in seconds. Produces a `ready for review` / `needs more work` / `blocked` verdict — never a ship decision (that's `review`'s job). If the repo cannot be booted or exercised reliably, hand off to `agent-readiness`. If you are auditing someone else's diff, branch, or PR, use `review` instead.
37effect-ts
Implement, debug, refactor, migrate, review, or explain Effect TypeScript code. Use when a task touches `effect` or `@effect/*` APIs, especially services, layers, schemas, runtime wiring, platform or CLI packages, Effect testing, or Promise-to-Effect migration.
37docs
Update repo documentation and agent-facing guidance such as AGENTS.md, README.md, docs/, specs, plans, and runbooks. Use when code, skill, or infrastructure changes risk doc drift or when documentation needs cleanup or restructuring. Do not use for code review, runtime verification, or `agent-readiness` setup.
36review
Independently audit existing code, diffs, branches, or pull requests using concern-specific reviewer personas and evidence. Use when triaging risk in a PR, deciding whether a change is safe to ship, or following up on a `verify` pass to make the call the builder cannot make on their own work. Produces a `ship it` / `needs review` / `blocked` verdict. Do not use to self-check a change you just authored; use `verify` for that.
23agent-readiness
Audit and build the infrastructure a repo needs so agents can work autonomously — boot scripts, smoke tests, CI/CD gates, dev environment setup, observability, and isolation. Use when a repo can't boot, tests are broken or missing, there's no dev environment, agents can't verify their work, or agents need human help to get anything done. Do not use for reviewing an existing diff or for documentation-only cleanup.
21skill-audit
Audit existing skills with Tessl scoring, metadata and trigger-coverage checks, repo conventions, and skill-authoring best practices. Use when creating or revising a skill, triaging weak self-activation, or comparing a skill against source-repo guidance such as `AGENTS.md`, `CLAUDE.md`, or repo rules, plus external skill guidance. Do not use to verify general application code or to rewrite unrelated docs.
19