mcpField
I
integrate

integrate

github.com/sahyll開発059 回インストール21 週間前に更新
リポジトリ

integrate について

Juspay の決済統合を案内するエージェントスキルです。製品選定、プラットフォーム確認、ドキュメント参照、実装、テストを、MCP の加盟店データと進捗管理を組み合わせて進めます。

主な機能

  1. 01MCP による加盟店情報の取得
  2. 02製品カタログに基づく製品選定
  3. 03プラットフォームとコードベースの確認
  4. 04ドキュメントに沿った実装
  5. 05フェーズとタスクの進捗管理
  6. 06認証情報の取り扱い保護

活用シーン

  1. 01Juspay 製品統合の開始
  2. 02指定したステップから統合を再開
  3. 03実装と検証の進捗管理

MCP 対応

ライブの加盟店データには `juspay-mcp`、ドキュメントの構成と内容には `juspay-docs-mcp` を使用します。`juspay-mcp` のツールを使う前に認証が必要です。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sahyll/juspay-skills --skill integrate

インストール後、Claude Code で/integrateを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

products/
ec-api.md
ec-headless.md
hyper-checkout.md
hyper-credit.md
jusbiz.md
juspay-billing.md
lotuspay.md
payout.md
upi-plugin-sdk.md
upi-tpap-sdk.md
scripts/lifecycle/
done
integrate-results
scripts/test/hyper-checkout/
order-status.sh
session.sh

詳細

/integrate — Juspay 統合オーケストレーター

最優先指令： このファイルは判断エンジンです。製品知識は含まれていません。 製品知識は products/ にあります。実装に関する確かな情報は、MCP ツールの呼び出しからのみ取得してください。記憶やトレーニングデータに頼ってはいけません。

MCP の優先事項： ライブの加盟店データ（認証情報、設定、ゲートウェイ設定、統合ステータス）には、常に juspay-mcp ツールを優先して使用してください。juspay-docs-mcp は、ドキュメントの構造とページ内容に限って使用してください。

エージェントのセルフチェック（各フェーズの前に頭の中で確認）

  • PRE-FLIGHT MCP 認証ステップを完了しましたか？まだの場合は、今すぐ mcp__juspay-mcp__authenticate() を実行してください。失敗した場合は、処理を中断し、続行する前にユーザーに認証を依頼してください。
  • 認証情報を尋ねる前に、juspay_get_merchant_details を呼び出して加盟店のコンテキストを確認しましたか？
  • explore_product を呼び出す前に products/ を読みましたか？カタログだけで結論を出せますか？
  • 言語やフレームワークについて確認する質問をする前に、コードベースを調べましたか？
  • コードを書く前に doc_fetch_tool を呼び出しましたか？
  • 記憶ではなく、取得したドキュメントに記載されたメソッド名とフィールド名を使用していますか？
  • SDK／ウェブ製品の場合：チェックリストの各ステージで、可能な限りテスト用リソースを取得し、テストを実行しましたか？

フラグの解析

開始前にフラグを抽出してください。

フラグ効果
--product <id>推奨をスキップします。1 行で製品を確認してから、フェーズ 2 に進みます。それでもステップ 1.7 のカタログ優先チェックは実行してください。
--platform <id>フェーズ 2 でプラットフォームを選択する際のヒントとして使用します。質問する前に、コードベースと照合してください。
--from <step>特定のステップから再開します（エントリーポイントを参照）。タスクリスト全体を作成し、それ以前のステップを完了済みとしてマークしてください。

結果の追跡

各フェーズの開始時と終了時に、scripts/lifecycle/integrate-results を呼び出します。作業開始前に step-start <name> を、検証後に step-end <status> "<verification>" を実行します。これによりフェーズごとの所要時間を正確に記録できます。両方をフェーズ終了時の1回の呼び出しにまとめると、所要時間が0秒として記録されます。

スクリプトのパス（プロジェクトのルートからフルパスで実行します）： .claude/skills/integrate/scripts/lifecycle/integrate-results

コマンド：

  • init — ワークフローのライフサイクルの骨組みを初期化します。init: startedAt=<ts> を出力します。ワークフロー開始時（タスクのシード前）に1回呼び出します。
  • step-start <name> — 各フェーズの冒頭、作業を始める前に呼び出します。pending: <name> を出力します。
  • step-end <status> "<verification>" ["<reason>"] — フェーズの検証後に呼び出します。recorded: <name> <status> (steps=<count>, pending=<none|name>) を出力します。
  • step <name> <status> "<verification>" <startedAt> <completedAt> ["<reason>"] — 開始時刻をシェルで取得したフェーズ向けの単一呼び出し形式です。
  • set <field> <value> — 機密情報以外のメタデータを保存します。set: <field>=<value> を出力します。スクリプトは *key*、*secret*、*password*、*token*（大文字と小文字を区別しない）に一致するフィールドを構造的に拒否します。この制限を回避しようとしないでください。

set に指定できる安全なフィールド： product、platform、productType、merchantId、active、status。

出力を信頼してください。 変更があるたびに、1行の確認メッセージが出力されます。これを書き込み成功の証拠として扱い、確認のために JSON を再読み込みしないでください。

integrate-results または scripts/lifecycle/done が終了コード2で終了し、SKILL_FALLBACK: で始まる行を出力した場合、jq も Python も利用できません。以降の integrate-results 呼び出しはすべて、再試行せずにスキップしてください。DONE フェーズのタイミングの概要もスキップし、次のメッセージを1回だけユーザーに伝えてください。「結果の追跡を利用できません（jq または Python が見つかりません）。フェーズごとの所要時間を有効にするには、いずれかをインストールしてください。統合作業自体は通常どおり進めます。」

STATIC_STEPS（init 時にシードされ、常に存在）： product-select、platform-detect、doc-fetch、params、codegen、test、summary、done

DYNAMIC_STEPS（ワークフローの途中で検出された時点でシード）：

  • Phase 2（プラットフォームの確認）後：{$PLATFORM}-setup（モバイルプラットフォームの場合）、checklist（常に）
  • Step 4.1（webhook の確認）後：webhook-config（webhook URL が未設定で、ユーザーが URL を提供した場合）
  • Phase 5 の DB スキャン後（DB の変更が確定した場合）：db-schema

動的なステップ名はプラットフォーム固有です：react-native-setup、android-setup、ios-setup、flutter-setup、cordova-setup、capacitor-setup。done スクリプトは任意のステップ名を処理するため、スクリプトの変更は不要です。

手順：

  • すべてのフェーズを、冒頭の step-start と末尾の step-end で挟んでください。先行する step-start なしで step-end を呼び出さないでください。自動スキップされるフェーズでは、step-start と step-end skipped を連続して呼び出してもかまいません。
  • タイムスタンプを自分で計算しないでください。integrate-results が内部で UTC を処理します。
  • 検証文字列に認証情報を含めないでください（下記の SECURITY を参照）。

進捗の追跡

エージェントの標準チェックリストまたはタスク追跡 UI を操作して、ワークフロー全体を通じて統合の進捗をユーザーがリアルタイムで確認できるようにします。

ワークフローの開始時（integrate-results init の後、Step 1.1 の前）に、8 つの STATIC_STEPS を 1 回のアシスタントターンで並列にシードします。タスクごとに TaskCreate を 1 回呼び出し、すべてを並列の tool_use ブロックとして出力します。

product-select, platform-detect, doc-fetch, params, codegen, test, summary, done

順次シードするのは後退です。すべての TaskCreate 呼び出しを 1 回のターンで出力してください。

Phase 2 の後（プラットフォーム確認後）： 動的タスクを 1 回の並列バッチでシードします。

  • {$PLATFORM}-setup — $PLATFORM が {android, ios, react-native, flutter, cordova, capacitor} のいずれかの場合
  • checklist — 常にシードします

オンデマンド（後続のフェーズ）：

  • Step 4.1 の Webhook 確認後：URL が未設定で、ユーザーが URL を提示した場合は webhook-config タスクをシードします
  • Phase 5 の DB スキャン確認後：ユーザーがスキーマ変更に同意した場合は db-schema タスクをシードします

各フェーズ境界での状態遷移：

  • step-start が呼び出されたら in_progress に切り替えます。
  • step-end passed が呼び出されたら completed に切り替えます。
  • 一度に in_progress にできるフェーズは 1 つだけです。

自動スキップのルール（これらのフェーズでは step-start と step-end skipped を連続して呼び出し、対応するタスクを直ちに completed にします）：

  • {$PLATFORM}-setup：確認済みプラットフォームでネイティブ SDK のセットアップが不要であることがドキュメントの構成から判断できる場合はスキップします。ドキュメントの構成から判断してください。製品に $PLATFORM 向けのネイティブ／モバイル SDK のページがない場合は、スキップの理由として "not applicable: no native/mobile SDK pages found for $PLATFORM in the doc map" を指定します。ステップには実際に解決されたプラットフォーム名を使用してください（例：step-start web-setup / step-end skipped）。

--from <step> エントリーポイント： 8 つの STATIC_STEPS をシードした後、エントリーポイントより前のすべてのステップをシード直後に completed としてマークします。エントリーポイントより前に作成されるはずだった動的ステップもシードし、直ちに completed としてマークします。

失敗時： フェーズで再試行を使い切ってワークフローが停止した場合、失敗したフェーズは in_progress のままにし、失敗の概要を示した後に done を completed としてマークし、integrate-results set status failed を呼び出します。

セキュリティ

ステップの検証文字列、タスクの説明、Bash コマンドの引数、またはターミナル出力には、以下を絶対に含めないでください。

  • $API_KEY — Step 4.2 で juspay_create_api_key を介して発行されます。エコーしないでください。また、結果ファイルにも保存しないでください。
  • $WEBHOOK_AUTH_PASSWORD — Step 4.4 で .env から読み取ります。同様に、絶対に含めないでください。
  • juspay_create_api_key が返す値
  • .env、.env.local、または同様のファイルから読み取った認証情報

正しい例：

integrate-results step-end passed "API key provisioned and stored in env var; webhook URL configured; return URL set"

誤った例：

integrate-results step-end passed "API key: sk-test-AbCdEf123; webhook=https://..."

integrate-results スクリプトは、set 実行時に機密フィールド名を構造的に拒否します（終了コード 1）。 フィールド名を変更して回避しようとしないでください。

テストスクリプトの実行時（Step 8.2）： 認証情報はインライン引数として Bash ツールの呼び出しコマンド文字列に表示させず、シェル環境変数（export JUSPAY_API_KEY=...）を介して渡してください。

スクリプトまたは MCP ツールの応答に認証情報の値が含まれている場合（例：juspay_create_api_key がプレーンテキストのキーを返す場合）は、メモリ内の変数に保存してください。値を表示せずに、発行されたことをユーザーに伝えてください。

"新しい API キーを作成し、このセッション用に保存しました。"

UI の操作ルール

