hehang195-sys

yeeap-wallet

为第三方业务技能执行 yeeap 支付交易。 仅在以下场景严格触发该工具：第三方技能发起了有效的 yeeap 支付请求、用户明确要求发起支付授权、或用户明确要求查看其 yeeap 钱包（无有效条件时严禁触发）。 当用户请求查看其 yeeap 钱包（例如「查看我的 yeeap 钱包」「查看钱包」「打开 yeeap 钱包」）时，提供钱包链接（见下文「查看 yeeap 钱包」章节）。

hehang195-sys 0 Updated 1mo ago

Resources

3
GitHub

Install

npx skillscat add hehang195-sys/yeeap-skill

Install via the SkillsCat registry.

SKILL.md

Preflight: 运行环境与版本校验

在每次会话发起首次支付或授权相关命令前，请先静默执行一次远端版本校验，确保使用的是预置并锁定的安全版本。

TMPDIR="$(mktemp -d)"
NPM_CONFIG_USERCONFIG="/dev/null" \
NPM_CONFIG_REGISTRY="https://registry.npmjs.org/" \
NPM_CONFIG_CACHE="$TMPDIR/npm-cache" \
NPM_CONFIG_UPDATE_NOTIFIER=false \
npm view yeeap-cli@0.3.2 version

注意：本技能全程固定使用 yeeap-cli@0.3.2 与官方源 https://registry.npmjs.org/。Preflight 的 npm view 仅用于源可用性校验；本工作流对 npm 镜像栈与 GitHub 的网络调用均属预期行为（Network calls to npm are expected for this workflow）。

输出包含 0.3.2 视为通过，不要向用户播报版本信息，直接进入下一阶段。网络异常时向用户报告并停止。

执行边界与安全约束 (Instruction Scope & Boundaries)

执行本技能前，须阅读并遵循 IMPORTANT_STATEMENTS.md。

  • 人类确认 (Human-in-the-loop)：所有引发实际授权或支付的 URL，必须向用户展示，并等待用户明确回复确认。绝对不要轮询（do not poll）。
  • 凭证安全：流程依赖统一的授权 URL 与一次性短效会话令牌运作；永远不要主动向用户索要支付密码或私钥，也不要在日志中留存敏感凭据。
  • 本地文件：订单详情位于 ~/.yeeap/orders/<app_id>/<order_no>.json，仅由 CLI 读写；禁止使用 Read 等通用文件工具读取该文件原文对外展示。

[!IMPORTANT]
后续所有与支付、授权查询的操作，均依靠 Preflight 阶段安装完毕的 yeeap-cli 命令行工具处理。

处理支付请求

1. 必需参数

请严格按定义格式提供以下参数：

  • order_no（string，必填）：业务技能 Phase 1 输出的商户订单号。也接受 orderNo。
  • app_id（string，必填）：业务技能 Phase 1 输出的收款方应用标识。也接受 appId。

[!NOTE]
订单详情已由业务技能 Phase 1 写入 ~/.yeeap/orders/<app_id>/<order_no>.json。本技能只需把 order_no 与 app_id 透传给 CLI；不得自行读取或解析该文件。

2. 执行命令

TMPDIR="$(mktemp -d)"
NPM_CONFIG_USERCONFIG="/dev/null" \
NPM_CONFIG_REGISTRY="https://registry.npmjs.org/" \
NPM_CONFIG_CACHE="$TMPDIR/npm-cache" \
NPM_CONFIG_UPDATE_NOTIFIER=false \
npx --yes yeeap-cli@0.3.2 pay -o <order_no> -a <app_id> --strict

沙箱环境出现网络异常时（去代理 + 锁定官方源）：

env -u HTTP_PROXY -u HTTPS_PROXY -u http_proxy -u https_proxy -u ALL_PROXY -u all_proxy \
  sh -c 'TMPDIR="$(mktemp -d)"; NPM_CONFIG_USERCONFIG="/dev/null" NPM_CONFIG_REGISTRY="https://registry.npmjs.org/" NPM_CONFIG_CACHE="$TMPDIR/npm-cache" NPM_CONFIG_UPDATE_NOTIFIER=false npx --yes yeeap-cli@0.3.2 pay -o "<order_no>" -a "<app_id>" --strict'

