prisma-next-feedback

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

Prisma Next — 反馈（Bug报告、功能请求、团队问答）

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

编辑你的数据契约。其余工作交给Prisma处理。

本技能是功能缺口路由模式的终端环节。当用户希望填补其他Prisma Next技能中“Prisma Next目前尚未支持”条目里的功能缺口时，会路由到本技能；此外，当用户输入诸如“这是一个bug”、“创建Issue”、“功能请求”、“我可以向团队咨询这个问题吗？”、“我该如何将X与Prisma Next集成？”等提示时，本技能也会直接触发。

本技能的职责是选择合适的渠道——GitHub Issue或Discord，然后生成一份结构化、适合公开的Issue内容（不含机密信息、专有Schema）供框架团队处理，或者为用户提供Prisma Discord的直接链接以进行同步问答。未经用户明确确认，绝不会自动提交到GitHub。

官方渠道：

GitHub Issues（Bug报告 + 具体功能请求）：https://github.com/prisma/prisma-next/issues/new/choose
Prisma Discord（问答、设计反馈、直接联系团队——包括扩展开发者）：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.

其他
```
prisma-next-*
```
技能中的功能缺口条目触发，且用户表示“是的，提交功能请求”。
用户提及“这是一个bug”、“提交这个问题”、“报告这个问题”、“针对PN创建Issue”、“发送反馈”、“这应该成为一项功能”。
用户描述了意外行为——错误的退出码、与实际情况不符的错误信息、与运行时行为不匹配的类型签名、规划器拒绝了看似安全的迁移——并希望框架团队关注该问题。
用户询问“我可以向Prisma团队咨询这个问题吗？”、“有没有可以联系团队的渠道？”、“这是实现X的预期方式吗？”、“我该如何将<我的扩展/我的工具>与PN集成？”，或者其他开放式问答或设计反馈类问题——包括扩展开发者提出的集成问题。

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.

用户希望自行修复自己代码中的bug。修复操作对应其他技能（调试/契约/迁移/查询/运行时/构建）。先路由到对应技能；仅当用户明确希望框架做出修改时，才转而使用反馈渠道。
用户希望升级Prisma Next（bug可能已在新版本中修复）→ 使用单独安装的
```
prisma-next-upgrade
```
技能；本技能会将其作为预检步骤提及。
用户的问题已被集群中的某个工作流技能覆盖（“我该如何添加列？”→
```
prisma-next-contract
```
；“正确的查询接口是什么？”→
```
prisma-next-queries
```
）。路由到工作流技能，而非联系团队——加载对应技能、回答问题，仅当Agent无法解答时才升级到Discord。

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.

三种渠道，一次决策。GitHub Issues（Bug报告 + 具体功能请求）、Prisma Discord（问答、设计反馈、直接联系团队），或集群中的其他技能（当问题属于工作流问题而非需要移交团队的问题时）。技能的首要步骤是确定渠道；后续所有操作均以此为基础。
公开产物。GitHub Issue和Discord消息均为全球可读且会被存档。内容/消息不得包含
```
DATABASE_URL
```
字符串、内部公司Schema片段、示例行中的客户数据，或任何用户不愿公开的内容。Agent在提交前会先进行脱敏处理。
Bug vs 功能 vs 问题。Bug指“文档描述的功能出现意外行为”。功能请求指“我需要一项目前不存在的功能”。问题指“我想与他人讨论X，或者不确定这是否是一个bug”。许多功能缺口路由属于功能请求；许多扩展开发者的提问属于问题范畴。
框架团队需要复现（仅Issue渠道）。没有复现步骤的Bug报告更难处理。尽可能生成团队可在本地重新运行的最小复现示例——理想情况下是对
```
examples/prisma-next-demo
```
进行小幅修改，团队已检出该示例。Discord问答不需要完整的复现步骤——通常一段简短的代码片段加上问题即可。

Workflow

工作流程

1. Pick the channel

1. 选择渠道

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.

用户希望将问题移交团队。应选择哪个渠道？

选择GitHub Issue的情况：

用户描述了具体的Bug（请参阅下文“分类”部分了解Bug与功能请求的区分）。
用户有具体的功能请求——一项明确的功能、特定的API形态、特定的CLI标志——希望加入待办事项。
其他
```
prisma-next-*
```
技能中的功能缺口条目将用户路由到此处提交功能请求。

