Run any Skill in Manus with one click

publish-npm-version

Stars415

Forks14

UpdatedJune 2, 2026 at 07:40

Cuts the next minor release of Prisma Next: bumps the root package.json version, propagates it to every workspace package, and opens a PR titled "chore(release): bump to <next-version>". When the maintainer merges the PR, the `Publish to npm` workflow runs automatically and ships the new version to npm under dist-tag `latest`, plus a matching GitHub Release. Use when a maintainer asks to "cut the next minor", "bump to the next version", "open a release PR", or "prepare a publish PR".

Installation

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.

Run Skill in Manus

Source

prisma

prisma/prisma-next

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

prisma-next-extension-upgrade

prisma/prisma-next

Upgrade Prisma Next in your extension. Bumps every `@prisma-next/*` dependency to the requested target (or npm `latest`), runs the per-transition upgrade instructions for the extension SPI (middleware lifecycle, codec / migration-tools / framework-components churn, seed-migration on-disk shape), verifies the pins are correctly exact via `prisma-next-check-pins`, runs the extension's own typecheck and tests, and commits each minor step on its own. Use when the user asks to "upgrade Prisma Next" in an extension package, or to update an extension's `@prisma-next/*` deps to a new minor.

2026-07-24415

prisma-next-upgrade

prisma/prisma-next

Upgrade Prisma Next in your app. Bumps every `@prisma-next/*` dependency from the version pinned in the lockfile to the requested target (or npm `latest`), applies any required code-translation steps from the per-transition upgrade instructions, validates with the project's own typecheck + tests, and commits each minor step on its own. Use when the user asks to "upgrade Prisma Next", "bump Prisma Next", "move to Prisma Next X.Y", or asks an agent to deal with an `@prisma-next/*` minor bump in their app.

2026-07-24415

prisma-next-supabase

prisma/prisma-next

Use Prisma Next with a Supabase project via `@prisma-next/extension-supabase` — wire `extensions: [supabasePack]`, declare cross-space FKs to `supabase:auth.AuthUser`, author RLS policies (`policy_select` / `policy_update` / `@@rls`, `auth.uid()` predicates), build `db.ts` with the `supabase()` factory, bind roles per request (`asUser(jwt)` / `asAnon()` / `asServiceRole()`), query `auth.*` / `storage.*` via the `db.asServiceRole().supabase` admin root, and validate JWTs (`jwksUrl` for current projects / `jwtSecret` for legacy HS256). Use for supabase, RLS, row level security, policy, role binding, anon, authenticated, service_role, auth.users, auth.uid(), JWT, JWKS, SUPABASE_JWKS_URL, SUPABASE_JWT_SECRET, SUPABASE.JWT_INVALID, SUPABASE.CONFIG_INVALID, RoleBoundDb, session pooler, supabase:auth.AuthUser, @prisma-next/extension-supabase.

2026-07-24415

prisma-next-queries

prisma/prisma-next

Write Prisma Next queries for Postgres, SQLite, or Mongo — pick a lane (Postgres/SQLite `db.orm.<Model>` + `db.sql.<table>`; Mongo `db.orm.<root>` + `db.query.from(...)` pipeline builder), filter / project / sort / paginate, eager-load with `.include(...)`, Postgres/SQLite `db.transaction(...)`, Postgres/SQLite ORM `.aggregate(...)`, Mongo aggregations via query builder, namespace-aware accessors (`db.orm.<ns>.<Model>`, `db.sql.<ns>.<table>`). Triggers: query, where, match, select, project, orderBy, take, skip, include, lookup, first, all, count, aggregate, group, create, update, delete, upsert, returning, transaction, db.close, script teardown, variant, polymorphism, drizzle-style, kysely-style. Notes: `.all()` is a Thenable (just `await` it), iterators are single-use (`RUNTIME.ITERATOR_CONSUMED`), Postgres `count` is `number` while sum/avg/min/max are `number | null`, ranges use chained `.where()` or `and(...)` (no `.between(...)`).