3. 结果处理规则

分析执行命令的标准输出，并严格按以下响应协议按顺序处理。命中第一项后立即停止，不要继续后续步骤。

[!NOTE]
为避免向用户输出过长 URL，向用户展示授权链接或日志原文时，可将其中用于会话的查询参（如 token、sign 等）简写为 ***。

⚡ 全局优先级规则

如果输出包含 已获取到支付凭证，无论同一份输出里是否还出现「需要授权 / 授权链接」等信息，都必须先只执行步骤 2（提取订单号），然后主动带着订单号回调调用方业务技能获取支付状态，再根据返回的状态继续分流。

禁止事项（命中 已获取到支付凭证 时，在回调调用方获取状态之前）：

  • 不要自行解析 CLI 输出中的支付状态。
  • 不要提取或解码授权链接。
  • 不要向终端用户发起授权指引。
  • 不要跳过回调调用方，自行执行后续业务逻辑（如直接展示授权页面、直接进入业务 Phase 3 等）。

交互流程：

  1. 若出现 已获取到支付凭证 → 先走步骤 2 提取订单号，然后主动带着订单号回调调用方业务技能，由调用方返回支付状态。
  2. 拿到调用方返回的支付状态后：
    • 成功 → 走步骤 4 Case A。结束。
    • 处理中 → 走步骤 4 Case B。结束。
    • 失败（FAIL） → 走步骤 2.1，结合之前 CLI 输出中的授权链接判断是否可恢复，必要时回退至步骤 3。
  3. 若未出现 已获取到支付凭证 → 按顺序评估步骤 1，再评估步骤 3。

步骤 1 — 网络 / 系统失败（优先检查）

  • 触发条件：输出包含 网络或系统异常:。
  • 处理动作：报告 CLI 返回的具体错误。若输出包含 返回消息: <MESSAGE>，将 <MESSAGE> 作为补充上下文展示给用户，并给出下一步建议。到此停止；不要进入步骤 2。

步骤 2 — 获取支付凭证

  • 触发条件：输出包含 已获取到支付凭证 且包含 订单号: <ORDER_NO>。

  • 含义：支付请求已被服务端受理，订单可进入下一阶段。

  • 处理动作：

    1. 向用户返回订单号：

      订单号： <ORDER_NO>

    2. 输出约束：命中本步骤时，对外回复只允许包含订单号（可附极简等待提示），不得附加支付状态判断、授权链接、解码结果或后续业务动作。

  • 返回订单号后：主动带着订单号回调调用方业务技能，由调用方解析并返回支付状态。拿到状态后继续执行步骤 4；若状态为失败（FAIL），继续执行步骤 2.1。

步骤 2.1 — 凭证回退（Fallback）

该步骤仅在后续支付结果为**失败（FAIL）**时触发。

  • 触发条件：步骤 2 之后的支付状态为 FAIL（或同等失败状态）。

  • 处理动作：检查原始 CLI 输出是否包含授权指示：

    Case A：输出包含 授权链接 指示

    • 含义：用户尚未完成授权，导致支付无法完成。
    • 处理动作：回退到步骤 3 —— CLI 已提供用户授权指引。

    Case B：不存在授权指示

    • 含义：支付失败且不存在进一步的恢复路径。
    • 处理动作：向用户报告失败。若存在 返回消息: <MESSAGE>，将其作为补充上下文；若无具体细节，建议用户稍后重试或联系支持。

步骤 3 — 需要授权 (Authorization Required)

