メニュー
Creates a GitHub PR with a Linear-ticket-prefixed title and a decision-led, narrative description for prisma-next. Use when the user wants to create a pull request, open a PR, or submit changes for review.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | create-pr |
| description | Creates a GitHub PR with a Linear-ticket-prefixed title and a decision-led, narrative description for prisma-next. Use when the user wants to create a pull request, open a PR, or submit changes for review. |
Detect the PR's base branch instead of hardcoding main. Set BASE_BRANCH once and reuse it in every diff/log command:
BASE_BRANCH=$(git rev-parse --abbrev-ref origin/HEAD 2>/dev/null | sed 's@^origin/@@')
BASE_BRANCH=${BASE_BRANCH:-main}
git rev-parse --abbrev-ref origin/HEAD returns the remote's default branch (e.g. origin/main); the sed strips the origin/ prefix. The fallback to main covers repos where origin/HEAD is unset. If you know the PR was branched off a non-default branch, override BASE_BRANCH explicitly before running the commands below.
git log "$BASE_BRANCH..HEAD" --oneline to see all commits on the current branch (fallback: git log "origin/$BASE_BRANCH..HEAD" --oneline).git diff "$BASE_BRANCH...HEAD" --stat to see which files changed (fallback: git diff "origin/$BASE_BRANCH...HEAD" --stat).git diff "$BASE_BRANCH...HEAD" to read the full diff (fallback: git diff "origin/$BASE_BRANCH...HEAD").git status -sbgh pr create can proceed but those changes will not be in the PR.Resolve the Linear ticket from context — do not ask the user. The ticket is almost always derivable from one of:
tml-NNNN-… (lower-case form of the Linear identifier). The current ticket is whatever matches (?i)\b(TML-\d+)\b in git rev-parse --abbrev-ref HEAD. Use the trailing slug from the branch name verbatim as $SLUG.Refs: TML-NNNN or (TML-NNNN) trailer / mention in git log "$BASE_BRANCH..HEAD".Extract:
$TICKET_ID — the canonical upper-case identifier (e.g., TML-1859)$SLUG — the trailing slug used in Linear URLs (e.g., pn-add-more-parameterized-types); take it directly from the branch name's trailing portion when availableOnly ask the user if all three sources fail to yield an identifier. In that case, ask once with a concrete proposal (e.g. "I couldn't infer a Linear ticket from the branch xyz or the recent commits — which ticket does this PR close?").
Format:
$TICKET_ID: <concise title in sentence case>
Rules:
: then a single space.TML-2375: expand pgvector type and operator surface (abstract)TML-2375: 5 new pgvector operator descriptors + HNSW index support (concrete)Examples:
TML-1859: add text codec support to sql-runtimeTML-2104: handle null in jsonb columns (postgres adapter)TML-2375: 5 new pgvector operator descriptors + HNSW index supportTML-2456: split contract emission into two phasesThe PR description must follow a decision-led, narrative structure. A teammate without prior context on the work should be able to read it top-to-bottom and understand what we decided, why, and how it fits together — without being overwhelmed by file lists or alternatives we ultimately rejected.
Read .github/PULL_REQUEST_TEMPLATE.md once before drafting. The template's required headers (in prisma-next today: ## Linked issue, ## Testing performed, ## Checklist) must appear in the final body even when the skill's recommended structure below doesn't list them. Where the template and the skill overlap, use the template's richer header (e.g. ## Linked issue — with a Refs: link and any prerequisite-PR / follow-up-PR context — replaces the bare close-line at the top).
## Linked issue — the template header, used instead of a bare close-line. Single Refs [$TICKET_ID](https://linear.app/...) link plus, if relevant, links to any prerequisite or follow-up PRs and the Linear tickets they close. Keep it short — three lines max.
## At a glance — a copy-pasteable code sample from real code in the branch (not invented, not pseudocode) that demonstrates the change in user-observable terms. Below the code, one short sentence that grounds the "before" state if relevant.
## Decision (or ## The decision) — lead with what we decided. State the deliverable in one paragraph or a short numbered list. If the PR carries more than one substantive piece (e.g. a feature + an enabling framework change), enumerate them so the reader can't miss any. Link to ADRs inline at the points they matter.
## How it fits together — the narrative, built bit by bit. 3–6 numbered steps that walk the reader from substrate to delivery. Each step should have a clear job (e.g. "lift the substrate", "add the codecs", "widen the operator surface", "prove against live infra"). Inline ADR links where relevant.
## How X works subsections instead of one ## How it fits together. One subsection per flow, in the order a reader would learn the system.## Behavior changes & evidence — one bullet per observable change. Each bullet:
## What lands in this PR and a short commit-by-commit table (commit subject + one-line "what it adds"). Mention the AC count + link to the spec for the scoreboard; do not paste raw AC-IDs.## Reviewer notes (the gotchas) — strongly recommended. The 3–6 things you most expect a careful reviewer to push back on, surfaced proactively. Things that belong here:
Place this near the top of the long-form sections — it's the most useful section to a skimming reviewer, so don't bury it after every other section.
## Compatibility / migration / risk — SPI / API / behavioral compatibility notes. For small PRs, fold this into ## Reviewer notes instead of carrying it as its own section.
## Verification (or ## Testing performed per the template) — list the suites you ran on the final HEAD, one per line, with the count of cases / tasks where useful. Note any flakes that reproduced and were ruled pre-existing.
## Follow-ups — Linear tickets or doc notes for deferred work. Skip if there are none; don't pad.
## Alternatives considered — final section. Each bullet names an alternative we genuinely weighed and why we didn't take it. Pull alternatives forward from any ADRs or design discussions so the reader doesn't have to click through. Frame as alternatives (decisions we made), not as "non-goals" (scope statements).
## Checklist — the template's checklist, with each item marked [x] only if true. Common items: DCO sign-off, CONTRIBUTING.md read, tests updated, title in the prevailing convention.
## At a glance and its concrete code sample. No "Intent" paragraph in between.## Decision so a reader can't skim past it..agents/skills/drive-pr-walkthrough/SKILL.md workflow for the current branch vs base (default: origin/main...HEAD) and write walkthrough.md to disk. The walkthrough provides raw material — narrative steps, behavior changes, evidence links — but its default section order is not the PR shape. You will restructure it.wip/pr-<num>-body.md) following the Required structure above. Reuse the walkthrough's narrative, behavior bullets, and evidence links where they fit; restructure to lead with the code sample and the decision, and to end with alternatives.path/to/file.ts); strip local-editor suffixes like :12-34.Before pushing, do a fresh-eyes pass on the draft body. Imagine you're a teammate without context on the design discussion. The skill's "decision-led, narrative" structure is a target shape; this step is the gate that catches cases where the first draft missed it.
For each check, if it fails, rewrite the draft before pushing — don't ship and rely on review feedback to catch it.
## Linked issue? If a fresh reader would have to read 3+ paragraphs of decision-prose before seeing a real example, the grounding is missing.## Decision? If the deliverables are diffused across bullets and a reader can't pin down "what's being shipped" on first scan, the lead is buried.## Alternatives considered.## Reviewer notes placed before the long-form sections (e.g. ## What lands in this PR, ## Verification)? It's the most useful section to a skimming reviewer.AC22, AC23, AC28) or FR-IDs (FR21), or "the spec calls out" presuppose the reader has read the spec. Either rephrase ("we built X because Y") or summarise as a count + link to the spec.## What lands in this PR commit table is fine, but don't also paste a "Change map" listing every file. Pick one summary surface; let the diff carry the rest.Open the PR directly — do not ask the user to confirm the title or body first. The skill's quality bar is the structure, the forbidden-patterns checklist, and the fresh-eyes pass; running through those in your own head is the gate, not a confirmation prompt. (If the user wants changes after the fact, they will tell you and you can edit the PR via gh pr edit.)
DCO sign-off check. Before pushing, verify every commit has a Signed-off-by: trailer — the prisma-next PR template's checklist requires it and the DCO status check will block merge:
git log "$BASE_BRANCH..HEAD" --format='%h %s%n %(trailers:key=Signed-off-by,valueonly)'
If any commit shows an empty Signed-off-by line, retroactively sign every commit:
git rebase --signoff "$BASE_BRANCH"
This rewrites SHAs, which is safe pre-push. After the rebase, push as normal.
Ensure the branch is pushed to remote (git push -u origin HEAD if needed).
Create the PR using the body file:
gh pr create --title "$TICKET_ID: <title>" --body-file wip/pr-<num>-body.md
(Use --body-file rather than a heredoc to avoid quoting/escaping pitfalls with backticks and code samples. Stage the body file under wip/ — gitignored — so the live PR matches what the user reviewed.)
Return the PR URL to the user.
## Linked issue, the body must move straight into ## At a glance and its real code sample.## Decision.## Alternatives considered, framed as decisions you weighed.type(scope): title format — that's the old format. The current format is $TICKET_ID: <title>.AC-NN / FR-NN IDs, "the spec calls out", "as the spec promises", and similar phrasings — a fresh reader doesn't have the spec to hand. Either rephrase to plain language or link to the spec the first time the term appears.## Alternatives considered. "We did X to avoid Y" rationale is alternatives content; it adds cognitive load when it appears before the reader has seen what we built.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.
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.
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.
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(...)`).
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.
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.