ユーザーが決まった選択肢から選ぶ必要がある場合は、常に次のルールに従ってください。

  • 標準の選択 UI を使用します
  • 選択肢がわかっている場合、自由入力での回答を求めてはいけません
  • 選択されるまで先に進まないでください
  • 選択肢を表示した後、同じ質問を言い換えて再度尋ねてはいけません
  • 導き出せる情報を尋ねてはいけません — コードベース、juspay-mcp のライブデータ、またはカタログから導き出せる情報が対象です

選択肢はインラインの文章ではなく、構造化された形式で提示してください。

事前確認：MCP 認証

このスキルは、次の2つの MCP サーバーに依存しています。

  • juspay-mcp — ライブの加盟店データ（認証情報、設定、統合ステータス）。ツールを呼び出す前に認証が必要です。
  • juspay-docs-mcp — ドキュメントの構成とページコンテンツ。認証は不要です。
認証フロー

juspay-mcp のツールを呼び出す前に、エージェント環境で利用可能な方法（例：authenticate ツール、OAuth ハンドシェイク、MCP サーバーが提供するログインプロンプト）を使って、認証フローの開始を試みてください。

認証に成功した場合 → 直接フェーズ 1 に進みます。

認証に失敗した場合、ツールが利用できない場合、または環境での認証方法が不明な場合 → まず、リモート MCP サーバーの認証方法について、利用中のエージェントのドキュメント（例：Claude Code のドキュメント、OpenCode のドキュメント、Cursor のドキュメントなど）を確認してください。その後、停止してユーザーに次のように伝えます。

"juspay-mcp サーバーは、この統合を進める前に認証が必要です。

MCP サーバーの認証方法について、利用中のエージェントのドキュメントを確認してから、integrate スキルを再実行してください。"

認証に成功する前に、juspay-mcp のツールを呼び出してはいけません。認証が確認されるまでフェーズ 1 に進まないでください。

フェーズ 1 — インテントの収集と製品の選択

起動時

各フェーズの作業を開始する前に、次の手順を順番どおりに実行します。

  1. integrate-results init — ライフサイクルのスケルトンを初期化します
  2. TaskCreate を8回、1回のアシスタントターン内で並列に呼び出します（PROGRESS TRACKING を参照）
  3. integrate-results set active working

--from <step> が渡された場合、タスクを作成した後、開始点より前のすべてのステップを直ちに completed にします（先行する各ステップについて、step-start / step-end passed "resumed from --from flag" を続けて実行し、その後、対応するタスクを completed に切り替えます）。

実行：integrate-results step-start product-select | product-select タスクを in_progress に切り替えます

ステップ 1.1 — 製品カタログの読み込み

products/ 内のすべてのファイルを読み込みます。各ファイルには、製品 ID、タイプ、プラットフォーム、ユースケース、インテントシグナルが含まれています。

全データを $PRODUCT_CATALOG として保存します。これはマッチングに使用するローカルのナレッジです。製品に関する学習データの知識は使用しないでください。

ステップ 1.2 — 加盟店アカウントから統合タイプを自動判定

次を呼び出します。

juspay-mcp:juspay_get_merchant_details()

次の値を抽出して保存します。

  • $MERCHANT_ID — merchantId フィールドから取得します
  • $CLIENT_ID — 常に $MERCHANT_ID をデフォルト値とします。API レスポンスから取得してはいけません。 ユーザーに次のように伝えます。

    「通常、Client ID は加盟店 ID（$MERCHANT_ID）と同じです。異なる Client ID を使用している場合は、今ここでお知らせください。そうでなければ、$MERCHANT_ID で進めます。」 続行する前に、確認またはカスタム値の提示を待ちます。

  • $INTEGRATION_TYPE — integrationType フィールドから取得します。このフィールドは配列です。最初の要素を使用します（例：["PP"] → "PP"）

$INTEGRATION_TYPE を推奨製品に対応付けます。

$INTEGRATION_TYPE推奨製品 ID
PPhyper-checkout
ec_sdkec-headless
ec_apiec-api
(その他の値または値なし)推定なし — ステップ 1.4 にフォールバックします
ステップ 1.3 — 推定した候補を提示する

マッピングが見つかった場合は、確認を 1 つだけ提示します。

「アカウント設定に基づくと、[Product Name] が設定されているようです。

[Product Name] との統合を進めてもよろしいですか？

  1. はい、進めます
  2. いいえ、別の製品タイプを選択します
  3. いいえ、特定の製品を選択します」
  • オプション 1 → $PRODUCT に推定した製品 ID を設定し、フェーズ 2 に進みます
  • オプション 2 → ステップ 1.4（製品タイプの一覧）に進みます
  • オプション 3 → $PRODUCT_CATALOG の全製品をフラットな一覧で表示し、ユーザーが直接選択できるようにします
ステップ 1.4 — 作成したいものをユーザーに尋ねる

$INTEGRATION_TYPE が存在しない、認識されない、またはステップ 1.3 でユーザーがオプション 2 を選択した場合にのみ実行します。

各エントリーの category フィールドを読み取り、重複のないカテゴリ一覧を作成して、$PRODUCT_CATALOG からカテゴリ一覧を導き出します。カタログに最初に登場する順に、各カテゴリを番号付きオプションとして提示し、最後に わかりません を追加します。

統合したい製品の種類を教えてください。

[$PRODUCT_CATALOG の重複のないカテゴリの番号付きリスト] [N+1]. わかりません

ステップ 1.5 — 製品を選択するようユーザーに尋ねる

$PRODUCT_CATALOG を、category がユーザーの選択と一致するエントリーに絞り込みます。一致する各製品の名前を番号付きの選択肢として提示します。

どの [category] 製品を統合しますか？

[$PRODUCT_CATALOG で category = 選択されたカテゴリの製品の番号付きリスト]

ユーザーが わかりません を選択した場合は、代わりに次のように尋ねます。

ユースケースを説明してください。適切な製品と統合フローをおすすめします。

自由記述の回答を $INTENT として保存し、ステップ 1.6 に進みます。

ステップ 1.6 — インテントを候補に照合する

$INTENT と各 $PRODUCT_CATALOG エントリーの intent signals フィールドを使用して、1～3 個の製品を $CANDIDATES[] として選択します。

照合ルール：

  • 「チェックアウト UI」、「決済ページ」、「モバイル SDK」→ type: sdk の製品を優先します
  • 「API のみ」、「サーバーサイド」、「REST」、「バックエンド」→ type: api-only の製品を優先します
  • 「継続課金」、「サブスクリプション」、「マンデート」→ 請求／マンデート製品
  • 「支払い」、「送金」、「分配」→ 支払い製品
  • 「UPI」、「TPAP」、「P2P」、「P2M」→ UPI 製品

候補は 1～3 個を目標にします。少ないほど望ましいです。

ステップ 1.7 — カタログを優先した製品の特定

explore_product を呼び出す前に、カタログのエントリーだけで結論を出せるか確認します。

カタログのエントリーだけで結論を出せるのは、次の条件を満たす場合です。

  • type フィールドにより、プラットフォームについて質問する必要があるかどうかが明確に判断できる
  • platforms リストのエントリーが 1 つだけ、または製品タイプが api-only（プラットフォームについて質問する必要がない）
  • コード生成を開始するために、これ以上のプラットフォームの判別が必要ない

結論を出せる場合 → この候補について explore_product をスキップして先に進みます。 結論を出せない場合（例：ハイブリッドタイプ、重複するプラットフォームが複数ある、複雑さの指標としてページ数が必要）→ 次を呼び出します。

juspay-docs-mcp:explore_product({ product: <candidate-id> })

おすすめに必要な情報だけを抽出します。

  • 製品タイトル
  • プラットフォーム ID → タイプを分類します（ランタイム ID = sdk、docs のみ = api-only、混在 = hybrid）
  • 番号付きの基本統合ページ数（複雑さの指標）
  • sdk/hybrid の場合、対応プラットフォームの一覧

ここでは個別のドキュメントページを取得しないでください。

ステップ 1.8 — おすすめを提示して確認する

products/ と explore_product から読み取った情報を根拠に、おすすめを提示します。

「説明いただいた内容に基づくおすすめは、次のとおりです。

[Product Title] — [ユーザーのインテントに関連付けた理由を 1 行で記載]

(代替案) [Product Title] — [理由]

どれを統合しますか？ または、以下の全製品一覧から選択してください。」

ユーザーが選択を変更できるよう、$PRODUCT_CATALOG の全製品を番号付きの一覧として表示します。

確認済みの選択を $PRODUCT（products/ ファイルの製品 ID）として保存します。

製品の選択が確定した後：

integrate-results set product $PRODUCT
integrate-results set merchantId $MERCHANT_ID
integrate-results step-end passed "product confirmed: $PRODUCT; merchantId resolved"

product-select タスクを completed に切り替えます。

フェーズ 2 — プラットフォームの検出

実行：integrate-results step-start platform-detect | platform-detect タスクを in_progress に切り替えます

ステップ 2.1 — $DOC_MAP を構築する（explore_product）

ステップ 1.7 で $PRODUCT に対してまだ呼び出していない場合に限り、explore_product を呼び出してください。

すでに呼び出していて $DOC_MAP が設定済みの場合は、ステップ 2.3 に直接進んでください。

それ以外の場合は、次を呼び出します。

juspay-docs-mcp:explore_product({ product: $PRODUCT })

応答全体を読みます。これは正式なドキュメント構成です。以下を抽出して保存します。

  • 製品のタイトルと説明
  • platforms[] — ID とタイトルを含むすべてのプラットフォーム項目
  • 各プラットフォームの sections[] → 各セクションの sectionTitle、pages[]
  • 各ページの pageTitle と md content link の URL

「1. …」「2. …」のように番号が付いたページは、必須の順序で並んだ基本的な統合ページです。この順序をそのまま維持してください。

explore_product が返したドキュメント構成を読み、製品の種類を分類します。プラットフォーム一覧、セクションのタイトル、ページのレイアウトから、製品にクライアント SDK が必要か、API／サーバーサイドのみか、または両方を組み合わせているかを推定します。結果を $PRODUCT_TYPE（sdk | api-only | hybrid）として保存します。

integrate-results set productType $PRODUCT_TYPE
ステップ 2.2 — コードベースからバックエンド言語を検出する

作業ディレクトリ内をスキャンし、バックエンド言語の手がかりを見つけて $DETECTED_LANG として保存します。最初に見つかった明確な一致を使用してください。

見つかった手がかり$DETECTED_LANG
requirements.txt、pyproject.toml、または過半数の *.py ファイルpython
バックエンドの *.ts ファイルを含む tsconfig.jsontypescript
依存関係に express／fastify／koa／hapi／nest を含む package.json、または過半数の *.js ファイルjavascript
go.mod または過半数の *.go ファイルgo
pom.xml、Android 以外のコンテキストでの build.gradle、または過半数の *.java ファイルjava
Gemfile または過半数の *.rb ファイルruby
composer.json または過半数の *.php ファイルphp
*.csproj または過半数の *.cs ファイルcsharp
Cargo.toml または過半数の *.rs ファイルrust

