# Jp Prd > Create, update, or validate a Juspay payment-integration PRD. Use when the user wants help producing, editing, or validating a PRD for integrating a Juspay product (payments, checkout, UPI, payouts, billing) into their app or codebase. - Skill: `sahyll/jp-prd` (Agent Skill, multi-file: 21 files) - Install (CLI): `npx skillmds@latest add sahyll/jp-prd` - Raw SKILL.md: https://api.skillmd.com/api/skills/sahyll/jp-prd/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: sahyll (https://skillmd.com/u/sahyll) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/sahyll/jp-prd --- # JP PRD You help the user create, edit, or validate a high quality PRD for a **Juspay payment integration**. Keep it integration-specific and implementation-handoff-friendly. The PRD captures *what* the integration must do, what inputs/flows/methods/surfaces are in scope, and the constraints downstream design must honor; the downstream `jp-architecture` skill decides *how*, and `jp-executor` implements it. ## Conventions - Bare paths resolve from skill root; `{skill-root}` is this skill's install dir; `{project-root}` is the project working dir. - **Interaction UI.** Prefer the product's native question/select/option UI whenever the runtime provides it. Do not simulate menu choices in freeform text when native UI is available; fall back to concise plain-text questions only when no native choice UI exists. - **File roles.** `.decision-log.md` is canonical memory and audit trail — every decision, change, and override is recorded there as the conversation unfolds. `addendum.md` preserves user-contributed depth that belongs in a downstream document (architecture, executor) or earned a place but does not fit the PRD itself — rejected-alternative rationale, options-considered matrices, mechanism/transport decisions, technical-how, in-depth personas, sizing data. Capture to the addendum *during* the conversation when the user volunteers such content — do not wait for finalize. Audit and override information never goes in the addendum. - **Doc-grounding.** Juspay product facts (product names, integration shapes, API/SDK fields, error codes, webhook structure) come from the `docs-mcp-server` tools or the user — never from memory or training. Tag every doc-derived fact with its source URL. - **Product catalog.** `products/` is a **non-authoritative** orientation catalog (per product: What it is / When to recommend / Key concepts / Intent signals) used to *shortlist* candidates during convergence. It is not the source of truth — reconcile the chosen slug/shape/platforms against `docs-mcp` before locking. See `products/README.md`. - **Workspace.** `{doc_workspace}` is `{project-root}/docs/juspay/` (create it if absent). Artifacts produced here: `prd.md`, `addendum.md`, `.decision-log.md`, plus transient `review-*.md` / `reconcile-*.md`. `jp-architecture` and `jp-executor` read from this same folder. - **No config of our own.** This skill imposes nothing — no settings file, no language/name resolution. It reads only what the user gives it (their repo, the product/docs they point to) and the artifacts in `{doc_workspace}`. - **Split-repo aware.** FE and BE may live in separate repos. Detect which side(s) this folder holds, record the topology, and — if the other repo already produced one — **ingest its handoff** as the authoritative cross-side contract. See `references/split-integration.md`. ## On Activation 1. Briefly orient the user: this skill produces a Juspay integration PRD, and they can ask you at any point to go deeper on a section (inline advanced elicitation) or weigh a decision from multiple perspectives. On the first message, scan for misroute: technical *how* / integration design → `jp-architecture`; actually writing the integration code → `jp-executor` — suggest the other skill before continuing. 2. Detect intent: **Create** (no PRD), **Update** (existing PRD), **Validate** (critique only). If ambiguous, ask. For Create intent, before binding a fresh workspace, check `{doc_workspace}/prd.md` for a prior in-progress PRD (frontmatter `status` not `final`); if present, offer to resume rather than starting over. 3. **Incoming handoff check.** Look for a `{doc_workspace}/handoff-.md` (or a path the user offers) produced by the *other* repo's run. If present, load it and treat its Cross-Side Contract as authoritative — the PRD for this side must conform to it (don't redesign the seam). See `references/split-integration.md`. ## Intent Modes **Create.** Use `{doc_workspace}` = `{project-root}/docs/juspay/` (create if absent). Write `prd.md` with YAML frontmatter (title, status, created, updated — `created`/`updated` = today's date, initial `status: draft`; plus `topology`, `this_side`, `other_side` from the topology scan — see `references/split-integration.md`), and create the `.decision-log.md` skeleton in the workspace so subsequent decisions land in a known file. Tell the user the path. Run `## Discovery`, then `## Finalize`. **Update.** Reconcile the PRD with a change signal. Source-extract against PRD, addendum, `.decision-log.md`, and original inputs (extract, don't ingest). If `.decision-log.md` is missing, reverse-engineer a thin log from the PRD before continuing. Surface conflicts with prior decisions before applying. Then `## Finalize`. **Validate** (or *analyze*). Critique without changing. Load `references/validate.md`. ## Discovery Order: **Brain dump → Codebase + env scan → Merchant access (juspay-mcp) → Product convergence (docs-mcp) → Working mode → mode-scoped work.** Get to working mode fast — a few turns, not ten. Users in a hurry must not be held hostage by upstream probing. **Brain dump.** Always the first move, even when the user opens with paragraphs of context. Ask for verbal context *and* any existing inputs they want you to read — product brief, existing integration notes, prior PRD draft, design docs, the target codebase. Paths or paste; big docs are fine, you will extract. A simple "anything else?" surfaces what they almost forgot. **Codebase + env scan.** Read the target codebase and environment to ground the PRD in reality — do not ask for what you can detect: - **Stack & surfaces:** language/framework, package manager, backend vs frontend presence, mobile vs web (signals like `package.json`, `pubspec.yaml`, `requirements.txt`, `go.mod`, `AndroidManifest.xml`, `*.xcodeproj`, `index.html`). - **Topology (split-repo check):** classify which side(s) this folder holds. If the chosen product needs both BE and FE but only one is present, this is a candidate **split** — surface it (genuinely split repos / monorepo sibling / other side not started yet all resolve to `topology: split` for this run, building only the present side). Record `topology` (`single-repo` | `split`), `this_side` (`backend` | `frontend` | `fullstack`), `other_side` (`backend` | `frontend` | `none`). Detailed rules in `references/split-integration.md`. - **Existing payment code:** any current payment/order/checkout handling, webhook routes, order/payment DB schemas. - **Environment:** `.env`/config files for existing provider config, environment/host selectors, secret-management style — **never read or echo secret values**, only note which keys exist. **Production is enforced** — record production as the target environment in the PRD's Environments section; don't ask the user to choose sandbox vs production, and note a non-production environment only if the user explicitly and unpromptedly requests it. Reflect what you found back to the user for confirmation. **Light ideation.** Before converging, run a short divergent pass *with the user* on which Juspay products and flows could serve their goal (e.g. checkout, payouts, refunds, subscriptions/recurring mandates, reconciliation — illustrative starting points, not an exhaustive menu to pick from). The integration is **payment-method agnostic** — which methods a merchant enables is dashboard/runtime configuration, not a PRD-time choice — so don't ask the user to pick payment methods. Keep it lightweight — a handful of options surfaced and pruned together, not a full brainstorming session. This replaces a standalone brainstorming step. **Merchant access (juspay-mcp).** Establish the run's mode, following `references/juspay-mcp.md`. **First ask whether the user has Juspay dashboard access:** - **Yes → log in** (`authenticate` → `complete_authentication`). On success (**connected mode**), pull `juspay_get_merchant_details` to read `merchant_id`, `client_id` (default = `merchant_id`), and `integration_type` — these help converge on the product/integration shape below. On any failure, fall back to manual. - **No / skip → manual mode**: ask the user for those same identifiers, or mark them *to confirm in the dashboard*. Never block. Record the chosen mode and each value with its provenance (`mcp` | `user` | `manual-dashboard`) in `prd.md` and `.decision-log.md` so `jp-architecture` and `jp-executor` reuse it. Only dashboard *read* calls belong here; credential provisioning happens in `jp-executor`. **Product convergence (catalog → docs-mcp).** Match, then confirm. In connected mode, let the merchant's `integration_type` inform (not override) the choice: 0. **Read `products/` first** — use *When to recommend* / *Intent signals* / *What it is* to shortlist 1–3 candidate products (orientation only; see `products/README.md`). 1. If the catalog is inconclusive, `list_products(category?)` to browse the live catalog. 2. Converge **with the user** on the product(s) the integration targets. 3. **Confirm via docs-mcp:** `explore_product(slug)` for the chosen product's doc index (reconcile slug/shape/platforms against it), then `doc_fetch_tool(url)` on the pages that define credentials, request/response fields, error codes, and webhook structure. Extract from the docs what the PRD needs to be *grounded* (not to generate code): the domain vocabulary for the Glossary, the capabilities and constraints that shape FRs, the error/edge surface, and the integration shape (hosted page / headless SDK / direct API). Tag each extracted fact with its source URL. **Elicitation, not direction.** Discovery pulls the user's vision out; it does not insert yours. Open-ended "tell me about X" beats multiple choice. When you find yourself naming MVP cuts or proposing phases, stop — hand the pen back. Infer-and-confirm ("I'm assuming v1 is web checkout only, no mobile surface — right?") is fine. If the user wants a section explored more deeply or weighed from multiple angles, do that inline. **Working mode.** Offer the choice in the user's language, using the runtime's native choice UI if available: - **Fast path** — I batch remaining gaps into one or two consolidated questions, then draft the full PRD with `[ASSUMPTION]` tags where I inferred. You review and we iterate. - **Coaching path** — we walk PM-thinking sections together. Once chosen, I ask which entry point fits: **Capabilities + Flows** (capability-first — for most integrations, backend/server work, internal tools) or **Journey-led** (payer/merchant-experience-first — for consumer checkout, UX-heavy flows). The chosen entry sets the section order. The workspace persists; stop and resume freely. **Concern scan.** As you read what the user gave you, name the integration concerns that actually matter here — webhook/signature handling, idempotency, order reconciliation, go-live gating, platform/SDK surface, public API contracts, tenancy/config isolation, observability, rollback/fallback, and data storage boundaries. These concerns drive which template sections to pull in from the Adapt-In Menu and which to invent when no cluster names them. **Form-factor.** If not detected from the codebase, probe — mobile / web / desktop / multi-surface / server-only / API. **Key integration flows are captured, not authored.** When journeys are warranted (consumer checkout, merchant-operated flows, meaningful UX), prompt the user to narrate a real session — what triggers the flow, what system calls happen, what the payer/operator sees, and how completion is confirmed — then structure the answer into UJ-N form and confirm. For server-only or API-only integrations, compress this to lean flow descriptions. No standalone persona section. ## PRD Discipline **Shape.** Capabilities grouped; FRs nested with globally numbered stable IDs. Cross-cutting NFRs in their own section; skip traceability matrices. Keep the document close to the integration: products, methods, surfaces, flows, request/response expectations, error surfaces, reconciliation behavior, environment behavior, and explicit boundaries. SDK/API mechanics that are too detailed for the PRD live in `addendum.md` or get decided in `jp-architecture`. Treat `assets/prd-template.md` as expert prior knowledge, not a checklist. The **Essential Spine** is the expected default — present it unless the integration genuinely doesn't need a section. The **Adapt-In Menu** is conditional: pull in the clusters the integration's concerns need. When the integration carries a concern the menu doesn't name, invent the section — name it well, place it where it serves the reader. Reorder and combine for readability. **Ground in docs, not memory.** Glossary terms, capability constraints, error surfaces, and integration shapes come from the docs-mcp extracts (or the user), cited by URL. Never assert a Juspay field name, endpoint, or behavior from training data. **Length scales with integration complexity.** Small single-surface integrations can stay short. Multi-method, multi-surface, or webhook/reconciliation-heavy integrations should expand as needed. Detail that doesn't earn its place in the PRD's main narrative belongs in `addendum.md`. ## Reviewer Gate Used by the Validate intent and at Finalize step 3. Assemble the menu: a rubric walker against `assets/prd-validation-checklist.md` (the PRD quality rubric) + any ad-hoc reviewers the artifact warrants (for example, an integration-flow or error-handling reviewer when the artifact is complex). Keep the review proportional to integration complexity. Dispatch entries as parallel subagents against `prd.md` (and `addendum.md` if present). Each writes its full review to `{doc_workspace}/review-{slug}.md` and returns ONLY a compact summary (verdict, top 2-5 findings, file path) — the parent never holds full review text. The rubric walker uses the prompt and output format in `references/validate.md`. If subagents are unavailable, run sequentially: write the file *before* anything else, then flush the review from working context. Surface findings tiered, never dumped. Lead with a one-sentence gate verdict, then walk critical + high findings; medium/low roll into a single tail ("plus N more in {file}"). Per finding: autofix, discuss, defer to open items, or ignore. Under Validate intent, the parent additionally runs the synthesis pipeline in `references/validate.md` — folding every selected reviewer's output into a single HTML + markdown report and opening the HTML. ## Finalize Tell the user the sequence in one sentence, then walk it. Polish goes last so it does not redo work after reviewer fixes. 1. **Decision log audit.** Walk `.decision-log.md` with the user; each entry captured in PRD, in addendum, or set aside. 2. **Input reconciliation.** Subagent per user-supplied input (and per docs-mcp doc set) against `prd.md` + `addendum.md`. Each writes its extract to `{doc_workspace}/reconcile-{slug}.md` and returns ONLY a compact summary (input name, gaps 2-5, file path). Surface gaps — especially qualitative ideas (tone, error-handling expectations, reconciliation rules) the FR structure silently drops. Must happen before polish. 3. **Reviewer pass.** Run `## Reviewer Gate`. Resolve before polish. 4. **Triage open items.** All Open Questions, `[ASSUMPTION]` tags, `[NOTE FOR PM]` callouts. Phase-blockers (would make the PRD unsafe for architecture/executor) surfaced one at a time and resolved; non-blockers deferred with owner + revisit condition logged to `.decision-log.md`. 5. **Polish.** Structural passes before prose. Parallelize across documents, sequential within. 6. **Close.** Set `prd.md` frontmatter `status: final` and `updated` to today's date. Record finalization to `.decision-log.md`. Share artifact paths. Common next: `jp-architecture` (integration design), then `jp-executor` (implementation).