prisma-next-feedback

name

prisma-next-feedback

description

Hand a Prisma Next question or report off to the team — file a GitHub issue (bug or feature request), or route Q&A / design discussion / direct-team-contact to the Prisma Discord at pris.ly/discord. Use for bug, bug report, file an issue, report a bug, feature request, missing feature, this should be a feature, file this, this is a bug, this is broken, surprising behaviour, this doesn't work, file feedback, send feedback, capability gap, file via prisma-next-feedback, ask the team, talk to the team, talk to the Prisma team, talk to Prisma, Discord, Prisma Discord, Q&A, design feedback, is this the intended way, how should I do X, extension author question, extension author needs help.

Prisma Next — Feedback (Bug Reports, Feature Requests, Team Q&A)

Edit your data contract. Prisma handles the rest.

This skill is the terminal of the capability-gap routing pattern. Every other Prisma Next skill's What Prisma Next doesn't do yet entries route here when the user wants the gap closed; the skill also fires directly on prompts like "this is a bug", "file an issue", "feature request", "can I ask the team about this?", "how should I integrate X with Prisma Next?".

The skill's job is to pick the right channel — GitHub issue or Discord — and then either produce a structured, public-safe issue body (no secrets, no proprietary schema) the framework team can act on, or hand the user a direct link to the Prisma Discord for synchronous Q&A. Submission to GitHub never happens without explicit user confirmation.

Canonical channels:

• GitHub Issues (bugs + concrete feature requests): https://github.com/prisma/prisma-next/issues/new/choose
• Prisma Discord (Q&A, design feedback, direct team contact — including extension authors): https://pris.ly/discord

When to Use

• A capability-gap entry from another prisma-next-* skill fired and the user said "yes, file the feature request".
• User says "this is a bug", "file this", "report this", "file an issue against PN", "send feedback", "this should be a feature".
• User describes an unexpected behaviour — wrong exit code, error message that didn't match what happened, type signature that doesn't match runtime behaviour, planner refused a migration that looked safe — and wants it on the framework team's radar.
• User asks "can I ask the Prisma team about this?", "is there somewhere I can talk to the team?", "is this the intended way to do X?", "how should I integrate <my extension / my tool> with PN?", or any other open-ended Q&A or design-feedback prompt — including extension authors asking integration questions.

When Not to Use

• User wants to fix the bug themselves in the user's own code. The fix lives in another skill (debug / contract / migrations / queries / runtime / build). Chain to the right skill first; only fall back to feedback if the user explicitly wants the framework to do something differently.
• User wants to upgrade Prisma Next (the bug may already be fixed) → the prisma-next-upgrade skill (separately installed); this skill mentions it as a pre-flight check.
• The user's question is already covered by a workflow skill in the cluster ("how do I add a column?" → prisma-next-contract; "what's the right query interface?" → prisma-next-queries). Route to the workflow skill, not to the team — load the skill, answer the question, and only escalate to Discord if the agent can't.

Key Concepts

• Three channels, one decision. GitHub Issues (bugs + concrete feature requests), Prisma Discord (Q&A, design feedback, direct team contact), or another in-cluster skill (when the question turns out to be a workflow question, not a hand-off-to-team question). The skill's first move is the channel decision; everything else follows.
• Public artifact. GitHub issues and Discord messages are world-readable and archived. The body / message must not contain DATABASE_URL strings, internal company schema fragments, customer data in sample rows, or any other content the user wouldn't share publicly. The agent redacts before either kind of submission.
• Bug vs feature vs question. A bug is "documented surface behaved unexpectedly". A feature request is "I want a capability that doesn't exist". A question is "I want to discuss X with someone, or I'm not sure this is a bug at all". Many capability-gap routes are feature requests; many extension-author prompts are questions.
• The framework team needs to reproduce (issues only). A bug report without a reproduction is much harder to act on. Where possible, the agent produces a minimal repro the team can re-run locally — ideally a small change against examples/prisma-next-demo, which the team already has checked out. Discord Q&A doesn't require a full repro — a short code snippet plus the question is usually enough.

Workflow

1. Pick the channel

The user wants to hand something off to the team. Which channel?

GitHub Issue if any of:

• The user describes a concrete bug (see Classify below for the bug-vs-feature split).
• The user has a concrete feature request — a named capability, a specific API shape, a specific CLI flag — that they want on the backlog.
• A capability-gap entry from another prisma-next-* skill routed them here for a feature request.

