用途
JP PRD 用于帮助用户创建、编辑或校验一份高质量的 Juspay 支付集成 PRD。它保持文档以集成为中心，并便于向实现阶段交接。PRD 记录集成必须做什么、范围内的输入/流程/方式/界面，以及下游设计必须遵守的约束；下游的 jp-architecture 技能决定“如何做”，jp-executor 负责实现。
主要能力
- 支持三种意图模式：创建（无 PRD）、更新（已有 PRD）、校验（仅评审，不修改）。
- 在创建前检查工作区是否已有进行中的 PRD（frontmatter status 非 final），若有则提供恢复选项。
- 检测并记录仓库拓扑（single-repo | split）、本侧（backend | frontend | fullstack）、另一侧（backend | frontend | none），支持前后端分离仓库。
- 若另一侧仓库已产出交接文件（如 {doc_workspace}/handoff-<this_side>.md），则将其跨侧契约视为权威，本侧 PRD 必须遵循。
- 通过 juspay-mcp 连接商户仪表盘（可选），读取 merchant_id、client_id、integration_type 等信息；失败时回退到手动模式。
- 通过 docs-mcp 核对产品 slug、集成形态、平台，并提取凭证、请求/响应字段、错误码、webhook 结构等事实，每条文档事实标注来源 URL。
- 提供 Reviewer Gate：使用校验清单和临时评审器，以并行子代理方式评审 prd.md（和 addendum.md），输出分级发现。
- 在 Finalize 阶段执行决策日志审计、输入对账、评审通过、开放项分诊和润色。
使用方式
技能激活时，会简要引导用户：本技能产出 Juspay 集成 PRD，用户可随时要求深入某节或从多角度权衡决策。首条消息会扫描是否误路由：技术实现/集成设计 → jp-architecture；实际编写集成代码 → jp-executor，并建议先转向其他技能。
发现阶段顺序：头脑倾泻 → 代码库与环境扫描 → 商户访问（juspay-mcp）→ 产品收敛（docs-mcp）→ 工作模式 → 模式限定工作。工作模式提供快速路径（批量剩余缺口，用 [ASSUMPTION] 标签起草完整 PRD）和教练路径（共同走 PM 思维章节，可选 Capabilities + Flows 或 Journey-led 入口）。
工作区默认为 {project-root}/docs/juspay/（不存在则创建），产出 prd.md、addendum.md、.decision-log.md，以及临时的 review-.md / reconcile-.md。jp-architecture 和 jp-executor 从同一文件夹读取。
适用场景
- 需要为 Juspay 支付集成编写、更新或校验 PRD 的团队。
- 前后端分离仓库中，需要一侧产出 PRD 并与另一侧交接契约对齐的场景。
- 需要将支付集成的产品事实（产品名、集成形态、API/SDK 字段、错误码、webhook 结构）基于文档而非记忆进行记录的场景。
- 需要为下游架构设计和实现提供清晰、可交接的需求文档的场景。
限制
- 不负责技术实现设计（由 jp-architecture 负责）或编写集成代码（由 jp-executor 负责）。
- 不自行配置设置文件，不进行语言/名称解析；只读取用户提供的内容和工作区产物。
- 产品目录 products/ 为非权威定位目录，最终需与 docs-mcp 核对。
- 文档事实必须来自 docs-mcp-server 工具或用户，不得来自记忆或训练数据。
- 生产环境为强制目标环境，不询问用户选择沙箱或生产；仅当用户明确且未提示地要求时才记录非生产环境。
- 不询问用户选择支付方式，因为集成与支付方式无关，商户启用哪些方式是仪表盘/运行时配置。
- 不包含独立人物角色章节。
- 具体收费、价格、平台支持等未在资料中提供。