複数の手がかりが一致しない場合は、server/、backend/、api/、またはプロジェクトのルートにある言語ごとのソースファイル数を数え、最多のものを選びます。見つからない場合は $DETECTED_LANG を未設定のままにします（ステップ 4.3 でユーザーに確認します）。

Step 2.2.5 — 単一サイドのコードベースチェック（SDK 製品とハイブリッド製品のみ）

$PRODUCT_TYPE = api-only の場合は、このステップ全体をスキップしてください。 API のみの製品にはクライアント側がないため、この質問は該当しません。

作業ディレクトリをスキャンし、バックエンドとフロントエンドの両方が存在するか確認します。

バックエンドのシグナル：専用の server/、backend/、または api/ ディレクトリ、サーバー側の依存関係（express、fastify、koa、hapi、nest）を含む package.json、app/api/ または pages/api/ ディレクトリを含む Next.js プロジェクト、requirements.txt、pyproject.toml、go.mod、pom.xml、build.gradle（Android 以外のコンテキスト）、Gemfile、composer.json、Cargo.toml、*.csproj。

フロントエンドのシグナル：クライアント側の依存関係（react、vue、angular、svelte、next、nuxt）を含む package.json、プロジェクトルートの index.html、*.jsx / *.tsx / *.vue ファイルを含む src/ ディレクトリ、pubspec.yaml（Flutter）、AndroidManifest.xml または *.xcodeproj（ネイティブモバイル）。

スキャン結果に基づいて $HAS_BACKEND と $HAS_FRONTEND を設定します。

両方が存在する場合 → $SINGLE_SIDE_MODE = false を設定して続行します。

片方だけが見つかった場合 → $SINGLE_SIDE_MODE = true を設定し、存在しない側（"backend" または "frontend"）を $MISSING_SIDE に設定します。その後、続行する前にユーザーに確認します。

"⚠️ このプロジェクトでは [$HAS_BACKEND → "backend" / $HAS_FRONTEND → "frontend"] しか見つかりません。完全な [Product] の統合には通常、両方が必要です。

  • バックエンド — セッションの作成、注文ステータスの確認、Webhook ハンドラー
  • フロントエンド — SDK の初期化と決済 UI

どのように進めますか？

  1. [$FOUND_SIDE] のみで続行 — この側に必要なものを生成します。統合の概要には、公開前に [$MISSING_SIDE] 側で実装が必要な項目をステップごとにまとめたチェックリストを含めます
  2. 中止 — 先に [$MISSING_SIDE] を追加してから、/integrate を再実行する"
  • オプション 1 → $SINGLE_SIDE_MODE = true で続行します
  • オプション 2 → 次のメッセージを表示して、ただちに停止します："問題ありません。プロジェクトに [$MISSING_SIDE] を追加し、準備ができたら /integrate を再実行してください。"

どちらも見つからない場合（空、または見慣れないプロジェクト構成）→ 両方が存在するものとして扱い、続行します。後続フェーズのコードベーススキャンで問題が明らかになります。

$PRODUCT_TYPE に応じて分岐します。

api-only の場合

プラットフォームに関する質問はありません。バックエンドの言語は $DETECTED_LANG から取得します。検出されていない場合にのみ質問します。

integrate-results set platform "api-only"
integrate-results set nativeSdkRequired false
integrate-results step-end passed "api-only product; backend language: $DETECTED_LANG"

platform-detect タスクを completed に変更します。

Wave 2 の動的タスクをシード（並列、1 ターン）：

  • checklist — 常に実行
sdk の場合

コードベースからクライアントプラットフォームを検出し、続行する前にユーザーに確認します。

ステップ 2.3 — コードベースからプラットフォームを検出する

ユーザーに尋ねる前に、作業ディレクトリをスキャンしてプラットフォームを示す情報を探します。

見つかったファイル／パターン検出されたプラットフォーム
pubspec.yamlflutter
依存関係に react-native を含む package.jsonreact-native
依存関係に @capacitor/core を含む package.jsoncapacitor
依存関係に cordova を含む config.xml または package.jsoncordova
build.gradle または AndroidManifest.xml（Flutter／RN／Cordova／Capacitor の情報がない場合）android
*.xcodeproj または Podfile（Flutter／RN の情報がない場合）ios
モバイルフレームワークの情報を含まない package.json、または index.html／.html ファイルweb または iframe-web

確信を持ってプラットフォームを検出できた場合は、あらかじめ選択された候補として提示します。

「プロジェクトは [Platform] アプリだと検出しました（[signal file] が見つかりました）。

[Platform] で進めますか？

  1. はい、[Platform] を使用する
  2. いいえ、別のプラットフォームを選ぶ」

ユーザーが確認した場合は、曖昧さの解消に進みます。オプション 2 を選んだ場合、または該当する情報が見つからなかった場合は、$DOC_MAP にあるプラットフォームの一覧をすべて提示します。

ステップ 2.4 — 曖昧さの解消

プラットフォームの確認後に適用します。

  • Android：Java と Kotlin のどちらかを尋ねます
  • iOS：Swift と Objective-C のどちらか、CocoaPods と SPM のどちらかを尋ねます
  • Web：ドキュメントマップに web と iframe-web の両方がある場合は、どちらのバリアントかを尋ねます

$PLATFORM に保存します。$DOC_MAP を選択したプラットフォームのページに絞り込みます。

integrate-results set platform $PLATFORM
integrate-results set nativeSdkRequired true
integrate-results step-end passed "platform confirmed: $PLATFORM; doc map filtered to platform pages"

platform-detect タスクを completed に切り替えます。

Wave 2 の動的タスクをシードします（並列、1 ターン）：

  • {$PLATFORM}-setup（例：react-native-setup）— 解決済みのプラットフォーム名で TaskCreate を作成します
  • checklist — 常に実行します
hybrid の場合

まず、次のように尋ねます。

「この製品にはバックエンド API とクライアント SDK の両方があります。何が必要ですか？

  1. バックエンド API のみ
  2. クライアント SDK のみ
  3. 両方」

次に、オプション 1 が選択された場合は api-only のパス、オプション 2 が選択された場合は sdk のパス、オプション 3 が選択された場合は両方のパスを順番に進めます。

integrate-results set platform $PLATFORM
integrate-results set nativeSdkRequired <true|false>
integrate-results step-end passed "hybrid product; mode=$MODE; platform=$PLATFORM"

platform-detect タスクを completed に切り替えます。

Wave 2 の動的タスクをシードします（並列、1 ターン）：

  • {$PLATFORM}-setup — $PLATFORM がモバイル（android/ios/react-native/flutter/cordova/capacitor）の場合
  • checklist — 常に実行します

PHASE 3 — ドキュメントの取得

実行：integrate-results step-start doc-fetch | doc-fetch タスクを in_progress に変更

必ず doc_fetch_tool を使用してください。有効な URL に対して MCP が明示的なエラーを返した場合に限り、WebFetch にフォールバックしてください。

juspay-docs-mcp:doc_fetch_tool({ url: "<md content link from $DOC_MAP>" })

取得順：

  1. 前提条件／概要 — 必ず最初に取得します。認証情報、認証形式、バージョン制約が記載されています
  2. 番号付きの基本連携ページ — explore_product に記載された正確な番号順に取得します
  3. Webhook、Order Status API
  4. エラーコード（リソースのセクション）
  5. 詳細セクション — ユーザーから依頼された場合のみ

各ページを読みながら、次の情報を抽出して保存します。

  • $CONSTRAINTS — フィールドごとの構造化テーブル（従来の $PARAMS リストに代わるもの）。見つかったすべてのリクエストフィールド、メソッドパラメーター、コンストラクター引数について、次の情報を記録します。

    • name — ドキュメントに記載された正確なフィールド名
    • type — 宣言された型：String | Integer | Decimal | Boolean | Array | Object
    • required — true | false
    • maxLength — 次のパターンから取得した整数値：「max N chars」、「maximum N characters」、「up to N」、「(max: N)」
    • minLength — 次のパターンから取得した整数値：「min N chars」、「at least N characters」
    • minValue — 次のパターンから取得した数値：「minimum N」、「at least N」、「min: N」、「minimum amount」
    • maxValue — 次のパターンから取得した数値：「maximum N」、「up to N」、「max: N」
    • format — 次のパターンから取得した文字列：ISO 4217、E.164、UUID、YYYY-MM-DD、英数字
    • enumValues — ドキュメントに固定の許可値（「one of: X, Y, Z」または有効値の表）が記載されている場合の文字列配列
    • warnings — このフィールドの項目の近くにあるコールアウトブロック：> **Note:**、> **Important:**、> **Warning:**、> ⚠️、> 💡、**Important** に一致する行
    • errors — このフィールド名を明示的に参照する $ERROR_CODES のエラーコード

  • $CODE_EXAMPLES — ドキュメントに記載された正確なメソッド名、クラス名、キー識別子

  • $ERROR_CODES — すべてのステータス値、エラーコード、失敗理由（コード＋意味＋推奨アクションを含む完全な表）

  • $VERSION_CONSTRAINTS — SDK の最小バージョン、言語／プラットフォームの最小バージョン

  • $WARNINGS — 特定のフィールドに関連しない、全般的な警告／注記のコールアウトブロック

integrate-results step-end passed "fetched $(count) doc pages; $(count) fields in $CONSTRAINTS; $(count) error codes; $(count) warnings"

doc-fetch タスクを completed に変更します。

PHASE 4 — パラメーターの収集

実行：integrate-results step-start params | params タスクを in_progress に変更

ユーザーに伝えます。

"ドキュメントを読みました。必要な情報を収集します。"

Step 4.1 — MCP 経由でマーチャントのコンテキストを自動解決

$MERCHANT_ID、$CLIENT_ID、$INTEGRATION_TYPE は Step 1.2 ですでに取得済みです。これらの値を再利用してください。juspay_get_merchant_details() を再度呼び出さないでください。

必ず次を呼び出します。

juspay-mcp:juspay_get_general_settings()

一般設定から次を抽出します。

  • $RETURN_URL — 設定済みの場合は既存のリターン URL（空でないことを確認）

Webhook の確認 — ドキュメントで必要とされる場合のみ： 取得したドキュメント（Phase 3、doc-fetch）に Webhook のセクションがあるか、Webhook URL の設定をマーチャントに指示しているかを確認します。該当する場合は、次を呼び出します。

juspay-mcp:juspay_get_webhook_settings()

Webhook 設定から次を抽出します。

  • $WEBHOOK_URL — 設定済みの場合は既存の Webhook URL（空でないことを確認）
  • $WEBHOOK_EVENTS — 現在登録されているイベント

ドキュメントに Webhook の記載がない場合は、Webhook の確認と設定を完全にスキップします。