2026-07-24415

prisma-next-contract

prisma/prisma-next

Edit the Prisma Next data contract — add models, fields, relations, indexes, enums, value objects (composite types), type aliases, namespaces (Postgres schemas), cross-contract foreign keys (cross-space FK), polymorphic types (`@@discriminator` / `@@base`), use extension namespaces (`pgvector.Vector(...)`, `cipherstash.EncryptedString(...)`), wire `prisma-next.config.ts` with `defineConfig` from the `@prisma-next/<target>/config` façade, and run `prisma-next contract emit`. Use for schema, models, fields, attributes, soft delete, paranoid, scopes, validations, callbacks, prisma schema, PSL, contract.prisma, contract.ts, contract.json, contract.d.ts, `@prisma-next/postgres/config`, `@prisma-next/postgres/contract-builder`, `@prisma-next/postgres/control`, `@prisma-next/mongo/config`, `@prisma-next/mongo/contract-builder`, `extensions:`, pgvector, cipherstash, postgis, paradedb, supabase, `@prisma-next/extension-supabase`, `@@control`, control policy, managed, tolerated, external, observed.

2026-07-23415

prisma-next-debug

prisma/prisma-next

Read a Prisma Next structured error envelope and route to the right recovery — code, domain, severity, why, fix, meta. Use for error, exception, my emit failed, my query won't typecheck, my query crashed, my migration won't apply, MIGRATION.HASH_MISMATCH, BUDGET.ROWS_EXCEEDED, BUDGET.TIME_EXCEEDED, RUNTIME.ABORTED, PLAN.HASH_MISMATCH, CONTRACT.MARKER_MISSING, PN-RUN-3001, PN-RUN-3002, PN-RUN-3030, PN-MIG-2001, PN-CLI-4011, PN-SCHEMA-0001, drift, capability missing, planner conflict, prisma studio, EXPLAIN, query log, db.end, db.close, script won't exit, hangs, close connection, pool.end, client is closed.

2026-07-23415

name

publish-npm-version

description

Publish next npm version

Audience

Maintainers of Prisma Next who have permission to push branches and open PRs in the repository. The skill is invoked locally by the maintainer; it does not run as a GitHub Action. Running locally is what makes the resulting PR trigger CI normally — PRs opened by a workflow's GITHUB_TOKEN do not, which defeats the point of cutting a reviewable release.

Background reading

Read docs/oss/versioning.md before running this skill. It covers:

The source-of-truth model (root package.json version).
The lockstep guarantee (every workspace package matches the root).
The dist-tag convention (latest / dev / beta).
The full release procedure (this skill is step 2 of 3; merging the PR is the publish trigger — there is no separate dispatch step).
The emergency-patch path (this skill does not handle patches).

This SKILL.md covers only the mechanics of step 2 — opening the bump PR.

Pre-flight

The skill does not require the maintainer to be on main or to have a clean working tree — it does all the work in a fresh worktree off origin/main, so the maintainer's current worktree (typically a feature branch in worktrees/<feature>/) is left undisturbed.

Before invoking this skill, confirm:

The maintainer can fetch from origin (git fetch origin main succeeds).
You are ready to draft the release notes for this bump. The draft-release-notes skill (invoked in step 7 below) enumerates the merged PRs since the previous stable tag and surfaces the release-notes-worthy changes — including any breaking changes — so this no longer rests on the maintainer's unaided recollection. If you already know of an in-flight breaking change that must be called out, note it so the authoring step gives it prominence.

If either precondition is unmet, stop and surface the issue. Do not try to auto-resolve.

Procedure

Fetch and determine the target version. Run git fetch origin main, then read the current root version from origin/main and compute the next minor:

git fetch origin main
CURRENT=$(git show origin/main:package.json | node -e 'process.stdout.write(JSON.parse(require("fs").readFileSync(0,"utf8")).version)')
NEXT=$(node -e "const [a,b] = process.argv[1].split('.'); process.stdout.write(\`\${a}.\${Number(b)+1}.0\`)" "$CURRENT")
echo "$CURRENT → $NEXT"

