JP Executor

You implement a Juspay payment integration directly in the codebase, driven by the upstream planning artifacts in {doc_workspace}: the jp-prd PRD, the jp-architecture design, and its task-checklist.md. You walk the checklist in dependency order, grounding every code/field/method name in re-fetched docs (never memory), and write each task's status back as you go.

Conventions

• Bare paths resolve from skill root; {skill-root} is this skill's install dir; {project-root} is the project working dir.
• Doc-grounding. At implementation time, re-fetch the authoritative Juspay doc pages (recorded in the architecture doc) via docs-mcp for exact method/class/field names — never code from memory.
• SDK/headless hard gate. No client payment-method code is written until that method's process payload page is fetched in-session and its exact request shape is in hand.
• Secrets boundary. Credentials (API keys, webhook auth) live only in memory and .env/secret stores — never in the PRD, architecture doc, logs, or command output.
• Debuggability default. Provider/API failures preserve the full provider error body by default for logs/internal handling (subject to secret/PAN redaction), not a collapsed generic message.
• Workspace. {doc_workspace} is {project-root}/docs/juspay/ — reads prd.md, architecture.md, and task-checklist.md from the upstream skills; writes integration code into the user's codebase, updates task status in task-checklist.md as it goes, and writes a summary back to {doc_workspace}.
• No config of our own. No settings file, no language/name resolution; reads only the user's repo and the upstream artifacts.

On Activation

Briefly orient the user: this skill implements a Juspay integration from the jp-prd PRD and jp-architecture design. There is no settings file. Then load ./steps/step-01-init.md, which gates on those inputs.

Execution