prisma-next-feedback

Prisma Next — フィードバック（バグ報告、機能リクエスト、チームへの質問）

データコントラクトを編集すれば、あとは Prisma が処理します。

このスキルは、機能ギャップのルーティングパターンにおける終着点です。他のすべての Prisma Next スキルにあるPrisma Next がまだ対応していないことの項目は、ユーザーがそのギャップの解消を望む場合にここへ誘導します。また、「これはバグです」、「イシューを作成して」、「機能リクエスト」、「チームに質問できますか？」、*「X を Prisma Next とどのように統合すればよいですか？」*といったプロンプトにも直接反応します。

このスキルの役割は、適切な窓口（GitHub のイシューまたは Discord）を選び、フレームワークチームが対応できる構造化された、公開しても安全なイシュー本文（秘密情報や独自のスキーマを含まないもの）を作成するか、同期的に質疑応答できる Prisma Discord への直接リンクをユーザーに案内することです。ユーザーの明示的な確認なしに、GitHub への投稿が行われることはありません。

正式な窓口：

• GitHub Issues（バグと具体的な機能リクエスト）：https://github.com/prisma/prisma-next/issues/new/choose
• Prisma Discord（質疑応答、設計へのフィードバック、チームへの直接連絡 — 拡張機能の作者も含む）：https://pris.ly/discord

使用する場合

• 別の prisma-next-* スキルから機能ギャップに関する項目が提示され、ユーザーが*「はい、機能リクエストを作成してください」*と答えた場合。
• ユーザーが*「これはバグです」、「これを登録して」、「これを報告して」、「PN に対するイシューを作成して」、「フィードバックを送って」、「これは機能として追加すべきです」*と言った場合。
• ユーザーが予期しない動作（終了コードが誤っている、実際に起きたことと一致しないエラーメッセージ、実行時の動作と一致しない型シグネチャ、安全そうに見えるマイグレーションをプランナーが拒否したなど）を説明し、それをフレームワークチームに知らせたい場合。
• ユーザーが*「この件について Prisma チームに質問できますか？」、「チームと話せる場所はありますか？」、「X にはこの方法で対応するのが意図されたやり方ですか？」、「<自分の拡張機能／ツール>を PN とどのように統合すればよいですか？」*など、オープンな質疑応答や設計へのフィードバックを求めるプロンプトを送った場合。拡張機能の作者からの統合に関する質問も含みます。

使用しない場合

• ユーザーが自分のコードでバグを修正したい場合。修正方法は別のスキル（デバッグ／コントラクト／マイグレーション／クエリ／ランタイム／ビルド）が担当します。まず適切なスキルに引き継ぎ、ユーザーがフレームワークに別の動作を明示的に求めた場合にのみ、フィードバックへ切り替えます。
• ユーザーが Prisma Next をアップグレードしたい場合（すでにバグが修正されている可能性があります）→ prisma-next-upgrade スキル（別途インストールが必要）。このスキルでは、アップグレード前の確認事項として触れています。
• ユーザーの質問が、クラスター内のワークフロースキルですでに扱われている場合（「列を追加するには？」 → prisma-next-contract、「適切なクエリインターフェースは？」 → prisma-next-queries）。チームではなくワークフロースキルに誘導します。スキルを読み込んで質問に回答し、エージェントが対応できない場合にのみ Discord へエスカレーションします。

主な概念

• 3つの連絡先、1つの判断。 GitHub Issues（バグと具体的な機能リクエスト）、Prisma Discord（Q&A、設計へのフィードバック、チームへの直接連絡）、または別のクラスター内スキル（質問の内容がチームへの引き継ぎではなく、ワークフローに関する質問だと判明した場合）を利用します。このスキルでは、最初に連絡先を判断し、その後のすべてはその判断に従います。
• 公開される成果物です。 GitHub の Issue と Discord のメッセージは、どちらも誰でも閲覧でき、アーカイブされます。本文やメッセージには、DATABASE_URL の文字列、社内スキーマの断片、サンプル行の顧客データなど、ユーザーが公開したくない内容を含めてはいけません。エージェントは、どちらに投稿する場合も事前に機密情報を削除します。
• バグ、機能リクエスト、質問の違い。 バグとは「文書化された機能が予期しない動作をした」ことです。機能リクエストとは「まだ存在しない機能が欲しい」ことです。質問とは「Xについて誰かと話し合いたい、または、そもそもバグかどうか確信がない」ことです。機能の不足に関するケースの多くは機能リクエストに、拡張機能の作成者からの問い合わせの多くは質問に該当します。
• フレームワークチームが再現できることが必要です（Issue のみ）。 再現手順のないバグ報告は、対応が格段に難しくなります。可能であれば、エージェントはチームがローカルで再実行できる最小限の再現例を作成します。理想的には、チームがすでにチェックアウトしている examples/prisma-next-demo に対する小さな変更を使います。Discord での Q&A に完全な再現例は必要ありません。短いコードスニペットと質問があれば、通常は十分です。

