putio-frontend-viteplus
Frontend VitePlus
Use this skill to move a frontend repo closer to the stock VitePlus toolchain without blindly deleting repo-specific release or runtime logic.
Workflow
- Inspect the repo's current scripts, workflows, Vite config, test imports, release flow, and package manager.
- Read references/bootstrap.md when creating a new repo or running
vp migrate. - Read references/packages.md for standalone package repos.
- Read references/monorepos.md for workspace repos.
- Read references/ci-cd.md before changing GitHub Actions or release automation.
- Read references/testing.md before migrating test imports, coverage, or test commands.
- For Git hooks, prefer the stock
vp configplusstagedblock flow documented by VitePlus instead of hand-rolled hook scaffolding. - Keep repo-specific binary, release, or packaging steps only where VitePlus does not replace them cleanly.
- Prefer one coherent migration: scripts, workflows, and test surface should move together.
- Verify with repo-native guardrails, then prove the important runtime surface still works.
Guardrails
More from putdotio/skills
putio-frontend-docs
Structure and rewrite docs for frontend repositories, especially README.md, CONTRIBUTING.md, SECURITY.md, and other top-level docs. Use when creating or reorganizing frontend repo docs, clarifying user vs contributor guidance, reducing doc sprawl, or fixing stale commands, paths, and links in top-level docs.
21putio-frontend-repos
Structure put.io frontend-owned repositories around repo-local verify and delivery contracts. Use when standardizing package repos, app repos, or SDK repos across TypeScript, Swift, Kotlin, or similar ecosystems; defining the verify command CI should call; aligning publish/deploy flows on main after verify passes; or fixing repo shape that blocks repeatable release or deployment work. Skip generic CI/CD design that does not depend on repo structure.
13putio-sdk-dev
Develop or review put.io SDK repositories, API clients, and client libraries across TypeScript, Swift, Kotlin, and similar packages. Use when adding or changing namespaces, tightening request or error types, aligning SDK behavior with backend and app usage, updating SDK verification flows, or checking how an SDK repo should be documented and released.
11putio-frontend-packages
Structure package repositories around a shared verify and release model. Use when creating or standardizing library/package repos across TypeScript, Swift, Kotlin, or similar ecosystems, setting up CI guardrails, defining a repo-local verify command, or enabling automatic releases on main.
11putio-frontend-patterns
Apply put.io frontend code patterns and seed repo-local `.patterns/` conventions. Use when writing or reviewing UI/frontend code in a put.io frontend repo, picking the default approach for types, data parsing, state machines, error handling, components, or testing, or seeding/extending the repo's `.patterns/` folder. Skip for delivery and CI shape (use `putio-frontend-repos`), top-level docs (use `putio-frontend-docs`), or SDK packages (use `putio-sdk-dev`).
5