Prisma Discord (https://pris.ly/discord) if any of:

• The user is asking an open-ended question — "is this the intended way to do X?", "how would you approach Y?", "I'm seeing weird behaviour but I'm not sure if it's a bug."
• The user wants design feedback before committing to a feature request — "we're thinking of building a custom middleware that does X, does this fit the framework's direction?"
• The user is an extension author with an integration question that needs back-and-forth with the team (peer-dependency coordination, breaking-change timing, a new extension surface).
• The user explicitly asks for the team — "can I ask the team about this?", "is there somewhere I can talk to Prisma?", "where do extension authors discuss things with the team?"

Both, in sequence, if any of:

• The user has a bug and a related feature request — file two separate GitHub issues, do not mix them in one issue.
• The user wants to discuss a design before filing the feature request — start in Discord, file the issue once the shape is settled.

2. Classify (issue path only)

The user is filing a GitHub issue. Is it a bug or a feature request?

Bug if any of:

• A documented CLI command exited with the wrong code.
• The fix field of an error envelope was misleading or wrong.
• A published TypeScript signature doesn't match runtime behaviour.
• The planner refused a migration that should have been valid (or accepted one that shouldn't have been).
• The contract emit produced an artifact that doesn't load at runtime.
• Any other case where the documented surface did the wrong thing.

Feature request if any of:

• The user wants a capability that doesn't exist yet (most of the What PN doesn't do yet entries land here).
• The user wants a better error message, an additional CLI flag, a new middleware, an additional bundler plugin, etc.

If both — a bug and the user wants a related feature — file two separate issues. Mixing them makes the framework team's triage harder.

3. Collect the minimum body (issue path only)

For either kind:

• Prisma Next version: pnpm ls @prisma-next/postgres (or @prisma-next/mongo). If the project uses a target package, that version is canonical.
• Node version: node -v.
• Package manager: pnpm / npm / yarn / bun / deno.
• OS: darwin / linux / win32 and the version string is enough.

For bug reports, additionally:

• The exact command that misbehaved (e.g. prisma-next migration plan --name add-email).
• The full output, with -v if a structured error envelope is involved. Redact DATABASE_URL and any other secrets.
• A minimal src/prisma/contract.prisma / src/prisma/contract.ts excerpt that reproduces the issue. Strip unrelated models. Keep the original model and field names from the user's contract when they don't expose anything compromising — a faithful excerpt is much easier for the framework team (and future readers of the issue) to reason about than a re-themed one. Only rename to neutral placeholders (User, Post, Tag) when the original names would leak confidential domain detail (product names, internal codenames, customer identifiers, regulated-data field names).
• Steps to reproduce, as a numbered list.
• Expected behaviour — one sentence.
• Actual behaviour — one sentence plus the relevant output line.
• Workaround, if any — one sentence.

For feature requests, additionally:

• Desired API or behaviour — one paragraph. Concrete shape (CLI flag, config field, middleware export, plugin API) where possible.
• Where the gap surfaces today — which skill's What PN doesn't do yet entry triggered the request, or the workflow the user was trying to complete.
• Current workaround, if any — one sentence (and the skill body the user is following may already say this).

4. Render the body

The repository ships GitHub Issue Forms (.github/ISSUE_TEMPLATE/bug_report.yml and feature_request.yml). When the user lands on https://github.com/prisma/prisma-next/issues/new/choose they pick the matching template and fill in the form fields; the skill produces the body in the same structured shape so it maps onto the form one-to-one (and so gh issue create --body-file produces a parseable artifact even when the form isn't in play).

Bug-report body shape (fields named to match .github/ISSUE_TEMPLATE/bug_report.yml):

## Package and version

<e.g. @prisma-next/postgres@0.5.2>

## What happened?

<one-sentence summary plus the relevant output line, secrets redacted>

## What did you expect to happen?

<one sentence>

## Minimal reproduction

1. <step one>
2. <step two>
3. <step three>

```ts
// schema.psl excerpt + the query / command that fails
```

## Environment

- Node: <version>
- OS: <darwin/linux/win32> <version>
- Package manager: <pnpm/npm/yarn/bun/deno> <version>
- Database: <Postgres / Mongo> <version>

## Additional context

<optional — link to source skill's capability-gap entry, related
issue number, partner extension involved>

Feature-request body shape (fields named to match .github/ISSUE_TEMPLATE/feature_request.yml):

## What problem are you trying to solve?

<paragraph — the use case or pain point this would address>

## Proposed solution

```ts
// imagined usage of the API / behaviour you'd want
```

## Alternatives considered

<sentence or two — what you tried with the current API and why it didn't work>

## Scope and impact

<which package(s) this would touch; target-specific implications>

5. Title (issue path only)

• Bug: bug(<area>): <one-line summary> — e.g. bug(cli): migration plan exits 0 when there is no diff.
• Feature request: feat(<area>): <one-line summary> — e.g. feat(build): first-party Next.js plugin for contract emit.

Areas mirror the cluster of skills: cli, contract, migration, query, runtime, build, error, docs.

6. Surface for confirmation (issue path only)

Never auto-submit. The agent shows the rendered title and body to the user and asks: "This looks good to file. Shall I submit it to GitHub?". Submission only happens after explicit user approval.

7. Submit (issue path only)

Preferred. Two steps:

1. Write the rendered body to a temporary file. Use your file-write tool (the same tool you'd use to create any other file on disk) to write the body to e.g. wip/pn-issue-body.md or /tmp/pn-issue-body.md. The body content is just the markdown produced in step 4 of this workflow — no surrounding shell quoting, no heredoc.

2. Reference that file from gh. Run:

   gh issue create \
     --repo prisma/prisma-next \
     --title "<title>" \
     --body-file <path-from-step-1>
   

Anti-pattern (do not do this): inlining the body via --body "$(cat <<EOF …)" or --body-file <(cat <<EOF …). Those one-liners reliably leak literal cat <<'EOF' / EOF markers into the issue body when the agent reuses the template verbatim with the body interpolated. Always write the body to a real file first and pass the path.

If gh is not installed: open the prefilled new-issue URL in the browser:

https://github.com/prisma/prisma-next/issues/new/choose

…and instruct the user to paste the rendered body. The agent can copy the body to the clipboard via pbcopy (macOS), xclip (Linux), or by simply printing it in the chat for the user to copy.

8. Route to Discord (Q&A / design-feedback / direct-team-contact path)

When step 1 picked the Discord channel (steps 2–7 do not apply):

1. Surface the link. Give the user the canonical invite: https://pris.ly/discord. Suggest the channel that fits the question:
   • General usage / Q&A → the public #help or #prisma-next channel (channel naming evolves; the invite landing page lists current channels).
   • Extension-author / partner-integration / breaking-change-coordination questions → the public extension-authors channel, or the user can ping a maintainer directly once they're in the server.
2. Help draft the opening message. Prisma's Discord is searchable; a well-framed opening message gets a faster, more useful answer. The agent drafts a short message with:
   • One-sentence summary of what the user is trying to do.
   • The Prisma Next version (pnpm ls @prisma-next/postgres or equivalent).
   • A short code snippet (PSL excerpt, query, config file) where relevant — redacted the same way as a GitHub issue body (no DATABASE_URL, no customer schema names).
   • The specific question the user wants answered.
3. Do not auto-post. The agent surfaces the drafted message to the user — "here's an opening message you can paste into Discord; want to adjust before sending?" — and lets the user decide whether to paste it as-is, edit it, or pick a different framing.
4. Set expectations honestly. Discord is synchronous and best-effort. Bugs and concrete feature requests should land in GitHub regardless (use the issue path); Discord is for the conversation that gets you to "yes, this is a bug, file it" or "yes, this should be a feature, file it".

9. Follow up

• Issue path: record the issue URL in the user's project notes (or in the project's wip/ if there is one) so a later upgrade or related work can reference it. If the bug is the symptom of an old version of Prisma Next, suggest the user run prisma-next-upgrade (the separately-installed upgrade skill) — many bugs are fixed in newer releases.
• Discord path: once the conversation on Discord settles into a concrete bug or a concrete feature request, return to step 1 of this skill and file the issue (the Discord thread becomes the Notes / Where the gap surfaces reference in the issue body).

Common Pitfalls

1. Auto-submitting without confirmation. Always show the body first. The user owns the public-facing artifact, not the agent.
2. Pasting DATABASE_URL or other secrets into the body. redact aggressively. Replace with postgresql://USER:PASS@HOST/DB placeholders.
3. Pasting a customer's confidential domain schema. When original model and field names would leak confidential information (product codenames, customer identifiers, regulated-data fields), rename to neutral placeholders before the body goes into a public issue. Otherwise, keep the original names — a faithful excerpt is easier for the framework team to reason about than a re-themed one. Over-renaming is its own readability cost.
4. Filing a documentation question as a bug. Documentation questions belong in another skill or in a GitHub Discussion (if the repo enables them). Bugs are about the surface misbehaving.
5. Conflating bug + feature in one issue. File two. Mixed issues are hard to triage and hard to close.
6. Filing without a version. "I'm using Prisma Next, it's broken" without the version makes triage hopeless. The version is the cheapest piece of context to capture; always include it.

What Prisma Next doesn't do yet

• In-product feedback channel. No prisma-next feedback CLI command. The GitHub Issues page is the canonical surface. If you want a CLI-side feedback command, file a feature request via this skill.

Reference Files

• https://github.com/prisma/prisma-next/issues/new/choose — the canonical submission surface.
• https://cli.github.com/manual/gh_issue_create — the gh command reference.

Checklist

• Classified as bug or feature request (not both in one issue).
• Environment block present: PN version, Node, package manager, OS.
• Reproduction is minimal, public-safe, secret-free.
• Schema fragments use original names where safe; renamed to neutral placeholders only where original names would leak confidential domain detail.
• Title in conventional-commit form (bug(area): … / feat(area): …).
• Body shown to the user for confirmation before submission.
• Submitted via gh issue create (preferred) or via the prefilled new-issue URL.
• Issue URL captured for future reference.
• Suggested prisma-next-upgrade if the bug may already be fixed in a newer release.