ワークフロー

1. 連絡先を選ぶ

ユーザーはチームに何かを引き継ぎたいと考えています。どの連絡先を使うべきでしょうか？

次のいずれかに該当する場合は、GitHub Issue を使います。

• ユーザーが具体的なバグを説明している（バグと機能リクエストの区別については、以下の 分類 を参照してください）。
• ユーザーが、バックログに登録したい具体的な機能リクエストを持っている（機能名、具体的な API の形式、具体的な CLI フラグなど）。
• 別の prisma-next-* スキルの機能不足に関する項目から、機能リクエストを送るためにこちらへ案内された。

次のいずれかに該当する場合は、Prisma Discord（https://pris.ly/discord）を使います。

• ユーザーが、自由形式の質問をしている（「X を行うのに、これが意図された方法ですか？」、「Y にはどう取り組みますか？」、「奇妙な動作が見られますが、バグかどうか確信がありません」）。
• ユーザーが機能リクエストを提出する前に設計へのフィードバックを求めている（「X を行うカスタムミドルウェアの作成を検討していますが、これはフレームワークの方向性に合っていますか？」）。
• ユーザーが拡張機能の作成者で、チームとのやり取りが必要な統合に関する質問をしている（ピア依存関係の調整、破壊的変更の時期、新しい拡張ポイントなど）。
• ユーザーが明示的にチームへの問い合わせを希望している（「これについてチームに聞いてもいいですか？」、「Prisma と話せる場所はありますか？」、「拡張機能の作成者はチームとどこで話し合っていますか？」）。

次のいずれかに該当する場合は、両方を順番に使います。

• ユーザーがバグと、それに関連する機能リクエストの両方を持っている。2つの GitHub Issue を別々に作成し、1つの Issue にまとめないでください。
• ユーザーが機能リクエストを提出する前に設計について話し合いたいと考えている。まず Discord で話し合い、内容が固まったら Issue を作成してください。

2. 分類する（Issue の場合のみ）

ユーザーは GitHub Issue を作成しようとしています。これはバグでしょうか、それとも機能リクエストでしょうか？

次のいずれかに該当する場合は、バグです。

• 文書化された CLI コマンドが誤った終了コードを返した。
• エラーエンベロープの fix フィールドの内容が誤解を招く、または正しくなかった。
• 公開されている TypeScript のシグネチャが、実行時の動作と一致しない。
• プランナーが、有効であるべきマイグレーションを拒否した（または無効であるべきマイグレーションを受け入れた）。
• コントラクトの出力によって生成された成果物が、実行時に読み込めない。
• その他、文書化された機能が誤った動作をしたケース。

次のいずれかに該当する場合は、機能リクエストです。

• ユーザーが、まだ存在しない機能を求めている（PN がまだ対応していないことの多くは、こちらに該当します）。
• ユーザーが、より分かりやすいエラーメッセージ、追加の CLI フラグ、新しいミドルウェア、追加のバンドラープラグインなどを求めている。

両方に該当する場合、つまりバグがあり、ユーザーが関連する機能も求めている場合は、2つの Issue を別々に作成してください。1つにまとめると、フレームワークチームによるトリアージが難しくなります。

3. 最小限の本文を収集する（イシューパスのみ）

どちらの種類でも、以下を収集します。

• Prisma Next のバージョン：pnpm ls @prisma-next/postgres（または @prisma-next/mongo）。プロジェクトで対象のパッケージを使用している場合は、そのバージョンが正式なバージョンです。
• Node のバージョン：node -v。
• パッケージマネージャー：pnpm／npm／yarn／bun／deno。
• OS：darwin／linux／win32 とバージョン文字列があれば十分です。

バグ報告では、さらに以下を収集します。

• 問題が発生した正確なコマンド（例：prisma-next migration plan --name add-email）。
• 出力の全文。構造化されたエラーエンベロープが関係する場合は -v を付けてください。DATABASE_URL やその他のシークレットは伏せてください。
• 問題を再現する最小限の src/prisma/contract.prisma／src/prisma/contract.ts の抜粋。無関係なモデルは削除してください。情報漏えいの懸念がない場合は、ユーザーのコントラクトにある元のモデル名とフィールド名を維持してください。実際の内容に忠実な抜粋のほうが、フレームワークチーム（および今後このイシューを読む人）にとって、テーマを変えたものよりもはるかに検討しやすくなります。元の名前から機密性の高いドメイン情報（製品名、内部コードネーム、顧客識別子、規制対象データのフィールド名）が漏れる場合に限り、汎用的なプレースホルダー（User、Post、Tag）に変更してください。
• 再現手順。番号付きリストにしてください。
• 期待される動作：1 文で記述してください。
• 実際の動作：1 文と、関連する出力行を記載してください。
• 回避策（ある場合）：1 文で記述してください。

