jp-prd

JP PRD

ユーザーが高品質な Juspay 決済統合の PRD を作成、編集、または検証できるよう支援します。統合に特化し、実装への引き継ぎをスムーズにできる内容にしてください。PRD では、統合で実現すべきこと、対象となる入力／フロー／メソッド／サーフェス、および後続の設計で遵守すべき制約を定義します。後続の jp-architecture スキルが方法を決定し、jp-executor が実装します。

規約

• 裸のパスはスキルのルートから解決されます。{skill-root} はこのスキルのインストール先ディレクトリ、{project-root} はプロジェクトの作業ディレクトリです。
• インタラクション UI。 実行環境で利用できる場合は、製品に組み込まれた質問／選択／オプション UI を優先してください。ネイティブ UI が使える場合、自由形式のテキストでメニュー選択を再現してはいけません。ネイティブの選択 UI がない場合に限り、簡潔な通常のテキスト質問に切り替えてください。
• ファイルの役割。 .decision-log.md は正規の記憶および監査記録です。会話の進行に合わせて、すべての決定、変更、上書きをここに記録します。addendum.md は、後続ドキュメント（アーキテクチャ、エグゼキューター）に含めるべき、または重要ではあるものの PRD 自体には収まらない、ユーザー提供の詳細を保持します。これには、却下した代替案の根拠、検討した選択肢のマトリックス、メカニズム／トランスポートの決定、技術的な実装方法、詳細なペルソナ、サイジングデータが含まれます。ユーザーがそのような内容を提示したら、finalize まで待たずに会話中に addendum に記録してください。監査情報と上書き情報は addendum に記録しないでください。
• ドキュメントに基づく情報。 Juspay 製品の事実（製品名、統合形態、API／SDK のフィールド、エラーコード、Webhook の構造）は、docs-mcp-server ツールまたはユーザーから取得してください。記憶や学習データから取得してはいけません。ドキュメントから取得した事実には、すべて出典 URL を付けてください。
• 製品カタログ。 products/ は正式な情報源ではない概要カタログです。製品ごとの「概要／推奨する場面／主な概念／意図のシグナル」を掲載し、収束の過程で候補を絞り込むために使用します。正確な情報源ではないため、選択した slug／形態／プラットフォームは確定前に docs-mcp で照合してください。products/README.md を参照してください。
• ワークスペース。 {doc_workspace} は {project-root}/docs/juspay/ です（存在しない場合は作成します）。ここで生成する成果物は prd.md、addendum.md、.decision-log.md と、一時的な review-*.md／reconcile-*.md です。jp-architecture と jp-executor は同じフォルダーから読み込みます。
• 独自の設定なし。 このスキルは何も強制しません。設定ファイルも、言語や名称の解決方法もありません。ユーザーが提供した情報（ユーザーのリポジトリ、指定した製品／ドキュメント）と {doc_workspace} 内の成果物のみを読み込みます。
• リポジトリ分割に対応。 FE と BE が別々のリポジトリに存在する場合があります。このフォルダーがどちら側を保持しているか（または両方か）を検出して、構成を記録してください。もう一方のリポジトリですでに引き継ぎ資料が作成されている場合は、その引き継ぎ資料を正式なサイド間契約として取り込みます。references/split-integration.md を参照してください。
• ステージの追跡。 このスキルは prd ファネルフェーズを管理します（setup フェーズはエージェント設定時に先行して juspay-cli が出力するため、ここでは出力しません）。On Activation と Finalize で指定された時点に、juspay_track_integration_stage を使って prd を出力してください。これは非同期で実行し、処理をブロックしてはいけません。references/integration-stage-tracking.md を参照してください。

アクティベーション時

0. まず加盟店に接続します。質問やコードベースのスキャンよりも先に行ってください。 このスキルで最初に行う操作は、juspay_get_merchant_details（引数は不要）の実行を試みることです。ランチャーによってプロビジョニングされたセッションでは、ダッシュボード MCP（juspay-mcp）はすでに認証済みなので、この呼び出しはそのまま成功します。この呼び出しを試す前に、ユーザーにダッシュボードへのアクセス権があるか尋ねたり、どの Juspay 製品を使いたいか尋ねたりしてはいけません。