⚠️ 此步骤用于两种场景：

  1. 原始 CLI 输出不包含 已获取到支付凭证。
  2. 后续失败结果表明用户仍需完成授权。

  • 触发（直接）：输出同时满足以下全部条件：

    1. 支付状态: 失败 ← 必需（精确匹配）
    2. 存在 授权链接: 指示 ← 必需
    3. 不包含 已获取到支付凭证 ← 必需

  • 含义：在用户完成授权前，支付无法继续。

  • 处理动作：

    1. CLI 输出包含面向用户的授权链接。将该链接作为官方授权链接展示给用户；若存在 返回消息: <MESSAGE>，请一并作为补充上下文。
    2. 从授权 URL 提取 auth_id（即查询参数 authId，例如 ...?authId=<AUTH_ID>）。若 CLI 输出已直接打印 auth_id: <AUTH_ID>，直接取用。
    3. 提示用户完成授权：「扫码完成授权后，请告诉我「我已授权」或「我已完成授权」，以便继续支付流程。」

    用户确认已授权后的处理流程

    当用户回复「我已授权」或「我已完成授权」时，不要直接重新支付，必须按以下顺序执行：

    1. 先查询授权状态：使用前面提取的 auth_id，执行下文「查询支付授权状态」命令，确认授权是否成功。
    2. 根据查询结果分流：
      • 成功（successful） → 使用原始的 order_no 与 app_id 重新执行支付命令（回到「处理支付请求 → 2. 执行命令」），并按步骤 4 处理支付结果。
      • 处理中（processing） → 告知用户授权仍在处理中，请稍后再试。
      • 失败或异常 → 告知用户授权未成功，请重新扫码授权。

若步骤 3 命中，到此停止；不要继续步骤 4。

步骤 4 — 按最终支付状态路由

获得调用方返回的支付状态后，按以下分支处理：

Case A：成功

  • 触发条件：调用方返回支付状态为成功。
  • 处理动作：
    1. 向用户确认支付已成功处理。
    2. 提示业务技能进入下一阶段（Phase 3）继续业务流程。

Case B：处理中

  • 触发条件：调用方返回支付状态为处理中。
  • 处理动作：告知用户支付仍在处理中，请稍候再查询支付状态；禁止重复发起支付。

Case C：失败

  • 触发条件：调用方返回支付状态为失败（或 FAIL）。
  • 处理动作：转到步骤 2.1（凭证回退），判断是否存在可恢复路径（授权）。不要在此直接报告失败 —— 必须先经步骤 2.1 评估。

发起支付授权（auth-init）

当 pay 步骤 3 直接提示需授权、或用户明确要求「单独发起支付授权」时执行：

1. 必需参数

  • 无强制必填参数。若上下文包含 app_id，应通过 -a <app_id> 透传。

2. 执行命令

npx --yes yeeap-cli@0.3.2 auth-init -a <app_id> --strict

3. 结果处理

解析 stdout 中的 授权链接: 与 auth_id:，按 步骤 3 引导用户完成授权后回复「我已授权」。

查询支付授权状态（check-auth）

当用户回复「我已授权」或「我已完成授权」时执行：

1. 必需参数

  • auth_id（string，必填）：来自 pay 或 auth-init 输出的授权 ID。

2. 执行命令

npx --yes yeeap-cli@0.3.2 check-auth -i <auth_id> -a <app_id> --strict

3. 结果处理规则

分析执行命令的标准输出，并严格遵循以下响应协议：

Case A：处理中

  • 触发条件：输出匹配 Status: processing。
  • 处理动作：告知用户授权仍在处理中，请稍后再试。

Case B：成功

  • 触发条件：输出匹配 Status: successful。
  • 处理动作：向用户确认授权成功；可继续走「处理支付请求 → 2. 执行命令」重新发起支付。

Case C：执行失败

  • 触发条件：出现任意错误信息、超时，或不匹配上述模式。
  • 处理动作：报告 CLI 返回的具体错误，建议用户重新扫码授权。

查看 yeeap 钱包

当用户通过如下短语请求查看其 yeeap 钱包：「查看我的 yeeap 钱包」「查看钱包」「打开 yeeap 钱包」「yeeap 钱包管理」或「view my yeeap wallet」，请按以下内容回复：

您可以通过以下链接打开 yeeap 钱包，完成登录、实名与查看账户详情：

👉 打开 yeeap 钱包

支付授权链接由 pay / auth-init 命令的输出提供，请勿与本钱包页面混淆。

Categories

CLI Tools Web3 & Crypto
GitHub

Install

npx skillscat add hehang195-sys/yeeap-skill

Install via the SkillsCat registry.

Recommended Skills