putio-frontend-packages
Frontend Packages
Shape package repos around one boring delivery rule: every merge to main should already be releasable.
Workflow
- Inspect the repo's package type, publish target, scripts, workflows, versioning, and branch model.
- Read references/delivery-model.md.
- If the repo is TypeScript, read references/typescript.md.
- For other ecosystems, keep the same verify/release shape and choose the smallest repo-native tooling that fits.
- Prefer one repo-local
verifyentrypoint that CI calls directly.
Guardrails
- Keep
VERIFYas the source of truth for all guardrails. - Run
RELEASEonly onmain, and only afterVERIFYpasses. - Prefer GitHub Actions for release orchestration; avoid adding release-only package dependencies or scripts unless an existing repo or team standard requires them.
- Do not duplicate complex shell logic in workflow YAML when the repo can expose a local command.
- Do not invent ecosystem-specific release tooling without a real repo or team standard behind it.
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-viteplus
Migrate or align frontend repositories to the stock VitePlus workflow. Use when standardizing package or monorepo repos around `vp`, `voidzero-dev/setup-vp`, `vite-plus/test`, and VitePlus-native CI, test, and packaging flows.
7putio-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