• データが返る → 接続済み。 merchant_id、client_id（デフォルトは merchant_id）、および**integrationType（アカウントで有効な製品。PP = HyperCheckout、EC_API = Express Checkout API、EC_SDK = Express Checkout SDK）を記録します。これはセッション全体を通じた事実の基準です。相手が利用している製品はすでに把握できているため、製品の選択時にはこれを確認**してください。何も分からない状態で製品の一覧を提示してはいけません。出所を mcp として .decision-log.md に記録します。
• ツールを利用できない、または呼び出しでエラーが発生 → 手動モード。 その場合に限り、アクセスについて質問できます。references/juspay-mcp.md に従って代替手段に切り替えてください。処理を止めてはいけません。
• ファネルの開始イベントを送信します。 接続の試行が解決した直後に、juspay_track_integration_stage(phase="prd", status="started") を非同期で送信します（setup マイルストーンはエージェントの設定時に juspay-cli がすでに送信しているため、ここで再送信してはいけません）。進行中の PRD を再開した場合は、今のセッションですでに送信済みなので、この操作を省略します。ユーザーにはこの操作について伝えないでください。references/integration-stage-tracking.md を参照してください。

1. このスキルでは Juspay 統合 PRD を作成すること、また、任意の時点でセクションの詳細を掘り下げたり（インラインでの高度な情報収集）、複数の視点から意思決定を検討したりできることを、ユーザーに簡潔に説明します。最初のメッセージでは、依頼内容が別のスキル向けではないか確認します。技術的な「方法」や統合設計については jp-architecture、実際の統合コードの作成については jp-executor を案内し、続行する前に該当する別のスキルを提案してください。
2. 意図を判定します。作成（PRD がない）、更新（既存の PRD がある）、検証（批評のみ）。曖昧な場合は質問してください。作成の場合、新しいワークスペースを設定する前に、{doc_workspace}/prd.md に進行中の PRD がないか確認します（フロントマターの status が final 以外）。見つかった場合は、最初からやり直すのではなく、再開するかユーザーに確認してください。
3. 引き継ぎの確認。 別のリポジトリでの実行によって作成された {doc_workspace}/handoff-<this_side>.md（またはユーザーが指定したパス）がないか確認します。存在する場合は読み込み、その Cross-Side Contract を確定事項として扱います。この側の PRD はそれに準拠する必要があり、接続部分を再設計してはいけません。references/split-integration.md を参照してください。

意図モード

作成。 {doc_workspace} を {project-root}/docs/juspay/ に設定します（なければ作成）。YAML フロントマター付きの prd.md を作成します（title、status、created、updated を含めます。created と updated は本日の日付、初期状態の status: draft と、トポロジースキャンで得た topology、this_side、other_side を設定します。references/split-integration.md を参照）。また、以降の意思決定を記録するファイルを明確にするため、ワークスペースに .decision-log.md のひな形を作成します。ファイルのパスをユーザーに伝えてください。続けて ## Discovery、次に ## Finalize を実行します。

更新。 変更内容をもとに PRD を整合させます。PRD、追記、.decision-log.md、元の入力を対象に情報を抽出します（取り込みではなく抽出してください）。.decision-log.md がない場合は、続行する前に PRD から簡潔なログを復元します。過去の意思決定と矛盾する点は、適用する前に明示してください。その後、## Finalize を実行します。

検証（または分析）。変更を加えずに批評します。references/validate.md を読み込みます。

情報収集

順序：（アクティベーション時の接続は完了済み）→ ブレインダンプ → コードベースと環境のスキャン → 製品の選択 → 作業モード → モードに応じた作業。 できるだけ早く作業モードに移行してください。やり取りは数回にとどめ、10回も続けないでください。急いでいるユーザーを、先行する確認作業のために待たせてはいけません。加盟店への接続はアクティベーション時のステップ 0 で完了しています。そのため製品の選択に進む頃には、アカウントで利用している製品をすでに把握しています。推測で質問するのではなく、確認してください。 ブレインダンプ。 常に最初に行います。ユーザーが詳細なコンテキストを段落で提示してきた場合も同様です。口頭でのコンテキストに加え、読み込んでほしい既存の入力（製品概要、既存のインテグレーションに関するメモ、以前の PRD の草稿、設計ドキュメント、対象のコードベース）も尋ねます。パスを指定するか、内容を貼り付けてもらいます。大きなドキュメントでも問題ありません。こちらで必要な情報を抽出します。「ほかに何かありますか？」と尋ねると、ユーザーが忘れかけていた情報を引き出せます。

コードベースと環境のスキャン。 対象のコードベースと環境を読み取り、現状に即した PRD を作成します。検出できる情報は尋ねないでください。