ドキュメントで Webhook が必須とされていて、$WEBHOOK_URL が空または未設定の場合：

まず、既存の Webhook ハンドラー（例：api/juspay/webhook、api/webhook、webhooks ルート）がコードベースにあるかを検索します。存在する場合は、そのパスを $WEBHOOK_PATH として記録します。

動的タスク webhook-config をここでシードします。

TaskCreate({ name: "webhook-config", description: "Configure webhook URL for payment events" })
integrate-results step-start webhook-config

ダッシュボードのドキュメントを取得して、正確なナビゲーションと直接リンクを確認します。次を呼び出します。

juspay-docs-mcp:explore_product({ product: "dashboard" })

explore_product が成功した場合は、タイトルに "Webhook" または "Settings" を含むページを探して取得します。

juspay-docs-mcp:doc_fetch_tool({ url: "<webhook/settings page URL from explore_product result>" })

explore_product が失敗するか結果を返さない場合は、次にフォールバックします。

juspay-docs-mcp:list_products({ category: "DASHBOARD" })

結果からダッシュボードの製品スラッグを選び、その製品に対して explore_product を呼び出してから、該当ページに対して doc_fetch_tool を呼び出します。取得したページを $DASHBOARD_DOCS として保存します。リターン URL の手順で再利用します。 取得したページから以下を抽出します：

  • $WEBHOOK_DOCS_URL — 取得したドキュメントページの URL（参照用）
  • $WEBHOOK_DASHBOARD_NAV — ページに記載されているダッシュボードのナビゲーションパス（例：「Settings → Webhooks」）
  • $WEBHOOK_DASHBOARD_LINK — ページに記載されているダッシュボードへの直接リンク。直接リンクが見つからない場合は空のままにし、ナビゲーション手順を使用します。
  • $WEBHOOK_EVENTS_REQUIRED — この製品で推奨される標準の webhook イベント名

デプロイ済みのベース URL をユーザーに尋ねます（完全な webhook URL の算出に必要です）。

"アカウントに webhook URL が設定されていません。ダッシュボードで設定する値を正確にご案内するため、デプロイ済みのベース URL を入力してください。

まだデプロイ済みの URL がない場合は、ngrok http <port> または cloudflared tunnel を使って、一時的な公開 URL を取得できます。"

ユーザーからベース URL が提供されたら、$CONFIGURED_WEBHOOK_URL = <user-provided base URL> + / + $WEBHOOK_PATH を算出し、設定手順を提示します。

"Juspay ダッシュボードで webhook を設定してください："

設定する URL： $CONFIGURED_WEBHOOK_URL

ナビゲーション： $WEBHOOK_DASHBOARD_NAV (ドキュメントより) 直接リンク： $WEBHOOK_DASHBOARD_LINK (利用可能な場合)

有効にするイベント：

  • $WEBHOOK_EVENTS_REQUIRED の各イベントを列挙

📖 設定ガイド：$WEBHOOK_DOCS_URL

設定を保存したらお知らせください。続きの手順に進みます。"

webhook が設定されたことをユーザーが確認するまで待ちます。確認済みの URL を $WEBHOOK_URL として保存します。

integrate-results step-end passed "webhook URL configured manually via dashboard: $WEBHOOK_URL; navigation instructions provided"

webhook-config タスクを completed に変更します。

$RETURN_URL が空、または未設定の場合：

まず、Juspay のリダイレクトを受け取り、注文ステータスの応答を処理できる既存の return URL ページまたはハンドラーがコードベースにないかスキャンします。見つかった場合は、そのパスを $RETURN_PATH として記録します。

ダッシュボード設定のドキュメントを取得します。 $DASHBOARD_DOCS が上記の webhook 手順ですでに設定されている場合は、それを再利用します。そうでない場合は、次を呼び出します。

juspay-docs-mcp:explore_product({ product: "dashboard" })

一般設定ページを探し、doc_fetch_tool で取得します。explore_product が失敗した場合は、list_products({ category: "DASHBOARD" }) にフォールバックします。

取得したページから以下を抽出します：

  • $SETTINGS_DOCS_URL — 取得したドキュメントページの URL
  • $SETTINGS_DASHBOARD_NAV — 一般設定のナビゲーションパス（例：「Settings → General」）
  • $SETTINGS_DASHBOARD_LINK — 利用可能な場合は、ダッシュボードへの直接リンク

return URL をユーザーに尋ねます。

"アカウントに return URL が設定されていません。決済完了後に顧客をリダイレクトする URL を入力してください。これは、決済の戻り処理および注文ステータスの応答を処理する、アプリ内の実在するルートである必要があります。"

ユーザーから URL が提供されたら、コードベース内の既存のルートまたはハンドラーと一致するか検証します。一致しない場合は、次のように警告します。

"入力された URL は、現在のコードベース内に return ハンドラーとして存在しないようです。この URL を使用してもよろしいですか？"

確認後、設定手順を提示します。

"Juspay ダッシュボードで return URL を設定してください：

設定する URL： <user-provided URL>

ナビゲーション： $SETTINGS_DASHBOARD_NAV (ドキュメントより) 直接リンク： $SETTINGS_DASHBOARD_LINK (利用可能な場合)

📖 設定ガイド：$SETTINGS_DOCS_URL

設定を保存したらお知らせください。"

ユーザーが確認するまで待ちます。確認済みの URL を $RETURN_URL として保存します。

環境は常に本番環境です。 ユーザーに尋ねてはいけません。ドキュメントに記載された本番環境のホスト URL を使用します。

Step 4.2 — API キーの自動プロビジョニング

API キーをユーザーに尋ねてはいけません。代わりに、次を呼び出します。

juspay-mcp:juspay_create_api_key({ description: "integrate-skill-<product>-<date>" })

返された平文の値を $API_KEY としてメモリ内にのみ保存します。ログへの記録、結果ファイルへの保存、出力は決して行わないでください。 ユーザーには次のように伝えます。

"この連携のために、新しい API キーがアカウントに作成されました。"

キーの値をユーザーに表示してはいけません。integrate-results に渡してはいけません。

ステップ 4.3 — 残りの必須パラメーターを収集する

次の順に確認します。

  1. 必須パラメーター — ユーザーが入力する必要のある各必須フィールド（自動生成フィールド、および解決済みのもの（$MERCHANT_ID、$CLIENT_ID、$API_KEY、$WEBHOOK_URL）は除外します）
  2. プラットフォームのバージョン確認（SDK の場合のみ） — ドキュメントに最小バージョンが記載されている場合
  3. バックエンドの言語 — コードベースからまだ特定できていない場合
ステップ 4.4 — バックエンドのベース URL と Webhook 認証情報を解決する

$BACKEND_BASE_URL — コードベースをスキャンして、バックエンドのリッスンポートとベース URL を確認します。

シグナル導出される値
バックエンドの .env または .env.local にある PORT=XXXXhttp://localhost:XXXX
フロントエンドの .env にある EXPO_PUBLIC_API_URL / VITE_API_URL / NEXT_PUBLIC_API_URL値をそのまま使用します
package.json の dev スクリプトにある --port XXXXhttp://localhost:XXXX
docker-compose.yml にある ports: - "XXXX:XXXX"http://localhost:XXXX

確度が高い状態で検出できた場合は、次のように1行で確認します。

"バックエンドを http://localhost:3001 で検出しました（backend/.env: PORT=3001 に基づく）。"

特定できない場合は、次のように質問します。

"バックエンドはどの URL で実行されていますか？（例：http://localhost:3001）"

$BACKEND_BASE_URL として保存します。

$WEBHOOK_AUTH_USERNAME / $WEBHOOK_AUTH_PASSWORD — Webhook ハンドラーが Basic Auth を使用している場合（生成されたコードまたはバックエンドの .env を確認します）、質問するのではなく、.env から値を読み取ります。これらの値はメモリー内にのみ保存します。ログに記録したり、ステップ検証文字列に含めたりしないでください。

サンドボックスに関する注意： ステップ 8.2 のテストスクリプトはローカルのバックエンドを呼び出し、バックエンドは設定済みの認証情報を使用して Juspay の API を呼び出します。Juspay の Dummy PG（シミュレーター）でテストする場合、追加の設定は不要です。テストリソースページ（ステップ 8.3.1 で取得）には、シミュレーターに自動的にルーティングされるテストカードと UPI VPA が記載されています。

integrate-results step-end passed "webhook configured: $WEBHOOK_URL; return URL set; API key provisioned; backend URL: $BACKEND_BASE_URL"

params タスクを completed に切り替えます。

フェーズ 5 — コード生成

実行：integrate-results step-start codegen | codegen タスクを in_progress に切り替えます

ルール：

  • 取得したドキュメントのコード例とメソッド名をベースとして使用します。収集した値を置き換えてください。ドキュメントに記載されていないメソッド名やクラス名は使用しないでください。
  • $INTEGRATION_STAGES（ステップ 5.1）にある、表示可能で無効化されていないすべてのステージに、対応するコードを用意する必要があります。まず重要なステージをカバーしてください。
  • $CONSTRAINTS（フェーズ 3）の制約対象フィールドはすべて、API に渡る前に検証レイヤーを通過させる必要があります。パラメーターを、ドキュメントに記載された制限を迂回させてはいけません。
  • フロントエンド／SDK コードを生成する前に、プラットフォーム固有または統合タイプ固有のコード指示がないか、products/$PRODUCT.md を読み直してください。一致するプラットフォームまたは統合タイプ向けのコードを生成する際は、そのような指示セクションをすべて記載どおりに正確に適用する必要があります。
ステップ 5.1 — 統合ステージを取得する

juspay_integration_monitoring_status を呼び出し、この統合で Juspay が対象としている決済フローを確認します。結果は $INTEGRATION_STAGES となり、フェーズ 3 の $CONSTRAINTS と並んでコード生成を制御する 2 つ目の制約ソースになります。

juspay-mcp:juspay_integration_monitoring_status({
  platform: <$PLATFORM mapped below>,
  product_integrated: <$PRODUCT mapped below>,
  merchant_id: $MERCHANT_ID,
  start_time: <30 days ago in YYYY-MM-DDTHH:MM:SSZ>,
  end_time: <now in YYYY-MM-DDTHH:MM:SSZ>
})

product_integrated のプロダクトマッピング：

$PRODUCTproduct_integrated
hyper-checkoutPayment Page Session
ec-headlessEC + SDK
ec-apiEC Only
(others)Payment Page Session

platform のプラットフォームマッピング：

$PLATFORMplatform
web, iframe-webWeb
androidAndroid
iosIOS
flutter, react-native, cordova, capacitorAndroid
api-only productsBackend

走査パス — レスポンスはネストされているため、次のようにたどります：

queryData.responseData.features
  → each {featureKey}          (e.g., "base")
    → .sections
      → each {sectionKey}      (e.g., "Payments Flow Checklist", "SDK Flow Checklist", "Latency")
        → .stages
          → each {stageKey}    (e.g., "new_card_txn", "upi_collect_txn")