选择Prisma Discord（https://pris.ly/discord）的情况：

用户提出开放式问题——“这是实现X的预期方式吗？”、“你会如何处理Y？”、“我看到了奇怪的行为，但不确定是否是Bug。”
用户希望在提交功能请求前获取设计反馈——“我们正在考虑构建一个实现X的自定义中间件，这符合框架的发展方向吗？”
用户是扩展开发者，有需要与团队反复沟通的集成问题（依赖协调、破坏性变更时间安排、新的扩展接口）。
用户明确要求联系团队——“我可以向团队咨询这个问题吗？”、“有没有可以联系Prisma的渠道？”、“扩展开发者在哪里与团队讨论问题？”

依次选择两者的情况：

用户同时遇到Bug和相关的功能请求——创建两个独立的GitHub Issue，不要将它们混在一个Issue中。
用户希望在提交功能请求前先讨论设计方案——先在Discord中沟通，确定方案形态后再创建Issue。

2. Classify (issue path only)

2. 分类（仅Issue渠道）

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.

用户正在创建GitHub Issue。这是Bug报告还是功能请求？

属于Bug的情况：

文档中记录的CLI命令返回了错误的退出码。
错误信封的
```
fix
```
字段具有误导性或不正确。
已发布的TypeScript签名与运行时行为不匹配。
规划器拒绝了本应有效的迁移（或接受了本应无效的迁移）。
契约生成的产物在运行时无法加载。
其他任何文档描述的功能出现错误行为的情况。

属于功能请求的情况：

用户需要一项目前不存在的功能（大多数“PN目前尚未支持”的条目属于此类）。
用户希望获得更好的错误信息、额外的CLI标志、新的中间件、额外的打包器插件等。

如果同时存在Bug和相关功能请求——创建两个独立的Issue。混合提交会增加框架团队的分类难度。

3. Collect the minimum body (issue path only)

3. 收集最小化内容（仅Issue渠道）

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

对于任意一种类型：

Prisma Next版本：
```
pnpm ls @prisma-next/postgres
```
（或
```
@prisma-next/mongo
```
）。如果项目使用目标包，则该版本为标准版本。
Node版本：
```
node -v
```
。
包管理器：
```
pnpm
```
/
```
npm
```
/
```
yarn
```
/
```
bun
```
/
```
deno
```
。
操作系统：
```
darwin
```
/
```
linux
```
/
```
win32
```
，加上版本字符串即可。

对于Bug报告，还需额外收集：

出错的具体命令（例如

prisma-next migration plan --name add-email

）。

完整输出，如果涉及结构化错误信封，请加上
```
-v
```
参数。脱敏
```
DATABASE_URL
```
和其他机密信息。
最小化的
src/prisma/contract.prisma
/
src/prisma/contract.ts
片段以复现问题。移除无关模型。当用户的契约中的原始模型和字段名称不会泄露敏感信息时，保留原样——忠实的片段比重新命名的片段更便于框架团队（以及未来查看Issue的读者）分析。仅当原始名称会泄露机密领域细节（产品名称、内部代号、客户标识符、受监管数据字段名称）时，才重命名为中性占位符（
```
User
```
、
```
Post
```
、
```
Tag
```
）。
复现步骤，以编号列表形式呈现。
预期行为——一句话描述。
实际行为——一句话描述加上相关输出行。
临时解决方案（如有）——一句话描述。

对于功能请求，还需额外收集：

期望的API或行为——一段描述。尽可能提供具体形态（CLI标志、配置字段、中间件导出、插件API）。
当前功能缺口的触发场景——哪个技能的“PN目前尚未支持”条目触发了请求，或者用户当时正在执行的工作流。
当前的临时解决方案（如有）——一句话描述（用户遵循的技能内容可能已提及此内容）。

4. Render the body

4. 生成内容

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

markdown

undefined

仓库提供了GitHub Issue表单（

.github/ISSUE_TEMPLATE/bug_report.yml

和

feature_request.yml

