npx skills add ...
npx skills add prisma/prisma-next --skill contrib-pr
npx skills add prisma/prisma-next --skill contrib-pr
Open a high-quality external contributor PR against prisma-next. Use when the user is an outside contributor (not a Prisma maintainer) and wants to submit a change as a pull request from a fork. Encodes the contribution flow from CONTRIBUTING.md so the resulting PR passes review on the first round.
This skill is for external contributors to prisma/prisma-next who are using an LLM-based agent to author or finalize a PR. It is intentionally separate from the maintainer-facing create-pr skill: it does not depend on Linear access, internal plan/spec documents, or any private context. It encodes the expectations laid out in CONTRIBUTING.md as a runnable workflow, so the PR you produce matches the shape maintainers expect on the first review round.
If the user is a maintainer with access to internal Linear tickets, use create-pr instead.
Trigger this skill when the user says any of:
If the user has clearly already followed the contribution flow and just needs the gh pr create invocation, you may skip directly to step 5.
Verify the result, not the authorship. The maintainers do not ask whether the change was AI-assisted; they verify that:
This skill is a pit of success — there is no CI gate that checks you used it. Following it is the cheapest way to land the PR cleanly.
Before doing anything else, read the project's contribution docs:
CONTRIBUTING.md. This is the source of truth for setup, the test command set, DCO signoff, and PR expectations.CODE_OF_CONDUCT.md so you understand what's expected in your interactions on the PR thread.SECURITY.md. If your change is fixing a security issue, stop and use the Private Vulnerability Reporting flow instead — do not open a public PR.If anything in CONTRIBUTING.md contradicts what this skill says, CONTRIBUTING.md wins.
Before opening the PR, check:
CONTRIBUTING.md. If not, recommend they do — maintainers will respond within 5 business days, and a half-day issue conversation can prevent a one-week PR rewrite when the design direction differs from what they expect.Run the suite that matches the scope of the change. From CONTRIBUTING.md:
| Change scope | Command |
|---|---|
| Type errors only | pnpm typecheck |
| Lint / formatting | pnpm lint |
Unit tests in packages/** | pnpm test:packages |
| Examples | pnpm test:examples |
| Postgres / SQLite e2e | pnpm test:e2e |
| Database integration | pnpm test:integration |
| Vite plugin / Cloudflare Worker | pnpm test:vite-plugin (needs Docker) |
| Everything | pnpm test:all |
The minimum bar before opening any PR is:
If any of these fail, fix the failure (or push back on the user about whether the change is actually right) before continuing. Do not open a PR with a known-failing test or lint error. It will be closed for that reason alone.
If the change touches the SQL runtime, also run pnpm test:integration and/or pnpm test:e2e. If you can't tell whether the change touches the SQL runtime, run them anyway — they're self-contained (PGlite + mongodb-memory-server, no external DB needed).
Every commit on the PR must have a Signed-off-by: trailer matching the commit author's name + email. Without this, the DCO status check blocks the PR from merging.
Check current commits:
For each commit, verify the body contains a Signed-off-by: line whose name + email match %an <%ae>.
If any commit is missing the trailer:
git commit --amend --signoff --no-editgit rebase --signoff origin/mainAfter amending or rebasing, force-push to the contributor's fork: git push --force-with-lease.
Conventional commit form, lowercase after the colon, no trailing period, under ~60 chars:
type is one of: feat, fix, chore, docs, refactor, test. Pick the one that best describes the change. scope is the primary affected package or layer (sql-runtime, postgres-adapter, contract, cli, framework, mongo-orm, etc.). If the change spans many packages, pick the one most central to the change.
Examples:
feat(sql-orm-client): support computed includesfix(postgres-adapter): handle null in jsonb columnsdocs(contributing): clarify pnpm install stepsThe PR title flows directly into the auto-generated GitHub Release notes when the version that contains it is published — pick a title a downstream user would understand.
Fill in the pull request template sections in order:
Fixes #N / Refs #N. If no issue exists because the change is small, write n/a — small change.pnpm test:* commands you ran. If you ran a manual repro (e.g. against the demo), say so.Do not include an "AI-authored" disclosure. Maintainers do not require it; it adds noise.
git push -u origin HEAD from the contributor's branch in the fork).The gh CLI must be authenticated against the contributor's GitHub account, not against prisma/prisma-next directly. The PR will open against prisma:main from the contributor's fork.
Return the PR URL.
Tell the user: a maintainer from @prisma/ORM-TS-Maintain will be auto-assigned via CODEOWNERS and is committed to a 5-business-day response window. If the change is large or controversial, expect a review thread before merge.
CONTRIBUTING.md rules. If they've changed since this skill was written, follow the file, not the skill.Signed-off-by: trailer. The DCO sign-off must be the contributor's own name and email matching the commit author.pnpm test:packages is red, fix it before pushing.SECURITY.md.