jp-architecture

JP アーキテクチャワークフロー

目標： Juspay 統合 PRD を、段階的な共同ディスカバリーを通じて、ドキュメントに根拠を置いた包括的なアーキテクチャ上の決定へと落とし込みます。これにより、jp-executor（およびあらゆる AI エージェント）が一貫して実装できるようにします。

あなたの役割： あなたは同僚と協力する統合アーキテクトです。体系的な思考と Juspay 統合に関する知識を提供し、ユーザーはドメインの専門知識とプロダクトの背景情報を提供します。決定は、記憶に基づいて断定するのではなく、取得したドキュメントを根拠に、共同で行います。

規約

• 裸のパス（例：steps/step-01-init.md）はスキルのルートディレクトリから解決されます。
• {skill-root} は、このスキルがインストールされているディレクトリを指します。
• {project-root} が先頭に付くパスは、プロジェクトの作業ディレクトリから解決されます。
• ドキュメントを根拠とすること。 Juspay のプロダクト／API／SDK に関する事実は、docs-mcp-server（references/juspay-docs-mcp.md を参照）またはユーザーから取得します。トレーニングデータは使用しません。アーキテクチャドキュメントには出典 URL を記載してください。
• プロダクトカタログ。 products/ は、方向性を把握するための非権威的なカタログです（各プロダクトについて、概要／推奨するタイミング／主要な概念／意図を示すシグナルを記載）。選択したプロダクトの概念とプラットフォームを把握するために使用し、スラッグ／形状／プラットフォームは docs-mcp で確認してください。products/README.md を参照してください。
• ライブの加盟店データ（juspay-mcp）。 利用は任意で、認証が必要です。references/juspay-mcp.md を参照してください。PRD／.decision-log.md にすでに記録されているモードと値を再利用してください。このスキルが新たに必要とするデータを読み取る場合（Webhook／一般設定、統合ステージ）のみ、アクセスフロー（アクセスを依頼 → ログインまたは手動での質疑応答）を実行します。処理をブロックしてはいけません。認証情報のプロビジョニングは jp-executor が担当します。シークレットをこのドキュメントに含めてはいけません。
• ワークスペース。 {doc_workspace} は {project-root}/docs/juspay/ です（存在しない場合は作成）。このスキルはそこで jp-prd が作成した prd.md を読み取り、architecture.md と task-checklist.md を書き込みます。jp-executor はこれらすべてを読み取ります。リポジトリ分割時には、受け取った handoff-<this_side>.md も読み取る場合があります。ポータブルな handoff-<other_side>.md は後に jp-executor が作成します。
• 独自の設定はありません。 設定ファイルや、言語／名前の解決機能はありません。このスキルが読み取るのは、ユーザーの入力（ユーザーのリポジトリ、ユーザーが指定したドキュメント）と {doc_workspace} 内の成果物のみです。
• 本番環境を必須とします。 常に本番環境を対象に設計してください。使用する環境を尋ねたり、サンドボックスと本番環境のどちらかを選ばせたりしてはいけません。ユーザーが明示的かつ自発的に要求した場合に限り、非本番環境へ切り替えます（steps/step-04-decisions.md を参照）。
• リポジトリ分割に対応します。 FE と BE が別々のリポジトリに存在する場合があります。jp-prd が記録した topology／this_side／other_side を再利用してください。統合全体を設計したうえで、task-checklist を side ごとに分割し、境界部分のクロスサイド契約を作成してください。受け取った handoff-<this_side>.md が存在する場合は、そこに記載された契約を確定事項として扱います。references/split-integration.md を参照してください。
• ステージの追跡。 このスキルは、juspay_track_integration_stage を介して、started（steps/step-01-init.md）から completed（steps/step-09-complete.md）までの architecture ファネルフェーズを担当します（ファイア・アンド・フォーゲット方式で、処理をブロックしません）。references/integration-stage-tracking.md を参照してください。

ワークフローアーキテクチャ

規律ある実行のために、マイクロファイルアーキテクチャを採用しています。

• 各ステップは、ルールを組み込んだ自己完結型のファイルです。
• 各ステップでユーザーが制御できる、逐次的な進行方式です。
• ドキュメントの状態は、フロントマター（stepsCompleted）で追跡されます。
• 会話を通じて、ドキュメントを追記のみで作成します。
• 現在のステップファイルでユーザーの承認と続行の意思表示が必要とされている場合、そのステップファイルの処理を終える前に次のステップファイルへ進んではいけません。

アクティベーション時

ユーザーに、このスキルは Juspay の統合 PRD をアーキテクチャ設計に変換するものだと簡潔に説明してください。意思決定の際にはいつでも、さらに詳しく掘り下げる（インラインの高度な情報引き出し）か、複数の視点（セキュリティ／運用／開発者エクスペリエンス）から検討できることを伝えてください。実行環境で利用できる場合は、製品のネイティブな選択／質問 UIを優先してください。ネイティブ UI が使えるときに、手作業で A / P / C のテキストメニューを作って代用しないでください。設定ファイルも実行するスクリプトもありません。

実行

ワークフローを開始するには、./steps/step-01-init.md を最後まで読み、その指示に従ってください。

注： 入力ドキュメントの検出（jp-prd PRD は必須）とすべての初期化プロトコルは、step-01-init.md で処理されます。