Prisma Next Feedback

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).