この走査で到達したすべてのステージについて、次の条件を満たす場合は $INTEGRATION_STAGES[] に含めます。

  • visibilityResult === true
  • disableStage === false
  • onlyReportResult === false（レポート専用のステージはコードカバレッジが不要なため、スキップします）

$INTEGRATION_STAGES[] の各エントリーには、次の情報を格納します。

FieldSourceNotes
section{sectionKey}辞書キー。例："Payments Flow Checklist" — これが表示名です
stageKey{stageKey}辞書キー。例："new_card_txn"
stageDisplayNamestage.stageDisplayNameわかりやすい名前。例："New Card"
stageDescriptionstage.stageDescriptionテスト内容
criticalResultstage.criticalResultブール値 — クリティカルなステージは本番稼働の可否を左右します
statusstage.status"PASSED" | "FAILED" | "NOT_ATTEMPTED" — ステップ 8.5 の差分比較用ベースライン

queryData.scoreData も $SCORE_BASELINE として保存します。

  • baseCriticalSuccessCount / baseCriticalTotalCount — 例：4 / 8
  • baseTotalSuccessCount / baseTotalCount — 例：4 / 12

これらのステージが統合の契約です。 $INTEGRATION_STAGES 内のすべてのステージは、以下の手順で対応するコードカバレッジを持つ必要があります。criticalResult: true のステージは、クリティカルでないステージより先にカバーする必要があります。

ステップ 5.2 — $CONSTRAINTS から検証レイヤーを生成する

統合コードを書く前に、$CONSTRAINTS に基づいて検証ヘルパー／関数を生成します。

  • maxLength を持つ各フィールドには、値が上限を超えた場合にエラーをスローまたは返す長さチェックを追加します。インラインコメントとして // docs: max N chars を追加します。
  • minValue を持つ各フィールドには、// docs: min N コメント付きの数値下限チェックを追加します。
  • type = Integer または Decimal の各フィールドでは、正しい型へのキャストを強制します。ドキュメントで数値型と定義されている値に文字列を渡してはいけません。
  • enumValues を持つ各フィールドには、定数セット（列挙型、凍結オブジェクト、またはリテラルユニオン型）を定義し、文字列を直接使わずにそれを参照します。
  • warnings が空でない各フィールドでは、そのフィールドへの代入の前に // ⚠️ WARNING: <warning text> コメントを追加します。

この検証レイヤーは一度だけ記述し、統合コード全体から参照します。

Step 5.3 — SDK の依存関係をインストールする（SDK／ハイブリッド製品のみ）

SDK をインポートするコードを書く前に、ドキュメントで必要とされているパッケージをインストールします。 前提条件／はじめにのページに記載されているパッケージ名とバージョンを正確に使用してください。記載されていないものはインストールしないでください。

プラットフォームコマンド
react-native、cordova、capacitorプロジェクトのルートで npm install <packages>
flutterflutter pub add <packages>
ネイティブ Androidbuild.gradle の dependencies ブロックに追加
ネイティブ iOSPodfile に追加してから pod install を実行

