jp-executor

JP Executor

{doc_workspace} にある上流の計画成果物、すなわち jp-prd PRD、jp-architecture 設計、および task-checklist.md に基づき、Juspay 決済連携をコードベースに直接実装します。チェックリストを依存関係の順に進め、コード／フィールド／メソッドの名前はすべて再取得したドキュメントで確認しながら、各タスクの status を進捗に合わせて更新します。

規約

• パスのみを指定した場合はスキルのルートから解決します。{skill-root} はこのスキルのインストール先、{project-root} はプロジェクトの作業ディレクトリです。
• ドキュメントに基づく実装。 実装時には、アーキテクチャドキュメントに記録された Juspay の正式なドキュメントページを docs-mcp で再取得し、正確なメソッド／クラス／フィールド名を確認します。記憶を頼りにコードを書いてはいけません。
• SDK／ヘッドレスの厳格なゲート。 その決済方法の process ペイロードのページをセッション中に取得し、正確なリクエスト形式を確認するまでは、クライアント側の決済方法コードを一切書きません。
• シークレットの取り扱い境界。 認証情報（API キー、Webhook 認証情報）はメモリと .env／シークレットストアにのみ保存します。PRD、アーキテクチャドキュメント、ログ、コマンド出力には決して含めません。
• デバッグしやすさを標準とします。 プロバイダー／API のエラーが発生した場合、デフォルトでは要約された汎用メッセージに置き換えず、プロバイダーのエラーボディー全体をログ／内部処理用に保持します（シークレット／PAN のマスキングを条件とします）。
• ワークスペース。 {doc_workspace} は {project-root}/docs/juspay/ です。上流スキルの prd.md、architecture.md、task-checklist.md を読み込み、ユーザーのコードベースに連携コードを書き込みます。作業を進めながら task-checklist.md のタスクの status を更新し、{doc_workspace} にサマリーを書き込みます。リポジトリが分かれた実行では、受信した handoff-<this_side>.md（存在する場合）も読み込み、共有可能な handoff-<other_side>.md を書き込みます。
• 独自の設定はありません。 設定ファイルや言語／名前の解決機能はありません。ユーザーのリポジトリと上流の成果物のみを読み込みます。
• 本番環境を強制します。 常に本番環境を対象とします。使用環境を尋ねたり、サンドボックスを提案したりしません。ユーザーが明示的に、かつ促されずにリクエストした場合に限り、本番以外の環境を使用します。キーの種類とステージは、設定されたホストに合わせます（steps/step-02-credentials.md を参照）。
• リポジトリ分割に対応します。 side ∈ {this_side, shared} のタスクのみをビルドします。other_side のタスクはここでは実装せず、他方のリポジトリを担当するエージェント向けに handoff-<other_side>.md に記載します。受信した handoff-<this_side>.md がある場合は、その契約に沿ってこの側をビルドし、準拠していることを確認します。references/split-integration.md を参照してください。
• ステージの追跡。 このスキルは、今回の実行で実際にビルドする内容に基づき、backend と frontend のファネルフェーズを管理します。steps/step-01-init.md で started にし、steps/step-09-summary.md で終端状態にします。juspay_track_integration_stage を使い、完了を待たずに呼び出し、ブロックしてはいけません。references/integration-stage-tracking.md を参照してください。

起動時

このスキルが jp-prd PRD と jp-architecture 設計に基づいて Juspay 連携を実装することを、ユーザーに簡潔に説明します。設定ファイルがないことも伝えます。その後、これらの入力を前提条件として確認する ./steps/step-01-init.md を読み込みます。

実行

./steps/step-01-init.md を最後まで読み、指示に従ってください。ステップの流れ：

1. step-01-init.md — 必須ゲート（アーキテクチャとタスクチェックリストが必要）、チェックリストを解析してキュー化 → コードベースを再スキャン → juspay-mcp モードを引き継ぎます。（常に実行）
2. step-02-credentials.md — 認証情報を .env に設定します（juspay-mcp 経由、またはダッシュボードで手動設定）。（必要に応じて実行）
3. step-03-core.md — ドキュメントを再取得し、バリデーション層（制約のあるフィールドがある場合）、SDK のインストール、コア統合と注文ステータスの照合を行います。（常に実行）
4. step-04-webhook.md — Webhook ハンドラー（署名と冪等性）を実装します。（webhook タスクがある場合のみ）
5. step-05-data-model.md — 注文／決済スキーマを実装します。（db タスクがある場合のみ）
6. step-06-native-setup.md — モバイルネイティブ SDK を設定します。（ネイティブのサーフェスでのみ）
7. step-07-portal-config.md — ダッシュボードを設定します（Webhook／リターン URL）。ナビゲーションパスとディープリンクも含みます。（manual-dashboard タスクがある場合のみ）
8. step-08-test.md — 最小限の稼働確認スモークテストを実施し、詳細かつスタックに応じたテストを jp-validate に引き継ぎます。（test タスクがある場合のみ）
9. step-09-summary.md — 統合の概要を永続化し、チェックリストのステータスを確定します。（常に実行）

詳細なテストは専用の jp-validate スキルで行います（リポジトリのテストスタックを検出して再現し、リスクの優先度に応じた決済テストを実施し、test-report.md を作成します）。この実行フローでは稼働確認スモークテストを行い、jp-validate を案内します。ビルド後に jp-validate を実行してください。

ステップは条件付きです。 共通ではない各ステップの冒頭には適用条件ゲートがあり、task-checklist.md（正式な情報源）と architecture.md に該当する作業がない場合は自動的にスキップします。Webhook タスクがなければ Webhook ハンドラーは不要です。Web／API サーフェスならネイティブ設定は不要です。ダッシュボードで設定する項目がなければポータルステップは不要です。この実行フローでは、この統合に必要な作業だけを行い、統合で必要のない Webhook／DB／ネイティブ／ポータルの作業を決して作り出しません。split 実行で「X タスクがある」とは、このサイドに属する X タスク（side ∈ {this_side, shared}）があることを意味します。other_side のタスクはステップ 1 ですでに skipped とマークされており、ここでステップの実行条件になることはありません。

これは支援を目的とするのではなく、アクション指向です。実装を進めますが、リスクのある操作や外部操作（認証情報の設定、DB スキーマの変更、ポータルの設定、サーバー／テストの開始）の前にはチェックポイントを設けてください。

juspay-mcp には認証ガードがあり、すべての開発者がダッシュボードにアクセスできるとは限りません。アクセスの流れ（アクセスを申請 → ログインまたは手動での Q&A）と、出典／再利用のルールについては references/juspay-mcp.md を参照してください。juspay-mcp 由来のデータはすべて手動入力で代替できるため、処理が止まることはありません。