機能リクエストでは、さらに以下を収集します。

• 希望する API または動作：1 段落で記述してください。可能であれば具体的な形式（CLI フラグ、設定フィールド、ミドルウェアのエクスポート、プラグイン API）も記載してください。
• 現在、どこで不足が表面化しているか：リクエストのきっかけとなったスキルの PN がまだ対応していないこと の項目、またはユーザーが完了しようとしていたワークフローを記載してください。
• 現在の回避策（ある場合）：1 文で記述してください（ユーザーが参照しているスキルの本文に、すでに記載されている場合もあります）。

4. 本文を生成する

このリポジトリには GitHub Issue Forms（.github/ISSUE_TEMPLATE/bug_report.yml と feature_request.yml）が用意されています。ユーザーが https://github.com/prisma/prisma-next/issues/new/choose にアクセスすると、該当するテンプレートを選び、フォームの各フィールドに入力します。このスキルは同じ構造で本文を生成するため、フォームの各項目と 1 対 1 で対応します（フォームを使わない場合でも、gh issue create --body-file が解析可能な内容を生成できます）。

バグ報告の本文形式（.github/ISSUE_TEMPLATE/bug_report.yml に合わせたフィールド名）：

## Package and version

<e.g. @prisma-next/[email protected]>

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

機能リクエストの本文形式（.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. タイトル（イシューパスのみ）

• バグ：bug(<area>): <one-line summary> — 例：bug(cli): migration plan exits 0 when there is no diff。
• 機能リクエスト：feat(<area>): <one-line summary> — 例：feat(build): first-party Next.js plugin for contract emit。

エリアはスキルの分類に対応しています：cli、contract、migration、query、runtime、build、error、docs。

6. 確認のために提示する（イシューパスのみ）

自動送信は絶対にしないでください。 エージェントは生成したタイトルと本文をユーザーに提示し、次のように尋ねます："この内容で送信できそうです。GitHub に送信してもよいですか？"。送信は、ユーザーが明示的に承認した後にのみ行います。

7. 送信する（issue のみの経路）

推奨される方法です。手順は 2 つです。

1. レンダリング済みの本文を一時ファイルに書き込みます。 ファイル書き込みツール（ディスク上に他のファイルを作成するときに使用するものと同じツール）を使い、本文を wip/pn-issue-body.md や /tmp/pn-issue-body.md などに書き込みます。本文の内容は、このワークフローの手順 4 で生成した Markdown のみです。シェルの引用符やヒアドキュメントで囲まないでください。

2. そのファイルを gh から参照します。 次を実行します。

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

アンチパターン（実行しないでください）： 本文を --body "$(cat <<EOF …)" や --body-file <(cat <<EOF …) でインライン化すること。エージェントが本文を挿入したテンプレートをそのまま再利用すると、これらのワンライナーは cat <<'EOF' や EOF というマーカーを issue の本文に文字どおり残してしまうことがあります。必ず最初に本文を実ファイルに書き込み、そのパスを渡してください。

gh がインストールされていない場合は、事前入力済みの新規 issue 作成 URL をブラウザーで開きます。

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

……そして、レンダリング済みの本文を貼り付けるようユーザーに伝えます。エージェントは、pbcopy（macOS）、xclip（Linux）を使って本文をクリップボードにコピーするか、チャットにそのまま表示してユーザーがコピーできるようにします。

8. Discord に誘導する（Q&A／設計へのフィードバック／チームへの直接連絡の経路）

手順 1 で Discord チャンネルが選ばれた場合（手順 2〜7 は適用されません）：

1. リンクを提示します。 正式な招待リンク https://pris.ly/discord をユーザーに案内します。質問に合ったチャンネルを提案します。
   • 一般的な使い方／Q&A → 公開の #help または #prisma-next チャンネル（チャンネル名は変更されることがあるため、招待ページに現在のチャンネルが記載されています）。
   • 拡張機能の作成者／パートナー連携／破壊的変更の調整に関する質問 → 公開の extension-authors チャンネル。あるいは、サーバーに参加後、メンテナーに直接メンションできます。