次の順序で生成します。

  1. 認証／認証情報の設定 — 環境変数を使用し、値をハードコードしないでください

  2. コア統合 — API 呼び出しまたは SDK のインストール → 初期化 → 開く → レスポンスハンドラー

  3. Webhook ハンドラー — ドキュメントに Webhook のセクションがある場合。署名検証を含めてください

  4. ステータス検証ユーティリティ — ドキュメントにステータス／注文 API がある場合

  5. DB スキーマ — このフローに厳密に従ってください。すべての手順を完了せずに、スキーマの変更を書いたり提案したりしないでください。

    Step 5.4 — 既存のスキーマを検索する

    コードベース内で、決済または注文に関連する DB 定義を検索します。

    • マイグレーションファイル（migrations/、db/migrate/、*.sql、*.prisma、schema.rb、typeorm/*.entity.*、mongoose モデルファイルなど）
    • order_id、payment_status、transaction_id、amount などのフィールドを含む ORM モデルファイル

    該当するものをすべて $EXISTING_SCHEMAS として収集します。

    Step 5.5 — 検出結果に応じて分岐する

    $EXISTING_SCHEMAS が空でない場合：

    見つかった内容の概要を提示します。

    「決済／注文に関連する既存のスキーマが見つかりました。

    • <file>：<table/model name> — フィールド：<list relevant fields>
    • (それぞれについて繰り返す)

    次のどれを行いますか？

    1. これらを拡張する — 既存のスキーマに Juspay 固有のフィールド（juspay_order_id、payment_status など）を追加する
    2. 別のテーブルを作成する — 既存のテーブルと並行して、新しい juspay_orders テーブルを追加する
    3. DB の変更をスキップする — 注文の関連付けはアプリケーション層のみで処理する」

    選択を待ちます。ユーザーが確認した内容のみ適用します。

    $EXISTING_SCHEMAS が空の場合：

    作成する前に許可を求めます。

    「既存の決済または注文のスキーマは見つかりませんでした。ドキュメントでは、次の情報を保存する必要があります：<$PARAMS と製品のステータス／Webhook ドキュメントから導出したフィールド>

    このための DB スキーマを作成しますか？作成する場合、形式を選択してください。

    1. Raw SQL マイグレーション
    2. Prisma スキーマ
    3. TypeORM エンティティ
    4. Mongoose モデル
    5. スキップ — 手動で処理する」

    選択を待ちます。ユーザーが 1〜4 を選択した場合は、取得したドキュメントに記載されたフィールド名と制約を使用してスキーマを生成します。5 を選択した場合は、完全にスキップします。

    Step 5.6 — 合意したスキーマを生成する

    db-schema 動的タスクを今すぐ開始します（ユーザーが DB の変更を確認済みの場合）：

    TaskCreate({ name: "db-schema", description: "Create/migrate payment schema" })
integrate-results step-start db-schema

    $PARAMS ではなく $CONSTRAINTS と製品の注文／Webhook ドキュメントに記載されたフィールド名、長さ、制約を使用します。$CONSTRAINTS の maxLength 値を列サイズの制約として適用します（例：maxLength: 20 のフィールドには VARCHAR(20) を指定）。ドキュメントに記載されていないフィールドや、ユーザーが要求していないフィールドは追加しないでください。

    integrate-results step-end passed "db schema generated: <table/model name>; N columns; constraints from $CONSTRAINTS applied"

    db-schema タスクを completed に変更します。

  6. エラー処理 — ドキュメントのエラーコードを使用して、さまざまなケースの処理方法を示します

integrate-results step-end passed "code generated: auth setup, core integration, webhook handler, status utility, DB schema; packages installed"

codegen タスクを completed に変更します。

フェーズ 6 — ネイティブ SDK のセットアップ（モバイルプラットフォームのみ）

トリガー条件：$PRODUCT_TYPE が sdk または hybrid で、かつ $PLATFORM が次のいずれかの場合：android、ios、react-native、flutter、cordova、capacitor。

ステップ名は、Wave 2 で設定されたプラットフォーム固有の動的な名前です：{$PLATFORM}-setup（例：react-native-setup、android-setup）。

トリガーされない場合、処理は {$PLATFORM}-setup が Phase 2 で設定されたかどうかによって異なります。

ケース A — タスクが設定されていない（$PRODUCT_TYPE = api-only、または $PRODUCT_TYPE = hybrid で、プラットフォームが web や iframe-web などのモバイル以外の場合）： ライフサイクル呼び出しは不要です。このステップは登録されていません。Phase 7 に進みます。

ケース B — タスクは設定されたが、ネイティブのセットアップが該当しない（$PRODUCT_TYPE = sdk で、プラットフォームが web や iframe-web などのモバイル以外であり、ドキュメントにネイティブ SDK のセットアップが不要と記載されている場合）：

integrate-results step-start {$PLATFORM}-setup
integrate-results step-end skipped "not applicable: $PLATFORM is not a native mobile platform; no native SDK setup required"

{$PLATFORM}-setup タスクを completed に切り替えます。Phase 7 に進みます。

実行：integrate-results step-start {$PLATFORM}-setup | {$PLATFORM}-setup タスクを in_progress に切り替えます

ルール：このフェーズのすべての操作は、Phase 3 で取得したドキュメントに基づきます。手順を創作しないでください。

ステップ 6.1 — ドキュメントからネイティブのセットアップ要件を抽出する

Phase 3 で取得済みのページ（Prerequisites / Overview / Getting Started、および「Android Setup」や「iOS Setup」という名前のセクション）を再確認し、次の項目を抽出します。

  • $NATIVE_PACKAGES — インストールするパッケージ／依存関係（npm/pub/gradle/cocoapods）
  • $BUILD_TOOL_CHANGES — ビルド設定ファイル（build.gradle、pubspec.yaml など）に必要な編集
  • $PLATFORM_CONFIG_FILES — 作成が必要な設定ファイル（SDK 認証情報を含む *.txt や *.json など）
  • $POST_INSTALL_SCRIPTS — パッケージのインストール後に実行するスクリプト（Podfile のフック、アセット統合スクリプトなど）
  • $PREBUILD_REQUIRED — ネイティブディレクトリにアクセスする前に、prebuild／generate／sync ステップが必要かどうか

ドキュメントのセクションに「Android Setup」または「iOS Setup」と明記されている場合、その内容全体を該当プラットフォームに関する確定情報として扱い、記載されている手順を省略しないでください。

ステップ 6.2 — プロジェクト構成を確認する

コマンドを実行する前に、コードベースからプロジェクトのワークフローを判定します。

シグナルワークフロー
"expo" キーを含む app.json があり、android/ または ios/ ディレクトリがないExpo managed — ネイティブディレクトリの生成が必要
android/ と ios/ があるBare / native — prebuild は不要
pubspec.yamlFlutter — Flutter ツールチェーンを使用
config.xmlCordova — cordova platform add を使用
capacitor.config.*Capacitor — npx cap sync を使用

ネイティブディレクトリがまだ存在しない managed ワークフローの場合は、$PREBUILD_REQUIRED が true であるか、フレームワークで必須とされている場合に限り、フレームワークの generate／sync コマンド（Expo managed の場合は npx expo prebuild、Capacitor の場合は npx cap sync、Flutter の場合は flutter pub get など）を実行します。ネイティブディレクトリがすでにあるリポジトリでは、破壊的な generate コマンドを決して実行しないでください。

ステップ 6.3 — ビルドツールの変更を適用する

$BUILD_TOOL_CHANGES の各項目について、次の操作を行います。

  • まず対象ファイルを読み取ります。
  • Edit ツールを使って変更を適用します（shell の sed/awk は使用しません）。これにより差分を確認できます。
  • 冪等性を確認します。値がすでに存在する場合は、変更を省略します。
ステップ 6.4 — プラットフォーム設定ファイルを作成する

$PLATFORM_CONFIG_FILES の各項目について、次の操作を行います。

  • Write ツールを使ってファイルを書き込みます。
  • $CLIENT_ID、$MERCHANT_ID、または Phase 4 で解決したその他の認証情報を代入します。
ステップ 6.5 — インストール後スクリプトの実行と依存関係の同期

$POST_INSTALL_SCRIPTS の各項目について：

  • Bash 経由で実行します。
  • stdout/stderr を取得します。終了コードが 0 以外の場合は、エラーを読み取り、原因を調査して修正し、再実行します。
  • このステップが終了コード 0 で完了するまで、次のステップに進まないでください。
ステップ 6.6 — サマリーテーブル

ステップを記録する前に、結果を報告します。

## Native SDK Setup Complete

| Step | Action | Result |
|------|--------|--------|
| packages installed | <names from docs> | ✅ / ❌ |
| prebuild / generate | <command, or "skipped — dirs existed"> | ✅ / skipped / ❌ |
| build config patched | <files changed> | ✅ / ❌ |
| config files created | <files created> | ✅ / ❌ |
| post-install scripts | <commands run> | ✅ / ❌ |

❌ の行には、取得したエラー出力と試みた修正を含める必要があります。

integrate-results step-end passed "{$PLATFORM}-setup complete: packages installed, build configs patched, config files created, post-install scripts run"

{$PLATFORM}-setup タスクを completed に変更します。

フェーズ 7 — チェックリストとエラーリファレンス

checklist は、Wave 2（Phase 2、platform-detect の後）で動的タスクとして登録されています。ここで in_progress に変更します。

実行：integrate-results step-start checklist | checklist タスクを in_progress に変更

チェックリスト

実際に取得した情報をもとにチェックリストを作成します。各項目は、この製品のドキュメントに実在する内容を反映する必要があります。

## Integration Checklist — [Product] on [Platform or API]

### Credentials
- [ ] [credential from docs] stored as env var
- [ ] API key generated via dashboard or juspay-mcp

### [Backend / API]
[items derived from API doc pages]

### [Frontend / SDK] (if applicable)
[items derived from SDK doc pages]

### Testing
- [ ] Successful sandbox transaction
- [ ] Error case from $ERROR_CODES tested
- [ ] Webhooks verified end-to-end

### Integration Stages (from Juspay)

`$INTEGRATION_STAGES` was already fetched in Step 5.1 — render it directly, no second MCP call needed here.

For each stage in `$INTEGRATION_STAGES`, emit:

```
### [stage.section]   ← the section dict key is the display name, e.g. "Payments Flow Checklist"

- [ ] **[stage.stageDisplayName]** ⚠️ Critical ← only if stage.criticalResult is true
      [stage.stageDescription]
```

- Do **not** show `status` — it reflects past activity, not a live gate; developers check stages off as they test
- Mark stages where `criticalResult: true` as ⚠️ Critical
- Group stages by `stage.section` (the section dict key)

### Go-Live
- [ ] Switched to production environment and keys
- [ ] Production end-to-end test passed
パラメーターの制約

$CONSTRAINTS 内で、少なくとも1つの制約列が null ではないフィールドについてのみ、このテーブルを出力します。一覧を見やすくするため、制約のないフィールドは省略します。

## Parameter Constraints

| Field | Type | Required | Max Length | Min Value | Format | Warnings |
|-------|------|----------|------------|-----------|--------|---------|
[one row per constrained field from $CONSTRAINTS — populate only non-null columns; use — for nulls]
エラーリファレンス
## Error Codes

| Code / Status | Meaning | Recommended action |
|---------------|---------|-------------------|
[from $ERROR_CODES]
次のステップ

基本的なインテグレーションの対象外だった $DOC_MAP のセクションについて、さらに詳しく確認できることを簡潔に案内します。ただし、ドキュメントマップで実際に確認した内容のみを挙げてください。

integrate-results step-end passed "checklist generated from docs; $(count) integration stages from monitoring API; error reference table built"

checklist タスクを completed に変更します。

フェーズ 8 — ライブテスト

実行：integrate-results step-start test | test タスクを in_progress に変更

必ずサーバーの実行を試み、インテグレーションを自分でテストしてください。可能な場合は、ユーザーに手動テストを指示しないでください。

ステップ 8.1 — 開発サーバーの起動

コードベースを調べて起動コマンドを確認します。

シグナルコマンド
"dev" スクリプトを含む package.jsonnpm run dev（または yarn dev）
pubspec.yaml実行不可 — ステップ 8.3 に進む
モバイル専用プロジェクト（ウェブサーバーなし）実行不可 — ステップ 8.3 に進む

サーバーを起動する前に、次を呼び出します。

integrate-results set active waiting

サーバーをバックグラウンドで実行し、起動を待ってから、次を実行します。

integrate-results set active working

重要： Vite/Node では、シェルの環境変数が .env ファイルより優先されます。サーバーを起動する前に、必須の環境変数（例：JUSPAY_API_KEY）がすでにシェルに設定されており、プロジェクトの .env と競合しないか確認してください。このプロジェクトに属さない変数は unset してください。

ステップ 8.2 — バックエンド API テストの実行

製品ファイル（products/$PRODUCT.md）に ## Test Scripts セクションが定義されている場合は、ステップ 8.2.2 と 8.2.3 でそのスクリプトを使用します。正確な実行方法、引数、検証条件はそこに記載されています。各スクリプトは HTTP ステータス、レスポンス本文、明示的な ✅ / ❌ を出力します。スクリプトがゼロ以外の終了コードを返した場合は、出力を読み、根本原因（誤った環境変数、不正なヘッダー、型の不一致、サーバーログ）を特定して修正し、合格するまで再実行します。

製品固有のテストスクリプトが定義されていない場合は、$SESSION_ENDPOINT と $ORDER_STATUS_ENDPOINT に対してインラインの curl を使用し、ステップ 8.2.2 と 8.2.3 をテストします。

セキュリティ：認証情報はコマンド文字列に直接記述せず、エクスポートした環境変数を介してテストスクリプトに渡してください。

export JUSPAY_API_KEY="$API_KEY"  # set in env, do not inline in command

ステップ 8.2.1 — テストパラメーターの生成

次の値を自動生成します。ユーザーに尋ねないでください。

  • TEST_ORDER_ID = test-$(date +%s)（実行ごとに一意）
  • TEST_AMOUNT = 1.00
  • TEST_CUSTOMER_ID = test-customer-001
  • TEST_CUSTOMER_EMAIL = [email protected]
  • TEST_CUSTOMER_PHONE = 9999999999
  • TEST_FIRST_NAME = Test、TEST_LAST_NAME = User
  • FAIL_ORDER_ID = fail-$(date +%s)（失敗ケースの Webhook テスト用の別 ID）

生成したバックエンドルートと $BACKEND_BASE_URL からエンドポイント URL を導出します。

  • SESSION_ENDPOINT = $BACKEND_BASE_URL + セッションルート（例：/api/juspay/session）
  • ORDER_STATUS_ENDPOINT = $BACKEND_BASE_URL + 注文ステータスルートのプレフィックス（例：/api/juspay/order-status）
  • WEBHOOK_ENDPOINT = $BACKEND_BASE_URL + Webhook ルート（例：/api/juspay/webhook）

ステップ 8.2.2 — セッション作成

製品ファイルの ## Test Scripts セクション（定義されている場合）に記載されたセッションテストを実行するか、インラインの curl を使用して、ステップ 8.2.1 のテストパラメーターを指定し、$SESSION_ENDPOINT に POST します。

ステップ 8.2.3 — 注文ステータス

製品ファイルの ## Test Scripts セクション（定義されている場合）に記載された注文ステータステストを実行するか、インラインの curl を使用して $ORDER_STATUS_ENDPOINT/$TEST_ORDER_ID に GET します。

ステップ 8.2.4 — Webhook テスト（インライン curl）

Webhook テストでは、ペイロードの構造とイベント名が製品によって異なるため、インラインの curl を使用します。両方ともフェーズ 3 で取得したドキュメントの Webhook セクションから導出します。

# SUCCESS — credentials passed via env, not inline
curl -s -w "\n%{http_code}" -X POST "$WEBHOOK_ENDPOINT" \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(printf '%s:%s' "$WEBHOOK_AUTH_USERNAME" "$WEBHOOK_AUTH_PASSWORD" | base64)" \
  -d '<payload constructed from docs — substitute $TEST_ORDER_ID and $TEST_JUSPAY_ORDER_ID>'

次をアサートします：HTTP 200、かつ本文に {"status":"ok"} が含まれていること、かつ DB の行で payment_status がドキュメントに記載された成功ステータスであること。

$FAIL_ORDER_ID を使用して失敗イベントタイプでも同じテストを繰り返します（最初に test-session.sh でセッションを作成します）。

次をアサートします：HTTP 200、かつ DB の行で payment_status がドキュメントに記載された失敗ステータスであること。

ステップ 8.2.5 — 制約の境界ケーステスト（インライン curl）

maxLength、minValue、または type が定義されている $CONSTRAINTS の各フィールドについて、境界テストを 1 つ生成します。バックエンド API リクエストに含まれるフィールドのみをテストします（クライアント専用の SDK フィールドは対象外です）。

  • maxLength テスト：フィールドに maxLength + 1 文字ちょうどの値を指定して送信します → そのフィールドに対してドキュメントで指定されたエラーコードを期待します（$CONSTRAINTS[field].errors を参照）。HTTP 4xx、かつレスポンス本文に期待されるエラーコードが含まれていることをアサートします。
  • minValue テスト：フィールドに minValue - 1 の値を指定して送信します → ドキュメントで指定されたエラーを期待します。HTTP 4xx、かつ本文に期待されるエラーコードが含まれていることをアサートします。
  • type テスト：type = Integer または Decimal のフィールドに文字列を指定して送信します → ドキュメントで指定されたエラーを期待します。HTTP 4xx、かつ本文に期待されるエラーコードが含まれていることをアサートします。
  • enumValues テスト：enumValues に含まれない値を指定して送信します → 拒否されることを期待します。HTTP 4xx をアサートします。

ステップ 8.4 の表では、タイプを Constraint として報告します。

ステップ 8.3 — フロントエンド／SDK テスト

このステップは $PRODUCT_TYPE = sdk または $PRODUCT_TYPE = hybrid の場合に適用されます。

ステップ 8.3.1：テスト認証情報の取得（すべての SDK／hybrid 製品）

juspay-docs-mcp:doc_fetch_tool({ url: "<test-resources md content link from $DOC_MAP>" })

次を抽出します。

  • $TEST_CARDS — Dummy PG／シミュレーター用のカード番号、有効期限、CVV
  • $TEST_UPI_VPA — UPI の成功／失敗テスト用の VPA 値（例：success@upi、failure@upi）
  • $DUMMY_PG_FLOWS — シミュレーターで各決済方法の成功と失敗を発生させる方法

ステップ 8.3.2：プラットフォーム別の分岐

Web / iframe-web

統合チェックリストの各ステージ（New Card、UPI Collect、UPI Intent、Wallet など）は、ホストされた決済ページを通じて実際の取引が行われた場合にのみ、Juspay のサーバーに登録されます。各ステージで次の操作を行います。

  • セッションのレスポンスに記載された決済ページの URL に移動します
  • $TEST_CARDS / $TEST_UPI_VPA を使用して取引を完了します
  • コールバック／リダイレクト先が $RETURN_URL であることを確認します
  • 決済ページがヘッドレスブラウザーをブロックする場合や CAPTCHA を必要とする場合は、その旨を明記します。黙ってスキップしてはいけません
Mobile（react-native、flutter、android、ios、cordova、capacitor）

SDK の UI はデバイス／エミュレーター上で動作し、CLI から操作できません。ガイドを提示する前に、この点を明記します。

「バックエンドテスト（Step 8.2）は完了しています。クライアント側 SDK は、デバイスまたはエミュレーターで手動確認する必要があります。」

$TEST_CARDS、$TEST_UPI_VPA、$DUMMY_PG_FLOWS、および Phase 7 チェックリストの統合ステージを使用して、すぐに実行できる手動テストガイドを作成します。

## Manual SDK Test Guide

### Setup
- Build and install: `npx expo run:android` / `npx expo run:ios` / `flutter run` / etc.
- Backend must be running at: $BACKEND_BASE_URL

### Test flows

| # | Flow | Test input | Expected result |
|---|------|------------|-----------------|
| 1 | New Card — success | [success card from $TEST_CARDS] | Payment succeeds, app shows success |
| 2 | New Card — failure | [decline card from $TEST_CARDS] | Payment fails, error shown gracefully |
| 3 | UPI Collect — success | [success VPA from $TEST_UPI_VPA] | UPI request sent, payment succeeds |
| 4 | UPI Collect — failure | [failure VPA from $TEST_UPI_VPA] | Failure handled gracefully |
| 5 | Back / cancel | Tap hardware/software back on payment screen | App returns to checkout, no order corruption |
| [other stages from Phase 7 checklist] | | | |

### After each test
- DB: verify `payment_status` updated (via webhook)
- App: success/failure screen matches the payment outcome
Step 8.4 — 結果を報告する

すべてのテスト後に、統一された合否テーブルを報告します。

| Test | Type | Result |
|------|------|--------|
| POST {session endpoint} → sdkPayload + DB row | Backend | ✅ / ❌ |
| GET {order-status endpoint} → status field | Backend | ✅ / ❌ |
| POST {webhook endpoint} <success event> → DB updated | Backend | ✅ / ❌ |
| POST {webhook endpoint} <failure event> → DB updated | Backend | ✅ / ❌ |
| {field} maxLength exceeded → {expected error code} | Constraint | ✅ / ❌ / — |
| {field} below minValue → {expected error code} | Constraint | ✅ / ❌ / — |
| {field} wrong type → {expected error code} | Constraint | ✅ / ❌ / — |
| New Card — success | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |
| New Card — failure | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |
| UPI Collect — success | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |
| UPI Collect — failure | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |
| [other stages from Phase 7] | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |

— = このカテゴリに制約テスト可能なフィールドが見つかりませんでした。Constraint の行は、制約のあるフィールドごとに 1 回展開されます。

⏭ = CLI から自動化できません。Step 8.3.2 で手動テストガイドを提示しています。

自動テストを完了できない場合（決済ページがヘッドレス環境をブロックする、CAPTCHA があるなど）は、その理由を明記します。合格と黙って記載してはいけません。

integrate-results set active working
integrate-results step-end passed "backend tests: session ✅ order-status ✅ webhook-success ✅ webhook-failure ✅; SDK: manual guide provided"
Step 8.5 — 統合ステージを確認する

Step 5.1 と同じ引数で juspay_integration_monitoring_status を再度呼び出し、テストのアクティビティが加盟店アカウントに記録されたことを確認します。

juspay-mcp:juspay_integration_monitoring_status({
  platform: <same mapping as Step 5.1>,
  product_integrated: <same mapping as Step 5.1>,
  merchant_id: $MERCHANT_ID,
  start_time: <30 days ago in YYYY-MM-DDTHH:MM:SSZ>,
  end_time: <now in YYYY-MM-DDTHH:MM:SSZ>
})

Step 5.1 と同じ探索経路をたどり、各 stageKey の status を $INTEGRATION_STAGES のベースラインと比較します。また、新しい queryData.scoreData を $SCORE_BASELINE と比較します。

差分テーブルを報告します。$INTEGRATION_STAGES の各ステージにつき 1 行を記載します。

## Integration Stage Confirmation

| Stage | Section | Critical | Before | After | Change |
| ----- | ------- | -------- | ------ | ----- | ------ |
| [stageDisplayName] | [section] | ⚠️ / — | [baseline status] | [new status] | ✅ / ⚠️ / ❌ |
  • Before / After の値：PASSED | FAILED | NOT_ATTEMPTED
  • Change 列：
    • ✅ — ステータスが PASSED に変化しました（以前は NOT_ATTEMPTED または FAILED）
    • ⚠️ — ステータスに変化はありません
    • ❌ — ステータスが後退しました（以前は PASSED で、現在は FAILED または NOT_ATTEMPTED）

テーブルの下にスコアの差分を表示します。

Critical stages: [new baseCriticalSuccessCount] / [baseCriticalTotalCount] passing
                 (was [baseline baseCriticalSuccessCount] / [baseCriticalTotalCount])
All stages:      [new baseTotalSuccessCount] / [baseTotalCount] passing

テスト後も重要なステージ（criticalResult: true）が NOT_ATTEMPTED または FAILED の場合は、リリース前の阻害要因として指摘します。

「⚠️ ステージ [stageDisplayName] は重要なステージですが、まだ合格していません。リリース前に解決する必要があります。」

test タスクを completed に切り替えます。

PHASE 9 — 統合の概要

実行：integrate-results step-start summary | summary タスクを in_progress に切り替えます

この統合作業で加えたすべての変更について、開発者向けの永続的な概要を作成します。このファイルは、今後の開発者が追加内容、設定内容、統合に関して想定されることを確認できる唯一の場所です。

Step 9.1 — 概要ディレクトリを特定または作成する

プロジェクトのルートで既存のドキュメントまたはメモ用ディレクトリを、次の優先順位で検索します。

ルートで見つかったディレクトリ書き込み先
docs/ が存在するdocs/juspay-integration/
memory-bank/ が存在するmemory-bank/juspay-integration/
notes/ が存在するnotes/juspay-integration/
上記のいずれも存在しないプロジェクトルートの juspay-integration/

選択したディレクトリが存在しない場合は作成します。ファイル名は [product]-[YYYY-MM-DD].md とします（例：hyper-checkout-2026-05-25.md）。以前の実行で同名のファイルがすでに存在する場合は、上書きせず、連番のサフィックス（-2、-3、…）を付けます。

ステップ 9.2 — サマリーファイルを作成する

Write ツールを使ってファイルを作成します。このワークフローの実行中に実際に行った内容に基づいて、各セクションを記入してください。変更がなかったセクションは省略します。行を捏造してはいけません。

# Juspay Integration Summary — [Product] on [Platform or API]

**Date:** [YYYY-MM-DD]  
**Merchant ID:** [MERCHANT_ID]  
**Docs base:** [first page URL from $DOC_MAP, for reference]

---

## Environment Variables

Variables added to `.env` or `.env.local` during this integration (names only — never values).

| Variable                            | File | Purpose                     |
| ----------------------------------- | ---- | --------------------------- |
| JUSPAY_API_KEY                      | .env | API authentication          |
| JUSPAY_MERCHANT_ID                  | .env | Merchant account identifier |
| JUSPAY_CLIENT_ID                    | .env | SDK client identifier       |
| JUSPAY_WEBHOOK_USERNAME             | .env | Webhook Basic Auth username |
| JUSPAY_WEBHOOK_PASSWORD             | .env | Webhook Basic Auth password |
| [any others written during codegen] |      |                             |

---

## API Routes Created / Modified

| Method | Path | File | Description |
| ------ | ---- | ---- | ----------- |

[one row per route generated in Phase 5 — e.g., POST /api/juspay/session, GET /api/juspay/order-status/:orderId, POST /api/juspay/webhook]

---

## Database Changes

| Change | Table / Model | Migration file | Columns added / modified |
| ------ | ------------- | -------------- | ------------------------ |

[one row per table or model created or altered in Phase 5 DB work]

---

## Order / Payment Status Mapping

Juspay statuses mapped to app-internal statuses in the webhook handler and order-status utility.

| Juspay status | App status | Mapped in |
| ------------- | ---------- | --------- |

[rows derived from status values used in the generated webhook handler and order-status code]

---

## Frontend Routes / Pages

| Route | File | Description |
| ----- | ---- | ----------- |

[rows for any frontend pages, redirect handlers, or return-URL routes created in Phase 5]

---

## SDK / Packages Installed

| Package | Version pinned | Platform |
| ------- | -------------- | -------- |

[rows from packages installed in Step 5.3 or Phase 6 — names and versions from the docs]

---

## Config Files Created or Modified

| File | Change type | Notes |
| ---- | ----------- | ----- |

[rows for build configs, platform config files, .env, gradle files, Podfile, pubspec.yaml, etc. touched during the integration]

---

## Webhook Configuration

| Setting           | Value                                                                           |
| ----------------- | ------------------------------------------------------------------------------- |
| Webhook URL       | [WEBHOOK_URL]                                                                   |
| Events subscribed | [comma-separated list of event names where value is true in the updated config] |

---

## Return URL

[RETURN_URL]

---

## Other-Side TODO _(only present when `$SINGLE_SIDE_MODE = true`)_

> This section is written **only** when Step 2.2.5 detected a single-side codebase and the user chose to continue with one side. Omit it entirely if both sides were present.
>
> **Do not hardcode any steps here.** Every checklist item must be derived from the docs fetched in Phase 3. Walk `$DOC_MAP` for `$MISSING_SIDE`-facing sections (e.g. sections labelled "Backend", "Server", "API" if `$MISSING_SIDE = backend`; sections labelled "Frontend", "Client", "SDK", platform names if `$MISSING_SIDE = frontend`). For each page in those sections, extract the required actions and emit one checklist item per distinct action, using the exact names from `$CODE_EXAMPLES` and `$CONSTRAINTS`.

### What must be implemented on the [$MISSING_SIDE] before go-live

[One checklist item per required action from the $MISSING_SIDE-facing doc sections in $DOC_MAP. Group items under the same section headings used in the docs. Use exact method/field/file names from $CODE_EXAMPLES and $CONSTRAINTS — no invented names.]

---

## Notes

[Non-obvious decisions, workarounds, known caveats, or anything a future developer would need to know. Do not include credential values. Examples: why a particular status mapping was chosen, a version constraint from the docs, a quirk of the SDK init flow, etc.]

integrate-results step-end passed "summary written to [path]; N env vars, N routes, N DB changes, N status mappings documented"

該当するカテゴリで変更がなかった場合は、そのセクションを空のままにしてください（例：この製品のドキュメントで環境変数が不要だった場合、「なし」と記載するのではなく、「環境変数」セクション自体を省略します）。

summary タスクを completed に切り替えます。

エントリーポイント

ID開始位置ユースケース
defaultproduct-select一からの完全な統合
--from doc-fetchdoc-fetchドキュメントを再取得（例：製品／プラットフォームの変更後）
--from codegencodegenコードを再生成（ドキュメントは取得済み）
--from testtestライブテストのみを再実行
--from summarysummary統合サマリーのみを再作成

--from <step> を使用する場合は、8 つの STATIC_STEPS と、エントリーポイントより前に生成されていた動的ステップ（例：React Native プロジェクトで --from codegen を指定した場合は、react-native-setup と checklist も含む）をシードします。エントリーポイントより前のすべてのステップを、直ちに completed としてマークします（step-start / step-end passed "resumed from --from flag" を連続して実行します）。

完了

実行：integrate-results step-start done | done タスクを in_progress に切り替えます

所要時間のサマリー

所要時間のサマリースクリプトを実行します。

.claude/skills/integrate/scripts/lifecycle/done

次の内容が出力されます。

  1. Markdown の所要時間テーブル（ステップ、ステータス、所要時間、検証）。合計時間の 30% 以上かかったステップは太字になります。
  2. 合計実時間の行。
  3. **最も時間のかかったステップ**: の行。
  4. 機械可読データ（totalSeconds、slowestStep、dominantSteps、skippedSteps、failedSteps、product、platform、productType）を含む <<<FACTS ... FACTS ブロック。

テーブルをユーザーに表示します。所要時間を自分で計算してはいけません。

最適化の提案

FACTS ブロックを読み取り、実際の所要時間に基づいて具体的な提案を 2～3 件作成します。

  • doc-fetch の所要時間が大きい場合：コードの再生成のみを行う再実行では --from codegen を提案します
  • test が失敗した場合：失敗したテストと、修正後に --from test で再実行する方法を記載します
  • {platform}-setup に時間がかかった場合：該当するビルドステップを記載し、再実行では --from codegen を提案します
  • params に時間がかかった場合：ユーザーとのやり取りがボトルネックだったことを示します。次回は --product <id> --platform <id> を指定して検出を省略するよう提案します
  • product-select と platform-detect の所要時間が大きい場合：再実行を速くするため、--product <id> フラグを提案します

一般的な助言ではなく、今回の実行データに即した具体的な提案にしてください。

完了
integrate-results set status completed    # or "failed" if any phase failed without recovery
integrate-results set active false
integrate-results step-end passed "integration complete: $PRODUCT on $PLATFORM; timing table printed"

done タスクを completed に切り替えます。

completed にするには、すべてのステップが passed または skipped である必要があります。failed のステップがある場合は、必ず completed の妨げになります。その場合は、代わりに integrate-results set status failed を実行します。

ツール呼び出しのリファレンス

タイミングツール目的
Step 1.1Read products/*.md意図のマッチングに使用する製品概要を読み込みます
Step 1.2juspay_get_merchant_details()加盟店 ID、クライアント ID、インテグレーションタイプを自動解決し、推奨製品を推定します
Step 1.7explore_product(candidate-id)推奨する前に、タイプとプラットフォームを調査します
Step 2.1explore_product($PRODUCT)ドキュメントの全体構成とページ URL を取得し、製品タイプを分類します
Phase 3doc_fetch_tool(url)個々のドキュメントページを取得し、タイプ、maxLength、minValue などを含む $CONSTRAINTS テーブルを作成します
Step 4.1juspay_get_webhook_settings()Webhook URL がすでに設定されているか確認します
Step 4.1juspay_get_general_settings()リターン URL がすでに設定されているか確認します
Step 4.1explore_product("dashboard")優先：ダッシュボードのドキュメント構成を取得し、Webhook／設定ページを特定します
Step 4.1doc_fetch_tool(url)ダッシュボード製品の Webhook ページまたは一般設定ページを取得し、$DASHBOARD_DOCS として保存します
Step 4.1list_products({ category: "DASHBOARD" })explore_product("dashboard") が失敗した場合の代替手段：正しいダッシュボード製品のスラッグを特定します
Step 4.2juspay_create_api_key(...)新しい API キーを発行します。メモリ内にのみ保存し、ログや結果ファイルには決して保存しません
Step 5.1juspay_integration_monitoring_status(...)インテグレーションのステージ契約を $INTEGRATION_STAGES に取得します。コード生成で対応すべきフローを決定します
Step 8.5juspay_integration_monitoring_status(...)テスト後に再度呼び出し、ステージのアクティビティが記録されたことを確認します。$INTEGRATION_STAGES のベースラインとの差分を確認します
Step 5.2(code output)$CONSTRAINTS から検証レイヤーを出力します。API 呼び出し前に長さ／値／型をチェックします
Step 5.3BashSDK パッケージ（npm/flutter/gradle/pod）をインストールします。パッケージ名とバージョンはドキュメントから取得します
Phase 6Bashprebuild/generate/sync を実行し、インストール後のスクリプトを実行します。手順はドキュメントから導き出します
Phase 6Edit / Writeビルド設定ファイルを修正するか、プラットフォーム設定ファイルを作成します。内容はドキュメントから導き出します
Step 4.4Bash / Read.env / package.json から $BACKEND_BASE_URL を検出し、Webhook 認証情報を読み取ります
Step 8.2Bash (product test scripts or inline curl)セッションエンドポイントに POST し、HTTP 200、製品固有のレスポンスフィールド、DB 行を検証します
Step 8.2Bash (product test scripts or inline curl)注文ステータスエンドポイントに GET し、HTTP 200 とステータスフィールドを検証します
Step 8.2Bash (inline curl)合成 Webhook イベントを POST します。ペイロードはドキュメントから取得し、HTTP 200 と DB の更新を検証します
Phase 9Bash / Read概要ディレクトリ（docs/、memory-bank/、notes/、またはプロジェクトルート）を検出します
Phase 9Write環境変数、ルート、DB の変更、マッピングを含む juspay-integration/[product]-[date].md を書き込みます
Startupintegrate-results initライフサイクルの骨組みを初期化します
Each phaseintegrate-results step-start/step-end時間計測の精度を保つため、各フェーズの開始と終了を記録します
Metadataintegrate-results set製品／プラットフォーム／製品タイプ／加盟店 ID を保存します。認証情報は保存しません
Done/scripts/lifecycle/done時間計測テーブルと FACTS ブロックを生成します
Fallback onlyWebFetch有効な URL に対して doc_fetch_tool がエラーを返した場合に限り使用します
ドキュメントの URL を独自に作成しないでください。 すべての URL は、explore_product のレスポンスに含まれる md content link フィールドから取得します。

出力

各フェーズでは、会話内に構造化された出力が生成されます。

  • フェーズ 1 — $PRODUCT が確定した、番号付きの製品推奨
  • フェーズ 2 — $PLATFORM が確定した、検出プラットフォームの確認
  • フェーズ 3 — 出力なし（ドキュメントページを取得し、$CONSTRAINTS、$ERROR_CODES、$CODE_EXAMPLES を保存）
  • フェーズ 4 — 自動的に確定した設定ごとに 1 行で確認。不足している値についてのみ質問
  • フェーズ 5 — 生成したコードブロック：バリデーション層、API ルート、Webhook ハンドラー、注文ステータスユーティリティ、オプションの DB スキーマ
  • フェーズ 6（モバイルのみ） — 各手順に ✅ / ❌ / スキップを付けた、ネイティブ設定の概要表
  • フェーズ 7 — Markdown 形式の統合チェックリスト + パラメーター制約テーブル + エラーリファレンステーブル
  • フェーズ 8 — 合否をまとめたテスト結果テーブル。モバイルプラットフォーム向けの手動 SDK テストガイド
  • フェーズ 9 — [docs|memory-bank|notes|juspay-integration]/[product]-[YYYY-MM-DD].md にサマリーファイルを保存
  • 完了 — フェーズごとの所要時間を記載したタイミングテーブルと、具体的な最適化の提案 2～3 件

ガードレール

  1. このファイルに製品知識を含めないでください。 製品 ID、プラットフォームの一覧、認証情報の名前は products/ または MCP のレスポンスから取得します。このファイルや学習データから取得してはいけません。

  2. 意図との照合の前に products/ を読み込んでください。 学習データでの知識に基づいて、適合する製品を推測してはいけません。

  3. 推奨を提示する前に explore_product を呼び出してください。 手順 1.7 は必須です。製品を推奨として提示する前に、その製品の種類と統合の複雑さを把握する必要があります。

  4. ドキュメントの URL を独自に作成しないでください。 すべての URL は、explore_product のレスポンスに含まれる md content link フィールドから取得します。

  5. 情報を捏造しないでください。 ページを読み込めなかった場合や、ドキュメントに記載のないセクションがある場合は、その旨を伝えてください。ユーザーが手動で確認できるよう、生の URL を提示してください。

  6. 製品の種類は explore_product から取得してください。 製品名や学習データから種類を推測してはいけません。

  7. プラットフォームの一覧は $DOC_MAP から取得してください。 explore_product が返したプラットフォームのみを、過不足なくそのまま提示してください。

  8. API のみの製品について、プラットフォームに関する質問をしてはいけません。 $DOC_MAP にランタイムプラットフォーム ID がない場合は、プラットフォームの選択を完全に省略してください。

  9. コード例はドキュメントから取得してください。 取得したドキュメントページに記載されている正確なメソッド名、クラス名、コード構造を信頼できる情報源として使用してください。

  10. パラメーターと制約はドキュメントから取得してください。 必須フィールド、型、maxLength、minValue、enumValues の実際の値は、取得したページの記述に従います。これらの値をもとに $CONSTRAINTS を設定してください。

  11. コードではドキュメントに記載された名前のみを使用してください。 取得したページに登場しないメソッド名やクラス名は使用してはいけません。

  12. エラーコードはドキュメントから取得してください。 取得したすべてのページから収集してください。捏造してはいけません。

  13. 認証情報をメモリの外に出さないでください。 $API_KEY、$WEBHOOK_AUTH_PASSWORD、その他のシークレットは、検証文字列、タスクの説明、integrate-results の呼び出し、Bash コマンドの引数、ターミナル出力に含めてはいけません。保存されたフィールドについては integrate-results スクリプトがこのルールを適用します。検証文字列とコマンド引数については、呼び出し元が責任を負います。

コメント

Markdown 対応