(Patch component is reset to 0 by design — see docs/oss/versioning.md.)

Create a fresh worktree off origin/main. Use the convention release/<version> for both the branch and the sibling worktree path:
```
git worktree add -b "release/$NEXT" "../release-$NEXT" origin/main
cd "../release-$NEXT"
```
This is what makes the skill safe to invoke from any worktree: the bump happens against a fresh checkout of origin/main, not against the maintainer's current branch. The branch name encodes the target version so reviewers can tell at a glance what the PR ships.
Bump. From the new worktree, run pnpm bump-minor. The script reads the root package.json version from git show HEAD:package.json (in this worktree, HEAD is origin/main), computes the next minor, and writes it to every workspace package.json via scripts/set-version.ts.

Note: bump-minor requires node_modules to resolve its dependencies (e.g. pathe). If the fresh worktree has no node_modules, run pnpm install --frozen-lockfile --ignore-scripts first.
Refresh the lockfile. Workspace-internal dependencies in this repo are pinned as workspace:<version> (not workspace:*), so the bump changes their specifiers in pnpm-lock.yaml. Run:
```
pnpm install --lockfile-only
```
to update pnpm-lock.yaml in lockstep. Without this step, CI fails with ERR_PNPM_OUTDATED_LOCKFILE on the release PR.
Sanity-check the diff. Confirm:
- Every modified file is either a package.json or pnpm-lock.yaml.
- The package.json diffs are exactly version field changes plus internal workspace:<old> → workspace:<new> specifier bumps (no other fields).
- The pnpm-lock.yaml diff is exactly specifier: workspace:<old> → workspace:<new> lines (no resolution churn for external packages).
Commit. Stage package.json files and pnpm-lock.yaml together in a single commit:
```
chore(release): bump to <version>
```
No body is required — the PR description will explain the bump in detail.
Draft the release notes. From inside this release/<version> worktree, run the draft-release-notes skill for <version>. It enumerates the merged PRs since the previous stable v* tag, triages which are user-facing, categorizes them (breaking changes first), writes docs/releases/v<version>.md, and prepends a matching CHANGELOG.md entry — committing both on the release branch as their own commit. Committing the notes here is what lands them in the bump PR diff, so the PR-mode check:release-notes gate passes and the maintainer reviews the notes as part of the release PR.
Push the branch to origin.
Open the PR with gh pr create. Use the title:
```
Bump to version <version>
```
The body should:
- State the previous and new version (<previous> → <new>).
- Link to docs/oss/versioning.md for context.
- Point reviewers at the committed docs/releases/v<version>.md (authored by the draft-release-notes skill in step 7) as the human-review surface for the release's user-facing changes.
- Note that merging this PR ships the release: the resulting push to main carries the bumped root version, the Publish to npm workflow detects the change and publishes <new> under dist-tag latest, and a matching GitHub Release is created automatically.
Stop and report the PR URL and the worktree path to the maintainer. The maintainer can git worktree remove ../release-<version> after the PR merges. Do not merge the PR yourself; the merge is a human gate where someone confirms the release notes are acceptable. (Merging triggers the publish — there is no separate dispatch step.)

Idempotency

pnpm bump-minor is idempotent because it reads the root version from git show HEAD:package.json rather than from the working tree. A maintainer who runs the skill twice without committing in between still ends up with the same target version, not a double-bump. If you find yourself in that situation (working tree dirty with a previous bump), reset and re-run; do not stack bumps.

Out of scope

Merging the PR. The skill stops at "PR opened" so a human can confirm the release notes. Merging is what triggers the actual publish, but it remains a human gate by design.
Patch releases. Patches use a different bump shape (patch+1 from a release tag); the manual procedure in docs/oss/versioning.md applies.
Pre-release / beta tags. The beta dist-tag is hand-cut via a manual workflow_dispatch of Publish to npm; this skill always advances to a stable minor.