• スタックと構成要素： 言語／フレームワーク、パッケージマネージャー、バックエンドとフロントエンドの有無、モバイルか Web か（package.json、pubspec.yaml、requirements.txt、go.mod、AndroidManifest.xml、*.xcodeproj、index.html などを手掛かりにします）。
• トポロジー（リポジトリ分割の確認）： このフォルダーにどちらの側が含まれているかを分類します。選択した製品にバックエンドとフロントエンドの両方が必要で、一方しか存在しない場合は、分割の候補です。その旨を提示してください（実際に分割されたリポジトリ、モノレポ内の兄弟リポジトリ、もう一方の側がまだ着手されていない場合のいずれも、今回の実行では topology: split とし、存在する側だけを構築します）。topology（single-repo | split）、this_side（backend | frontend | fullstack）、other_side（backend | frontend | none）を記録します。詳しいルールは references/split-integration.md を参照してください。
• 既存の決済コード： 現在の決済／注文／チェックアウト処理、Webhook ルート、注文／決済の DB スキーマがあるか確認します。
• 環境： 既存のプロバイダー設定、環境／ホストの選択設定、シークレット管理方式を確認するため、.env／設定ファイルを調べます。シークレットの値は絶対に読み取ったり、出力したりせず、存在するキーだけを記録してください。本番環境が必須です。PRD の「環境」セクションでは本番環境をターゲットとして記録してください。サンドボックスか本番環境かをユーザーに選ばせないでください。また、ユーザーが明示的かつ自発的に求めた場合に限り、非本番環境について記載します。 調査結果をユーザーに伝え、確認してもらいます。

マーチャントアクセス（juspay-mcp）。 すでにアクティベーション時のステップ 0で処理済みです。その結果（モードと merchant_id／client_id／integrationType）を再利用してください。juspay_get_merchant_details を再度呼び出さず、ユーザーに再度尋ねないでください。ここで残っている作業は、ステップ 0 がツールを利用できない手動モードで完了し、識別子がまだ必要な場合に限り、references/juspay-mcp.md に従って、ユーザーから情報を得るか、ダッシュボードで確認する項目として記録することです。ステップ 0 が接続済みなら、必要な情報はすべてそろっています。そのまま製品の選択に進んでください。決して処理を止めないでください。

選択したモードと各値について、その出所（mcp | user | manual-dashboard）とともに prd.md と .decision-log.md に記録し、jp-architecture と jp-executor が再利用できるようにします。ここで行うのはダッシュボードの読み取り呼び出しのみです。認証情報のプロビジョニングは jp-executor で行います。

製品の選択。 すでに判明している情報に基づいて分岐します。あらかじめ決めたメニューを提示せず、アカウントで利用できない製品を提案しないでください。

• 空でない integrationType で接続されている場合 → アカウントを根拠に選択します。MID と、読みやすい名称に対応付けた有効なインテグレーション（PP → HyperCheckout、EC_API → Express Checkout API、EC_SDK → Express Checkout SDK）を示し、アカウントが利用しているプロダクト数に応じて選択します。インテグレーションが1つの場合 → 質問せず、内容を伝えて進めます（例：「<MID> としてサインインしています。アカウントでは HyperCheckout が利用されているため、これをここにインテグレーションします。」）。複数ある場合 → コードベースから得られる情報と組み合わせて推定し、確認します。選択肢として提示するのは、そのアカウントが利用しているインテグレーションだけです（例：「…アカウントでは Payment Page + EC API + EC SDK が利用されており、このリポジトリは <web/backend> のようなので、EC SDK を想定しています。よろしいですか？」）。「その他／新しいプロダクトを追加する」という選択肢を提示したり、integrationType に含まれないプロダクトを示したりしてはいけません。ユーザーがアカウントで利用できないプロダクトを求めた場合は、そのプロダクトはアカウントで有効になっていないこと、インテグレーションするには事前にJuspay に連絡して有効化する必要があることを伝えます。アカウントで利用できないプロダクトのスコープ設定や構築は行いません。
• それ以外の場合（integrationType が空または存在しない場合 — 新規マーチャント、手動モード、または MCP なし）→ ユーザーの目標に沿って、カタログとドキュメントから絞り込みます。 0. まず products/ を読みます — 推奨する場面／意図を示す手掛かり／概要を参考に、候補を1～3件に絞ります（あくまで方向付けです。products/README.md を参照）。
  1. 候補が絞り込めない場合は、list_products(category?) で現在のカタログを参照します。
  2. インテグレーション対象のプロダクトを、ユーザーとともに絞り込みます。