2. 最初に送るメッセージの作成を支援します。 Prisma の Discord は検索可能です。要点が整理された最初のメッセージを送ると、より迅速で役立つ回答を得られます。エージェントは次の内容を含む短いメッセージを作成します。
   • ユーザーが実現しようとしていることの 1 文での要約。
   • Prisma Next のバージョン（pnpm ls @prisma-next/postgres または同等のコマンド）。
   • 関連する場合は短いコードスニペット（PSL の抜粋、クエリ、設定ファイル）。GitHub issue の本文と同様に、機密情報を伏せます（DATABASE_URL や顧客のスキーマ名は含めません）。
   • ユーザーが回答を求めている具体的な質問。
3. 自動投稿しないでください。 エージェントは作成したメッセージをユーザーに提示し、「Discord に貼り付けられる最初のメッセージを作成しました。送信前に調整しますか？」と確認します。メッセージをそのまま貼り付けるか、編集するか、別の表現にするかはユーザーに任せます。
4. 期待値を正直に伝えます。 Discord はリアルタイムでのやり取りですが、対応はベストエフォートです。バグや具体的な機能リクエストは、いずれにせよ GitHub に登録してください（issue の経路を使用します）。Discord は、「はい、これはバグです。issue を作成してください」または「はい、これは機能として追加すべきです。issue を作成してください」という判断に至るまでの会話に使います。

9. フォローアップする

• issue の経路：issue の URL をユーザーのプロジェクトノート（またはプロジェクトに wip/ があればそこ）に記録し、後のアップグレードや関連作業で参照できるようにします。バグが Prisma Next の古いバージョンに起因する症状である場合は、ユーザーに prisma-next-upgrade（別途インストールするアップグレードスキル）の実行を提案します。新しいリリースでは多くのバグが修正されています。
• Discord の経路：Discord での会話を通じて具体的なバグや機能リクエストが明らかになったら、このスキルの手順 1 に戻って issue を作成します（Discord のスレッドは、issue の本文に記載する Notes／Where the gap surfaces の参照先になります）。

よくある落とし穴

1. 確認せずに自動送信する。 必ず最初に本文を表示してください。公開する成果物の所有者はエージェントではなく、ユーザーです。
2. 本文に DATABASE_URL などのシークレットを貼り付ける。 積極的に redact してください。postgresql://USER:PASS@HOST/DB のようなプレースホルダーに置き換えます。
3. 顧客の機密性の高いドメインスキーマを貼り付ける。 元のモデル名やフィールド名から機密情報（製品のコードネーム、顧客識別子、規制対象データのフィールド）が漏れる場合は、公開 issue に本文を投稿する前に、中立的なプレースホルダーに置き換えてください。それ以外の場合は、元の名前をそのまま使ってください。内容に忠実な抜粋のほうが、テーマを変更したものよりフレームワークチームが状況を把握しやすくなります。過剰な置き換えは、それ自体が読みやすさを損ないます。
4. ドキュメントに関する質問をバグとして報告する。 ドキュメントに関する質問は、別のスキル、または GitHub Discussion（リポジトリで有効になっている場合）で扱ってください。バグとは、動作に問題があるものです。
5. バグと機能要望を1つの issue にまとめる。 2つに分けて報告してください。混在した issue はトリアージもクローズも困難です。
6. バージョンを記載せずに報告する。 バージョンなしで「Prisma Next を使っていますが、動きません」と報告されても、トリアージは非常に困難です。バージョンは最小限の手間で記録できるコンテキストです。必ず含めてください。

Prisma Next でまだできないこと

• 製品内のフィードバックチャネル。 prisma-next feedback CLI コマンドはありません。GitHub Issues ページが正式な投稿先です。CLI 側のフィードバックコマンドを希望する場合は、このスキルを通じて機能要望を提出してください。

参考ファイル

• https://github.com/prisma/prisma-next/issues/new/choose — 正式な投稿先。
• https://cli.github.com/manual/gh_issue_create — gh コマンドのリファレンス。

チェックリスト

• バグか機能要望のどちらかに分類している（1つの issue に両方を含めない）。
• 環境情報を記載している：PN のバージョン、Node、パッケージマネージャー、OS。
• 再現手順が最小限で、公開しても安全であり、シークレットを含まない。
• スキーマの断片では、安全な場合は元の名前を使用し、元の名前から機密性の高いドメイン情報が漏れる場合に限り、中立的なプレースホルダーに置き換えている。
• タイトルが Conventional Commits 形式（bug(area): …／feat(area): …）になっている。
• 送信前に、ユーザーに確認用の本文を表示している。
• gh issue create（推奨）または事前入力済みの新規 issue URL から送信している。
• 今後参照できるよう、issue の URL を記録している。
• 新しいリリースですでに修正されている可能性があるバグには、prisma-next-upgrade を提案している。