）。当用户访问https://github.com/prisma/prisma-next/issues/new/choose时，他们会选择匹配的模板并填写表单字段；本技能生成的内容采用相同的结构化格式，以便与表单一一对应（即使未使用表单，

gh issue create --body-file

也能生成可解析的产物）。

Bug报告内容格式（字段名称与

.github/ISSUE_TEMPLATE/bug_report.yml

匹配）：

markdown

undefined

Package and version

包及版本

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

<例如：@prisma-next/postgres@0.5.2>

What happened?

发生了什么？

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

<一句话总结加上相关输出行，已脱敏机密信息>

What did you expect to happen?

预期行为是什么？

<一句话描述>

Minimal reproduction

最小化复现步骤

<step one>
<step two>
<step three>

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

<步骤一>
<步骤二>
<步骤三>

// schema.psl片段 + 出错的查询/命令

Environment

环境信息

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

Node: <版本>
OS: <darwin/linux/win32> <版本>
包管理器: <pnpm/npm/yarn/bun/deno> <版本>
数据库: <Postgres / Mongo> <版本>

Additional context

额外信息


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

~~~markdown

<可选——链接到触发请求的源技能功能缺口条目、相关Issue编号、涉及的合作伙伴扩展>


功能请求内容格式（字段名称与`.github/ISSUE_TEMPLATE/feature_request.yml`匹配）：

~~~markdown

What problem are you trying to solve?

你试图解决什么问题？

<段落——该功能将解决的使用场景或痛点>

Proposed solution

提议的解决方案

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

// 你期望的API/行为的使用示例

Alternatives considered

考虑过的替代方案

<一两句话——你尝试过的现有API及其不足之处>

Scope and impact

范围与影响

undefined

<该功能将涉及哪些包；特定目标的影响>

undefined

5. Title (issue path only)

5. 标题（仅Issue渠道）

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

Bug报告：

bug(<领域>): <一行摘要>

——例如

bug(cli): migration plan在无差异时返回0

。

功能请求：

feat(<领域>): <一行摘要>

——例如

feat(build): 用于契约生成的官方Next.js插件

。

领域与技能集群对应：

cli

、

contract

、

migration

、

query

、

runtime

、

build

、

error

、

docs

。

6. Surface for confirmation (issue path only)

6. 确认环节（仅Issue渠道）

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.

绝不自动提交。Agent会向用户展示生成的标题和内容，并询问：“这份内容可以提交了。是否要提交到GitHub？”。仅在用户明确批准后才提交。

7. Submit (issue path only)

7. 提交（仅Issue渠道）

Preferred. Two steps:

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.

Reference that file from
gh
. Run:

bash

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 …)"

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

gh

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

text

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.

推荐方式。分为两步：

将生成的内容写入临时文件。使用文件写入工具（与创建其他磁盘文件相同的工具）将内容写入例如
```
wip/pn-issue-body.md
```
或
```
/tmp/pn-issue-body.md
```
。内容仅为步骤4中生成的markdown——无需添加周围的shell引号或 heredoc。

通过
gh
引用该文件。运行：

bash

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

反模式（请勿使用）：通过

--body "$(cat <<EOF …)"

或

--body-file <(cat <<EOF …)

内联内容。当Agent直接复用模板并插入内容时，这些单行命令会可靠地将字面量

cat <<'EOF'

EOF

标记泄露到Issue内容中。始终先将内容写入真实文件，再传递文件路径。

如果未安装

gh

：在浏览器中打开预填充的新建Issue链接：

text

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

并指导用户粘贴生成的内容。Agent可通过

pbcopy

（macOS）、

xclip

（Linux）将内容复制到剪贴板，或直接在聊天中打印内容供用户复制。

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

8. 路由到Discord（问答/设计反馈/直接联系团队渠道）

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

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

当步骤1选择Discord渠道时（步骤2-7不适用）：

展示链接。为用户提供官方邀请链接：https://pris.ly/discord。建议用户选择适合问题的频道：
- 通用使用/问答→公开的
```
#help
```
  或
```
#prisma-next
```
  频道（频道名称会更新；邀请登录页面会列出当前频道）。