docs-mcp で確認（両方の分岐に適用）： 選択したプロダクトのドキュメントインデックスを explore_product(slug) で確認し、スラッグ／形態／プラットフォームを照合します。次に、認証情報、リクエスト／レスポンスのフィールド、エラーコード、Webhook の構造を定義しているページを doc_fetch_tool(url) で取得します。コードを生成するためではなく、PRD の根拠とするために必要な情報を抽出します。具体的には、用語集の語彙、機能要件を形作る機能と制約、エラーや例外の範囲、インテグレーション形態（ホステッドページ／ヘッドレス SDK／ダイレクト API）です。抽出した事実にはそれぞれ出典 URL を付けます。

インテグレーションは決済手段に依存しません。マーチャントが有効にする決済手段はダッシュボードや実行時の設定であり、PRD 作成時に選ぶものではありません。そのため、ユーザーに決済手段を選ばせないでください。

方向付けではなく、引き出すこと。 ディスカバリーでは、ユーザー自身のビジョンを引き出します。こちらの考えを押し付けてはいけません。「X について自由に教えてください」のような自由回答形式の質問は、選択式の質問よりも有効です。MVP の対象を絞ったり、フェーズを提案したりしそうになったら、そこで止めてユーザーに主導権を戻します。「v1 は Web チェックアウトのみで、モバイル画面は対象外と想定しています。よろしいですか？」のように推定して確認するのは問題ありません。ユーザーが特定のセクションをさらに深く掘り下げたり、複数の観点から比較したりしたい場合は、その場で対応します。

進め方。 ユーザーの言語で選択肢を提示し、利用できる場合はランタイム標準の選択 UI を使います。

• ファストパス — 残りの不明点をまとめた質問を1～2回行い、その後、推定した箇所に [ASSUMPTION] タグを付けて PRD 全体を作成します。ユーザーがレビューし、その後、反復して仕上げます。
• コーチングパス — PM 思考が必要なセクションを一緒に進めます。選択後、どちらの入り口が適切かを尋ねます。機能とフロー（機能優先 — 多くのインテグレーション、バックエンド／サーバー作業、社内ツール向け）またはジャーニー主導（支払い者／マーチャントの体験優先 — 消費者向けチェックアウト、UX を重視するフロー向け）です。選択した入り口に応じて、セクションの順序を決めます。

ワークスペースの状態は保持されるため、いつでも中断して再開できます。

懸念事項の確認。 ユーザーから提供された情報を読みながら、このケースで実際に重要なインテグレーション上の懸念事項を特定します。たとえば、Webhook／署名の処理、冪等性、注文の照合、本番稼働のゲート、プラットフォーム／SDK の対象範囲、公開 API の契約、テナント／設定の分離、可観測性、ロールバック／フォールバック、データ保存の境界などです。これらの懸念事項をもとに、Adapt-In Menu から取り込むテンプレートのセクションと、該当するクラスターがない場合に新たに作成するセクションを決めます。

フォームファクター。 コードベースから判別できない場合は、モバイル／Web／デスクトップ／複数画面／サーバーのみ／API のいずれかを確認します。 主要なインテグレーションフローは記録するものであり、作り上げるものではありません。 ジャーニーが必要な場合（購入者のチェックアウト、加盟店が運用するフロー、意味のある UX）は、実際のセッションについてユーザーに説明してもらいます。何がフローを開始するのか、どのようなシステム呼び出しが行われるのか、支払者／運用担当者には何が表示されるのか、完了をどのように確認するのかを聞き、その回答を UJ-N 形式にまとめて確認します。サーバーのみ、または API のみのインテグレーションでは、簡潔なフロー説明にまとめます。独立したペルソナのセクションは設けません。

PRD の方針

構成。 機能をグループ化し、FR はグローバルに採番した安定した ID を付けて階層化します。横断的な NFR は独立したセクションにまとめ、トレーサビリティマトリクスは省略します。ドキュメントはインテグレーションの内容に即したものにします。製品、方式、接点、フロー、リクエスト／レスポンスの想定、エラーが発生する箇所、照合の動作、環境ごとの動作、明示的な境界を扱います。PRD に詳しすぎる SDK／API の仕組みは addendum.md に記載するか、jp-architecture で決定します。assets/prd-template.md はチェックリストではなく、専門家の事前知識として扱います。Essential Spine が標準の構成です。インテグレーションにそのセクションが本当に不要でない限り、含めます。Adapt-In Menu は条件に応じて使います。インテグレーションの懸念事項に必要なクラスターを取り入れます。インテグレーションにメニューにない懸念事項がある場合は、セクションを新設します。適切な名前を付け、読者にとって役立つ位置に配置します。読みやすさを考慮して、順序を入れ替えたり、統合したりしてください。

