Menu
Run all validation checks before tagging a new release
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when writing tests for peek-stash-browser. Covers Vitest + React Testing Library (client) and Vitest + integration testing (server). Follow these conventions exactly.
Use when starting a new coding session, beginning work on a branch, or resuming after a context reset. Gathers branch context, in-progress work, plan documents, and recent history to produce a briefing before any code is written.
Perform a code quality review before creating a PR. Use when reviewing changes, checking code quality, or doing a self-review of the current branch. Invoked as part of the work-ticket lifecycle after verification-before-completion and before finishing-a-development-branch.
Use when preparing or executing a release of peek-stash-browser. Covers the full release lifecycle from validation through Docker image publishing.
Express 5 patterns for peek-stash-browser — TypeScript backend serving a React SPA with HLS video proxying, multi-instance Stash server routing, JWT auth via HTTP-only cookies, and SQLite via Prisma. Use when writing or modifying Express route handlers, middleware, proxy controllers, or streaming endpoints in the peek project.
Expert guidance for Prisma ORM with SQLite databases. Use when designing schemas, writing migrations, optimizing queries, working with FTS5 full-text search, or troubleshooting SQLite-specific issues in Node.js/TypeScript applications.
| name | pre-release |
| description | Run all validation checks before tagging a new release |
Run this before tagging a new version to ensure everything works.
Do this first, before any local checks.
# Must be on main
git branch --show-current # expect: main
# Check the latest CI run on main
gh run list --branch main --limit 1 --json conclusion,displayTitle,databaseId
Expected: conclusion: "success". If CI is failing or in-progress, stop and resolve before continuing. All branches should already be merged to main before starting the pre-release process.
Nuke the shared dist to simulate CI's clean checkout. This catches missing build steps.
rm -rf shared/dist shared/tsconfig.tsbuildinfo
cd shared && npm run build
Expected: Build succeeds and shared/dist/ is populated.
Run steps 2a-2e in parallel where possible (server and client checks are independent).
cd server && npm test
Expected: All tests pass
cd server && npm run lint
cd server && npx tsc --noEmit
Expected: No errors (warnings OK)
cd client && npm test
Expected: All tests pass
cd client && npm run lint
Expected: No errors (warnings OK)
cd server && npm run test:integration
Expected: All tests pass Note: Requires testEntities.ts to be configured
cd client && npm run build
Expected: Build succeeds without errors
docker build -f Dockerfile.production -t peek:test .
Expected: Image builds successfully
When a check fails, invoke the relevant skill for guidance before attempting fixes:
| Failure | Skill to invoke |
|---|---|
| Test failures (writing/fixing tests) | writing-tests |
| TypeScript type errors | typescript-advanced-types |
| Prisma/migration issues | prisma-sqlite-expert |
| Docker build failures | docker-best-practices |
| React/client lint or build errors | vercel-react-best-practices |
| Server lint or runtime errors | nodejs-backend-patterns |
Report summary:
Ready to proceed with release tagging.