- 扩展开发者/合作伙伴集成/破坏性变更协调问题→公开的扩展开发者频道，或用户加入服务器后可直接@维护者。
帮助起草开场消息。Prisma的Discord支持搜索；表述清晰的开场消息能更快获得有用的回复。Agent会起草一条简短消息，包含：
- 用户试图完成的目标的一句话总结。
- Prisma Next版本（
```
pnpm ls @prisma-next/postgres
```
  或等效命令的结果）。
- 一段简短的代码片段（PSL片段、查询、配置文件）（如相关）——与GitHub Issue内容一样进行脱敏处理（不含
```
DATABASE_URL
```
  、客户Schema名称）。
- 用户想要解答的具体问题。
绝不自动发布。Agent会向用户展示起草的消息——“这是你可以粘贴到Discord的开场消息；是否需要调整后再发送？”——并让用户决定是否直接粘贴、编辑或选择其他表述方式。
如实告知预期。Discord是同步且尽力而为的渠道。Bug和具体功能请求仍应提交到GitHub（使用Issue渠道）；Discord用于进行前置讨论，以确定“是的，这是一个Bug，提交它”或“是的，这应该成为一项功能，提交它”。

9. Follow up

9. 跟进

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

Issue渠道：将Issue URL记录到用户的项目笔记中（或项目的
```
wip/
```
目录中，如果有的话），以便后续升级或相关工作可以引用。如果Bug是由旧版本的Prisma Next导致的，建议用户运行
```
prisma-next-upgrade
```
（单独安装的升级技能）——许多Bug已在新版本中修复。
Discord渠道：当Discord上的讨论确定为具体Bug或功能请求时，返回本技能的步骤1并创建Issue（Discord线程将作为Issue内容中的“备注”/“功能缺口触发场景”参考）。

Common Pitfalls

常见误区

Auto-submitting without confirmation. Always show the body first. The user owns the public-facing artifact, not the agent.
Pasting
DATABASE_URL
or other secrets into the body.
```
redact
```
aggressively. Replace with
```
postgresql://USER:PASS@HOST/DB
```
placeholders.
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.
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.
Conflating bug + feature in one issue. File two. Mixed issues are hard to triage and hard to close.
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.

未经确认自动提交。始终先展示内容。用户拥有公开产物的所有权，而非Agent。
将
DATABASE_URL
或其他机密信息粘贴到内容中。严格进行脱敏处理。替换为
```
postgresql://USER:PASS@HOST/DB
```
占位符。
粘贴客户的机密领域Schema。当原始模型和字段名称会泄露机密信息（产品代号、客户标识符、受监管数据字段）时，在内容提交到公开Issue前重命名为中性占位符。否则，保留原始名称——忠实的片段比重新命名的片段更便于框架团队分析。过度重命名会降低可读性。
将文档问题作为Bug提交。文档问题属于其他技能或GitHub Discussion（如果仓库启用）的范畴。Bug是指功能出现错误行为。
在一个Issue中混合Bug和功能请求。分别创建两个Issue。混合Issue难以分类和关闭。
提交时未包含版本信息。“我使用Prisma Next，它坏了”但未提供版本信息会让分类工作无法进行。版本是最容易获取的上下文信息；始终包含它。

What Prisma Next doesn't do yet

Prisma Next目前尚未支持的功能

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.

内置反馈渠道。没有
```
prisma-next feedback
```
CLI命令。GitHub Issues页面是官方提交渠道。如果你需要CLI端的反馈命令，请通过本技能提交功能请求。

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.

https://github.com/prisma/prisma-next/issues/new/choose — 官方提交页面。
https://cli.github.com/manual/gh_issue_create —
```
gh
```
命令参考文档。

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.

已分类为Bug或功能请求（未在一个Issue中混合两者）。
包含环境信息块：PN版本、Node、包管理器、操作系统。
复现步骤最小化、适合公开、不含机密信息。
Schema片段在安全情况下保留原始名称；仅当原始名称会泄露机密领域细节时才重命名为中性占位符。
标题符合约定式提交格式（
```
bug(领域): …
```
/
```
feat(领域): …
```
）。
提交前已向用户展示内容并获得确认。
通过
```
gh issue create
```
（推荐方式）或预填充的新建Issue链接提交。
已记录Issue URL供未来参考。
如果Bug可能已在新版本中修复，建议用户运行
```
prisma-next-upgrade
```
。