putio-frontend-patterns
put.io Frontend Patterns
Use this skill when writing or reviewing UI/frontend code in a put.io frontend repository, or when seeding the repo's .patterns/ folder.
Bundled references: frontend-defaults.md and pattern-template.md.
Use this skill for put.io-wide code defaults and .patterns/ for repo-specific choices such as schema, state-machine, styling, and testing libraries.
Quick Rules
- Type/schema-driven: schemas at the boundary are the source of truth. Types follow from schemas, not the other way around.
- Parse at the boundary: turn unknown input into typed values at the boundary. Pass typed values inward so raw
unknown, untyped JSON, and "validated but still loosely typed" data stay out of the render tree. - Make impossible states impossible: discriminated unions, sealed shapes, exhaustive matches. No sentinel
nulls orisLoading + data + errorboolean salads. - State machines for bug-sensitive flows: auth, payment, video conversion, video playback, upload, transfer lifecycle — model them as explicit state machines, not ad-hoc
useStatecascades. - Localize expected errors, bound unexpected errors: feature code maps known failures to actionable localized messages; route or feature boundaries catch unknown crashes without blanking the whole app.
- Effects at leaves: data fetching, navigation, storage, telemetry happen in adapters and leaves. Render trees stay pure and easy to test.
- No type escape hatches: no
as, no non-null!, no@ts-expect-errorwithout a written reason. If you need one, the model is wrong — fix the model. - Repo overrides skill:
.patterns/<topic>.mdin the repo wins over this skill's defaults. The skill is the fallback when the repo is silent.
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-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.
7