記憶ではなくドキュメントを根拠にする。 用語集の用語、機能上の制約、エラーが発生する箇所、インテグレーションの形態は、docs-mcp の抽出内容（またはユーザーの情報）を出典とし、URL を引用します。トレーニングデータを根拠に、Juspay のフィールド名、エンドポイント、動作を断定してはいけません。

長さはインテグレーションの複雑さに応じて調整する。 単一の接点を持つ小規模なインテグレーションは、短くまとめられます。複数の方式や接点を持つもの、または Webhook／照合の比重が大きいものは、必要に応じて詳述します。PRD の主要な説明に入れる価値のない詳細は、addendum.md に記載します。

レビュアーゲート

Validate インテントおよび Finalize ステップ 3 で使用します。

レビュアーメニューを組み立てます。assets/prd-validation-checklist.md（PRD 品質評価基準）に基づくルーブリック確認担当者に加え、成果物に応じてアドホックなレビュアー（たとえば、複雑な成果物の場合はインテグレーションフローやエラー処理のレビュアー）を追加します。レビューの規模は、インテグレーションの複雑さに見合うものにします。

prd.md（存在する場合は addendum.md も）を対象に、各項目を並列サブエージェントに割り当てます。各サブエージェントはレビュー全文を {doc_workspace}/review-{slug}.md に書き、簡潔な要約（判定、主な指摘事項 2～5 件、ファイルパス）のみを返します。親エージェントはレビュー全文を保持しません。ルーブリック確認担当者は、references/validate.md のプロンプトと出力形式を使用します。サブエージェントを利用できない場合は、順次実行します。まずレビューをファイルに書き出し、その後で作業コンテキストからレビュー内容をフラッシュします。

指摘事項は分類して提示し、羅列するだけにしません。まずゲートの判定を一文で示し、次にクリティカルおよび高の指摘事項を説明します。中および低の指摘事項は、最後に「ほかに N 件、{file} を参照」とまとめます。指摘事項ごとに、自動修正するか、議論するか、未解決事項に回すか、無視するかを決めます。

Validate インテントでは、親エージェントがさらに references/validate.md の統合パイプラインを実行します。選択したすべてのレビュアーの出力を 1 つの HTML + Markdown レポートにまとめ、HTML を開きます。

最終確認

手順をユーザーに一文で伝えてから、順に進めます。レビュアーの修正後に作業をやり直さなくて済むよう、最後に仕上げを行います。

1. 意思決定ログの監査。 ユーザーと .decision-log.md を確認し、各項目を PRD に記載するか、追加文書に記載するか、保留にするかを決めます。
2. 入力の照合。 ユーザー提供の各入力（および各 docs-mcp ドキュメントセット）について、prd.md と addendum.md と照合するサブエージェントを割り当てます。各サブエージェントは抽出内容を {doc_workspace}/reconcile-{slug}.md に書き込み、簡潔な要約（入力名、ギャップ 2～5 件、ファイルパス）のみを返します。ギャップを明らかにします。特に、FR の構造では暗黙に抜け落ちる定性的なアイデア（トーン、エラー処理への期待、照合ルール）に注意します。これは仕上げの前に必ず行います。
3. レビュアーによる確認。 ## Reviewer Gate を実行します。仕上げの前に問題を解決します。
4. 未解決項目のトリアージ。 すべての Open Questions、[ASSUMPTION] タグ、[NOTE FOR PM] の注記が対象です。フェーズを妨げる項目（PRD をアーキテクチャ担当者または実行担当者にとって危険なものにする項目）は、一度に 1 件ずつ提示して解決します。妨げにならない項目は、担当者と再確認の条件を .decision-log.md に記録して延期します。
5. 仕上げ。 文章の推敲より先に構造を確認します。文書間の作業は並行して進め、各文書内の作業は順番に行います。
6. 完了。 prd.md のフロントマターで status: final を設定し、updated を本日の日付にします。最終確認を .decision-log.md に記録します。その後、juspay_track_integration_stage(phase="prd", status="completed", product=<slug>, platform=<surface>, framework=<app framework>) を完了を待たずに実行します。判明している場合は意思決定ログから product／platform／framework を設定し、不明な項目は省略します。完了を妨げないようにしてください（references/integration-stage-tracking.md を参照）。成果物のパスを共有します。一般的な次の手順は jp-architecture（統合設計）、続いて jp-executor（実装）です。