putio-frontend-repos
Frontend Repos
Use one delivery rule: every merge to main should already be publishable or deployable.
Bundled references: delivery-model.md, typescript.md, applications.md, and env-setup.md.
This skill owns repo shape and canonical commands, not host-specific deployment architecture.
Workflow
- Run the inspection commands below and capture the summary before editing.
- Read references/delivery-model.md.
- If the repo is TypeScript, read references/typescript.md.
- If the repo is an application, read references/applications.md.
- If the repo uses 1Password-backed local, live-test, build, signing, or deploy workflows, read references/env-setup.md and standardize the local env shape.
- Prefer one repo-local
verifyentrypoint that CI calls directly. - Run the repo-local
verifycommand locally before changing delivery automation. If it fails, fix that command first and rerun it until it passes. - Configure semantic-release plugins and commit identity per the delivery-model reference when release commits are in scope.
- Verify the publish or deploy path only after the repo-local
verifycommand is stable and reproducible. - After publish or deploy changes, run the repo-documented artifact or app smoke check. If none exists, record that as a repo gap.
Summary shape:
- Repo kind:
- Verify entrypoint:
- Delivery target:
- Versioning/release:
- 1Password/env needs:
- Template gaps:
Useful inspection commands:
rg -n '"verify"|"release"|"build"|semantic-release|deploy|publish|OP_SERVICE_ACCOUNT_TOKEN|PUTIO_1PASSWORD|op://' \
package.json Makefile .github README.md CONTRIBUTING.md SECURITY.md docs .env.example scripts tooling apps 2>/dev/null
test -f package.json && jq '.scripts // {}' package.json
test -f Makefile && rg -n '^[a-zA-Z0-9_.:-]+:' Makefile
test -d .github && find .github -maxdepth 3 -type f | sort
Concrete example:
{
"scripts": {
"verify": "pnpm lint && pnpm test && pnpm build"
}
}
- name: Verify
run: pnpm verify
- name: Release
if: github.ref == 'refs/heads/main'
run: pnpm release
App-shaped example:
- name: Verify
run: make verify
- name: Deploy Beta
if: github.ref == 'refs/heads/main'
run: make deploy-beta
Guardrails
- Keep the repo-local
verifycommand as the source of truth for guardrails. - Prefer GitHub Actions for orchestration and repo-local commands as the canonical home for build, test, and deliver logic.
- Do not invent release tooling without a real repo or team standard behind it.
- GitHub-facing repos should carry a useful pull request template and issue templates when the review or triage flow benefits from them.
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.
19putio-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-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.
9putio-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`).
3