Activate and authorize Alipay AI payment capabilities, supporting payment capability enabling, authorization, binding, and unbinding.
Reference Documents(Consult as needed, no need to read in advance):
references/cli-setup.md—alipay-botInstallation and verification process when not installedreferences/env-vars.md— Environment variable passing rulesreferences/output-rules.md— Full version of output rulesreferences/security.md— Supply chain security and data privacy statementreferences/feedback.md— Detailed issue feedback process
Applicable Scenarios
- The user asks to enable/activate payment capability, check activation status
- The user asks to unbind Alipay wallet, disable payment capability, cancel authorization
- The user reports "already unbound" "payment capability has been disabled"
- The user sends an authorization code (format:
开启支付功能 xxxx、开启支付功能：xxxx、绑定AI钱包 xxxx） - The user reports having completed activation/authorization within Alipay (e.g., "activated", "authorized", "bound", "scanned")
- The user explicitly requests handling payment capability not activated/not authorized
- The user requests enabling the wallet/payment function in shopping or other scenarios (cross-scenario trigger)
- Switched from a payment scenario: Handle only when the payment command explicitly requires an independent wallet flow, or the user proactively requests to first activate/authorize the wallet
Trigger Condition Determination (Important)
Scenarios where this skill should be triggered:
| Scenario | User Intent | Whether to Trigger | Description |
|---|---|---|---|
| The user proactively requests activation | "Help me activate the payment function" | Should trigger | Directly handle the activation request |
| The user asks about activation status | "Is my payment function activated?" | Should trigger | Check and handle the activation status |
| The user requests unbinding | "Help me unbind Alipay" | Should trigger | Handle the unbinding request |
| The user sends an authorization code | "Enable payment function 123456" | Should trigger | Handle authorization code binding |
| The user reports having completed authorization on the Alipay side | "Activated", "authorized", "bound", "scanned" | Should trigger | Execute check-wallet to confirm the automatic binding result |
| Independent wallet check finds unauthorized | check-wallet returns code=200, message is "Application submitted, waiting for authorization" | Should trigger | Continue this skill's wallet authorization flow |
| Independent wallet check finds not activated | check-wallet returns code=500 | Should trigger | Continue this skill's wallet activation flow |
| Request to enable wallet during shopping | "Then help me enable the payment feature first" | Should trigger | Cross-scenario switching, even if the preceding context is about shopping |
| The user says "Bind AI wallet" | "Bind AI wallet 461417" | Should trigger | Directly provide the authorization code for binding |
Scenarios where this skill is prohibited from triggering:
| Scenario | User intent | Whether to trigger | Description |
|---|---|---|---|
| The user wants to pay and there is a cashier URL | "Help me pay this order" + cashier URL | Prohibited from triggering | Should be handled by alipay-payment-skill |
| The user has authorized and wants to pay | check-wallet returns code=200, message is not "Application submitted, awaiting authorization", access_url="" | Prohibited from triggering | Execute payment directly, no authorization needed |
| Payment flow in progress | submit-payment or query-payment-status has already started | Prohibited from triggering | Continue the payment flow |
| The user is only asking a payment question | "How do I pay with Alipay" | Prohibited from triggering | Answer the question, do not trigger the authorization flow |
Environment dependencies
npmAvailable,alipay-botCLI is installed (which alipay-botdetection, if not installed followreferences/cli-setup.mdexecute)
Command execution rules (highest priority)
All
alipay-botcommands must be executed directly using theexectool, with the complete command string passed as the parameter.
- Must use the
exectool: prohibited to callexeccommands through plugin hooks, indirect wrapper tools, or any non-alipay-botmethod - Pass the complete command string: prohibited to truncate, omit parameters, or split into multiple executions
- Surround URL parameters with quotes
- Command timeout/network unreachable → Prompt "Network request failed, please check your network connection and try again", may retry once; if it fails continuously, guide to problem feedback
- Handling asynchronous returns from the exec tool: when exec returns "Command still running (session xxx)", immediately use the process tool (action=poll) to obtain the actual output
- For environment variable rules, see
references/env-vars.md - For image output rules, see
references/image-output.md: only process MEDIA lines or Markdown images in the output of this command; after extracting the path from the MEDIA line, remove it, and send the image with the message tool; keep Markdown images as-is - Command whitelist: this skill can only execute the
alipay-botcommands explicitly listed in this document or in referenced documents (such ascheck-wallet、apply-wallet、bind-wallet、close-wallet, problem feedback commands); prohibited to execute, display, or infer any commands not defined in this skill document
Core principles (highest priority)
Principle 0: Command termination rules (the highest priority among the highest priorities)
┌─────────────────────────────────────────────────────────────────────────────┐
│ 终止规则（每条都是硬性约束，必须遵守） │
├─────────────────────────────────────────────────────────────────────────────┤
│ T1. bind-wallet 成功后 → 立即原样输出 CLI 内容 → 流程结束 │
│ 禁止再执行任何命令（禁止 apply-wallet、check-wallet 等） │
│ │
│ T2. bind-wallet 失败后 → 原样输出失败内容 → 流程结束，禁止追加重试引导 │
│ 禁止自动重新 apply-wallet，等待用户主动提供新授权码 │
│ │
│ T3. check-wallet 返回已绑定（code=200, message 不是"已申请开通，等待授权", access_url=""）→ 原样输出 → 流程结束 │
│ 禁止执行 apply-wallet、bind-wallet、再次 check-wallet │
│ │
│ T4. apply-wallet 成功后 → 原样输出 CLI 内容（含授权链接；如有引导则来自 CLI）→ 等待用户在支付宝内完成授权 │
│ 禁止本轮再次 apply-wallet，禁止本轮再次 check-wallet │
│ 后续用户反馈"开通好了/授权好了/绑定好了/扫完了" → 执行 check-wallet 确认状态 │
│ 如果用户提供授权码 → 直接 bind-wallet，不需要再次 apply-wallet │
│ │
│ T5. 用户提供了授权码 → 直接 bind-wallet -c <授权码> │
│ 禁止在 bind-wallet 之前执行 apply-wallet（已申请状态不需要重新申请） │
│ 禁止在 bind-wallet 之前再次 check-wallet（状态已通过上一步确认） │
└─────────────────────────────────────────────────────────────────────────────┘
Principle 1: Take action immediately after check-wallet execution (single-check principle)
check-wallet is a status check command; after executing it once, you must immediately take action based on the result. Prohibited to repeatedly execute check-wallet, and prohibited to stop and wait after execution.
┌─────────────────────────────────────────────────────────────────────────────┐
│ check-wallet 返回结果后的唯一正确行为 │
├─────────────────────────────────────────────────────────────────────────────┤
│ CLI 返回: code=200、message 不是"已申请开通，等待授权"且 access_url="" │
│ 状态判断: 已开通已授权 │
│ ─────────────────────────────────────────────────────────────────────────── │
│ 【必须执行】原样输出 CLI 返回的模板内容（模板T1/T11，含"支付功能已开启"） │
│ 【禁止执行】apply-wallet、bind-wallet │
│ 【禁止执行】再次 check-wallet │
│ 【流程结束】 │
├─────────────────────────────────────────────────────────────────────────────┤
│ CLI 返回: code=200 且 message 为"已申请开通，等待授权" │
│ 状态判断: 已申请未授权 │
│ ─────────────────────────────────────────────────────────────────────────── │
│ 如果用户本轮已提供授权码 → 直接 bind-wallet -c <授权码>（禁止 apply-wallet） │
│ 如果用户本轮反馈已完成支付宝侧授权 → 原样输出本次 check-wallet 结果，流程结束 │
│ 如果用户本轮只是申请/开通且需要授权链接 → apply-wallet → 原样输出模板T2 │
│ 【禁止执行】再次 check-wallet │
│ 【禁止执行】再次 apply-wallet │
├─────────────────────────────────────────────────────────────────────────────┤
│ CLI 返回: code=500 │
│ 状态判断: 未开通 │
│ ─────────────────────────────────────────────────────────────────────────── │
│ 【必须执行】apply-wallet 获取授权链接 │
│ 【必须输出】原样输出 CLI 返回的模板内容（模板T2，含"开启支付宝支付功能"+链接） │
│ 【禁止执行】再次 check-wallet │
│ 【禁止执行】再次 apply-wallet │
│ 【等待用户】用户在支付宝内完成授权后反馈，下一轮执行 check-wallet；若页面展示授权码则执行 bind-wallet │
└─────────────────────────────────────────────────────────────────────────────┘
Common error patterns (strictly prohibited):
| Incorrect command sequence | Reason for error | Correct command sequence |
|---|---|---|
check-wallet → check-wallet → apply-wallet |
Executing check-wallet repeatedly | check-wallet → apply-wallet |
check-wallet → apply-wallet → apply-wallet |
Executing apply-wallet repeatedly | check-wallet → apply-wallet → 等待用户完成支付宝侧授权 → check-wallet |
check-wallet(已授权) → apply-wallet |
Executing apply-wallet when already authorized | check-wallet(已授权) → 原样输出模板T1 → 结束 |
check-wallet(未授权) → 仅输出"未授权" |
Failing to output the template content when the user is applying for activation | check-wallet(未授权) → apply-wallet → 原样输出模板T2 |
bind-wallet(成功) → apply-wallet |
Redundant commands after success | bind-wallet(成功) → 原样输出 → 结束 |
check-wallet(已授权) → bind-wallet |
Executing bind-wallet when already authorized | check-wallet(已授权) → 原样输出模板T1 → 结束 |
Principle 2: Pass through CLI output as-is
The template content returned by the CLI already contains the complete status identifier and must be output as-is; adding extra signal words or modifying the content is prohibited.
Scope of this command output (highest priority)：
- The authorization/binding result presented to the user can only come fromthe alipay-bot command output actually executed this time. It is prohibited to assemble, complete, or replace this command output from conversation context, historical command output, payment order links, or other tool results.
- Non-JSON alipay-bot output must be passed through as-is as the user-visible result. Except for this output's
MEDIA:lines being sent via the image channel as transport-layer handling, it is prohibited to append any text not output by the CLI, such as "Authorization successful", "Please continue payment", "Please retry", or "Please enter the authorization code". - Images must also come from the alipay-bot command output actually executed this time: only this output's
MEDIA:lines or Markdown imagesmay be processed. It is prohibited to resend or reuse images from context, historical replies, old QR code paths, file system search results, or other tool results. - The short links returned during the wallet activation/authorization phase,
access_url、https://u.alipay.com/...、https://u.alipay.cn/...belong only to the wallet authorization process; it is prohibited to interpret these links as payment links, payment URLs, payment query shortUrls, or pass them to the payment skill'squery-payment-status。 - If the command output contains both update-recommendation logs and the final command execution result, onlythe final command execution resultmay be used to determine status;
- It is prohibited to extract or display links, QR codes, images, statuses, or payment results from fields such as
accessUrl、shortAccessUrl、qrcodeUrl、data、extInfoin diagnostic logs
| Executed command | Status identifier already included in the template | |-----------|-------------|---------------------| | check-wallet bound | "✓ Payment feature enabled" | | apply-wallet successful | "Please scan the QR code or click the link to enable the Alipay payment feature" + link | | bind-wallet successful | "[Enabled successfully]" + "Alipay payment feature has been enabled successfully" | | bind-wallet failed | "✗ Alipay AI Pay feature authorization failed, please retry" | | System error | "✗ The wind is too strong, please retry later" or server-side error text |
Output rules:
- Output as-is: Output the Markdown text returned by the CLI character by character as-is; adding extra signal words is prohibited. For image handling rules, see
references/image-output.md, and images must come from this CLI output - Preserve links completely: Variables such as
<<access_url>>in the template have already been replaced with actual links and must be output completely - MEDIA line / image → see
references/image-output.md. If this output contains a MEDIA line, extract the path from this MEDIA line, remove the MEDIA line, and send the image using the message tool. If this tool output contains a Markdown image in theformat, thenKeep it as-is in the output, render it in Markdown format; conversion is prohibited, and sending it with other tools is prohibited
Self-check questions (must be answered after each command is executed):
- After check-wallet is executed: Did I execute it only once? Did I immediately take the correct action based on the result?
- After apply-wallet is executed: Did I output the template content returned by the CLI exactly as-is (including "开启支付宝支付功能" and the link)?
- After bind-wallet is executed (success): Did I output the template content returned by the CLI exactly as-is (including "[开启成功]")?
- After bind-wallet is executed (failure): Did I output the template content returned by the CLI exactly as-is (including "授权失败")?
- Did I add signal words such as "授权链接" or "绑定成功" before the CLI output? (If yes, that is an error)
- Did I repeatedly execute check-wallet or apply-wallet? (If the answer is "yes", that is an error)
Output rules (highest priority)
For detailed rules, see
references/output-rules.md. Core summary:
- Markdown text → copy character by character exactly as-is; adding or removing content, wrapping in code blocks, and adding explanatory text are prohibited
- MEDIA line / image → see
references/image-output.md. If a MEDIA line exists in this output, extract the path from this MEDIA line, remove the MEDIA line, and send the image with the message tool. If this tool output contains aMarkdown image in the format, thenkeep it as-is in the output, render it in Markdown format; conversion is prohibited, and sending it with other tools is prohibited - JSON output → process according to field logic, do not display directly
- URL → keep it complete character by character; truncation/escaping is prohibited. Including
alipays://、https://and all other protocols - Diagnostic logs →
http request/http response/ traceId / costTime, etc. are only used for troubleshooting and do not participate in customer-facing output; extracting links or images from them is prohibited
check-wallet status determination rules (highest priority)
The status must be determined based on the code、message and access_url fields returned in the JSON; inferring the status from the output text on your own is prohibited.
If the check-wallet output contains multiple sections, you must ignore http request / http response and other diagnostic logs, and read only the final command result JSON. The accessUrl、shortAccessUrl、qrcodeUrl in the diagnostic logs is not the check-wallet customer-facing output; displaying it to the user is prohibited, and it cannot replace the apply-wallet。
check-wallet 返回值判断（唯一依据）：
code=200 & message != "已申请开通，等待授权" & access_url="" (空字符串)
→ 状态：已开通已授权
→ 动作：原样输出 CLI 返回的模板内容（含"支付功能已开启"）
→ 禁止执行 apply-wallet、bind-wallet，流程立即结束
→ 模板已包含状态标识："✓ 支付功能已开启"
code=200 & message == "已申请开通，等待授权"
→ 状态：已申请未授权
→ 如果用户本轮反馈已完成支付宝侧授权：原样输出本次 check-wallet 结果，流程结束；禁止 apply-wallet
→ 如果用户本轮提供授权码：执行 bind-wallet -c <授权码>
→ 如果用户正在申请开通或需要授权链接：执行 apply-wallet → 原样输出模板内容（含"开启支付宝支付功能"+链接）
→ 模板已包含状态标识："开启支付宝支付功能" + 链接；check-wallet pending 输出不包含 access_url，禁止从日志补链
code=500
→ 状态：未开通
→ 动作：立即执行 apply-wallet → 原样输出模板内容（含"开启支付宝支付功能"+链接）
→ 禁止仅告知状态而不执行 apply-wallet，必须执行并原样输出
→ 模板已包含状态标识："开启支付宝支付功能" + 链接
When querying status, subsequent operations must be actively executed
When the user asks "我的支付功能开通了吗", "支付功能状态", or gives feedback such as "开通好了/授权好了/绑定好了/扫完了", check-wallet must be executed to confirm the real status. If it is already bound, output the result exactly as-is and end; if it is still "已申请开通，等待授权", output the result of this check-wallet exactly as-is and end; repeatedly executing apply-wallet is prohibited. Only when the user is applying for activation or explicitly needs the authorization link displayed again should apply-wallet be executed and the template content output exactly as-is.
Common errors (must be avoided):
- Prohibited: seeing code=200 and assuming "已开通" → you must actually check whether message is "已申请开通，等待授权", and whether access_url is empty
- Prohibited: seeing that the output text contains "申请已提交" and executing apply-wallet → you must rely on the JSON message field, and inferring from the output text is prohibited
- Prohibited: calling apply-wallet or bind-wallet while already bound → must only output the content as-is
- Prohibited: when the user is applying for activation or needs an authorization link, only informing them of the status without executing apply-wallet → must execute apply-wallet and output the template as-is
Overall execution flow
开始
↓
执行 alipay-bot check-wallet
↓
├─ code=200 & message 不是"已申请开通，等待授权" & access_url 为空 → 已开通已授权 → 原样输出命令执行返回内容→ 结束（禁止执行其他命令）
│
├─ code=200 & message 为"已申请开通，等待授权"
│ ├─ 用户反馈已完成支付宝侧授权 → 原样输出本次 check-wallet 结果 → 结束（禁止 apply-wallet）
│ ├─ 用户提供授权码 → bind-wallet -c <授权码> → 原样输出 → 结束
│ └─ 用户正在申请开通/需要授权链接 → apply-wallet → 原样输出命令执行返回内容 → STOP 等待用户完成支付宝侧授权
│
└─ code=500 → 未开通 → 立即执行 apply-wallet → 原样输出命令执行返回内容 → STOP 等待用户完成支付宝侧授权
Flow 1: Payment capability activation and authorization
Trigger conditions: the user proactively requests activation (e.g. "activate payment function", "help me enable payment capability")
Must execute check-wallet first to check the status; it is prohibited to skip this and directly execute apply-wallet or bind-wallet.
Step 1: Check wallet status
Use the exec tool to execute:
alipay-bot check-wallet
Output parameters：JSON { "code": 200|500, "access_url": "string", "message": "string" }
| code | message | access_url | Status | Action |
|---|---|---|---|---|
| 200 | Not "application submitted, awaiting authorization" | Empty "" |
Activated and authorized | Output the content returned by the executed command as-is (executing apply-wallet or bind-wallet is prohibited), end of flow |
| 200 | "Application submitted, awaiting authorization" | No judgment | Applied but not authorized | If the user reports that authorization has been completed, output the check-wallet result as-is; otherwise execute Step 2 to display/refresh the authorization link |
| 500 | - | - | Not activated | Directly execute Step 2(same handling as the previous row) |
Step 2: Apply for activation
Current turn (use the exec tool to execute):
alipay-bot apply-wallet --agent-name "<当前agent名称>"
--agent-name: taken fromAIPAY_AGENT_NAME, or take the current Agent's name; if it cannot be determined, set it to empty""
Output handling(CLI returns Markdown text + MEDIA line):
- The Markdown text is output character by character as-is; the template already includes the status identifier (e.g. "Enable Alipay payment function"). For image handling rules, see
references/image-output.md - MEDIA line: only process the MEDIA line in this output, extract the image path and remove that line, then use the message tool to send the image and text together. If no tool is available, output the text and image as-is. See
references/image-output.md - Execution failure → output the error message as-is; may retry once; after consecutive failures, enter issue feedback only when the user proactively requests feedback; it is prohibited to append feedback guidance after this CLI output
- End of this turn → STOP; adding extra signal words is prohibited
- apply-wallet output must not have guidance appended: after outputting the CLI template content and image as-is, STOP immediately. The CLI template already states "After completing activation within Alipay, I will automatically complete the binding; you can later execute check-wallet to confirm the status". It is prohibited to add on your own text not output by the CLI, such as "Please enter the authorization code to complete binding".
Subsequent turns (when the user reports that Alipay-side authorization has been completed):
Upon receiving feedback such as "activated", "authorized", "bound", "scanned", "completed", etc. → immediatelyuse the exec tool to execute check-wallet：
alipay-bot check-wallet
check-wallet subsequent handling：
| Result | Handling |
|---|---|
| code=200 and message is not "application submitted, awaiting authorization" | Output the content returned by this check-wallet as-is, end of flow |
| code=200 and message is "Application submitted, awaiting authorization" | Output the content returned by this check-wallet as-is, and the process ends; do not repeatedly apply-wallet, wait for the user to confirm later or provide an authorization code |
| code=500 | Output the content returned by this check-wallet as-is; if the user explicitly requests to re-apply, then execute apply-wallet |
| CLI returns a format error/command failure | Output the error message as-is; do not append guidance, and the process ends |
Subsequent rounds (when the user sends an authorization code):
Received 开启支付功能xxxx、开启支付功能：xxxx or 绑定AI钱包 xxxx → extract the authorization code, immediatelyUse the exec tool to execute bind-wallet：
alipay-bot bind-wallet -c <授权码>
Authorization code handling rules: pass the authorization code provided by the user directly to bind-wallet, and let the CLI verify its validity. Do not perform local format pre-validation or refuse to call bind-wallet.
Subsequent decision logic：
| Result | Handling |
|---|---|
| Execution succeeded | Output the content returned by the CLI as-is;the process ends immediately, do not execute any further commands, and do not append text not output by the CLI such as "Authorization completed/Please re-initiate payment" |
| Execution failed (authorization code expired/invalid) | Output the content returned by the CLI as-is;do not automatically re-execute apply-wallet, do not append guidance, and the process ends immediately |
| CLI returns a format error | Output the error message returned by the CLI as-is;do not append guidance, and the process ends immediately |
| Consecutive failures 2 times+ | If the user actively requests feedback, then proceed to problem feedback (see references/feedback.md); do not append feedback guidance after this CLI output |
Hard termination rules after bind-wallet：
- bind-wallet succeeded → output template T3 as-is → end immediately, do not execute any subsequent commands(including apply-wallet, check-wallet, etc.)
- bind-wallet failed → output the failure content as-is → end immediately, do not append retry guidance, and do not automatically re-apply-wallet
Process 2: The user directly provides an authorization code (highest-priority decision branch)
Trigger condition: an authorization code appears in the user message (format such as 开启支付功能 xxxx、开启支付功能：xxxx、绑定AI钱包 xxxx、461417 and other combinations of numbers/letters)
⚠️ This is the most common failure scenario. When the user provides an authorization code, bind-wallet must be called directly; do not apply-wallet first.
Decision flow chart
用户提供了六位数字的授权码
↓
执行 check-wallet（仅一次）
↓
┌─ code=200 & message 不是"已申请开通，等待授权" & access_url="" → 已开通已授权
│ → 原样输出模板T1（含"支付功能已开启"）→ 结束
│ → 【禁止】bind-wallet、apply-wallet
│
├─ code=200 & message 为"已申请开通，等待授权" → 已申请未授权
│ → 直接执行 bind-wallet -c <授权码>
│ → 【禁止】apply-wallet（已申请不需要重新申请！）
│ → 【禁止】再次 check-wallet（状态已确认！）
│ → bind-wallet 成功 → 原样输出模板T3 → 结束
│ → bind-wallet 失败 → 原样输出模板T4 → 结束，禁止追加重试引导
│
└─ code=500 → 未开通
→ 执行 apply-wallet --agent-name "<agent>"
→ 原样输出模板T2 → 等待用户扫码后重新输入授权码
→ 【禁止】bind-wallet（未开通无法绑定）
Step 1: Check wallet status
Use the exec tool to execute:
alipay-bot check-wallet
Step 2: Handle according to status
⚠️ Highest-priority rule: applied but not authorized + user provided an authorization code = directly bind-wallet, absolutely do not apply-wallet
| Status | check-wallet returns | User provided an authorization code | Must execute | Must not execute |
|---|---|---|---|---|
| Activated and authorized | code=200 & message is not "Application submitted, awaiting authorization" & access_url is empty | Ignore the authorization code | Output the returned content as-is | bind-wallet; apply-wallet |
| Applied but not authorized | code=200 & message is "Application submitted, waiting for authorization" | Used directly for binding | bind-wallet -c <授权码> |
apply-wallet(Already applied, no need to reapply) |
| Not activated | code=500 | Ignore the authorization code | apply-wallet --agent-name "<agent>" |
bind-wallet (cannot bind if not activated) |
Typical errors (high-frequency failure points):
| Error | Scenario | Correct approach |
|---|---|---|
| check-wallet (unauthorized) → apply-wallet → end | User provided an authorization code | check-wallet (unauthorized) → bind-wallet -c <authorization code> |
| check-wallet (unauthorized) → check-wallet → bind-wallet | Repeated status checks | check-wallet → bind-wallet -c <authorization code> (do not re-check) |
| bind-wallet (success) → apply-wallet | Extra commands after success | bind-wallet (success) → output as-is → end |
Process 3: Unbind/Disable payment capability
Trigger conditions: User requests to disable the Alipay payment feature, cancel Alipay authorization, or unbind the Alipay wallet
Step 1: Execute the disable command
Use the exec tool to execute:
alipay-bot close-wallet
Step 2: Handle based on the returned content
| Scenario | Command return | Handling |
|---|---|---|
| Valid binding | Disable link + MEDIA | Output as-is, wait for user operation feedback, then execute check-wallet to confirm the latest status |
| Not bound | Reopen link + MEDIA | Display the command's returned content verbatim; do not interpret it as an error |
| Authorization expired | Expiration notice + reopen link + MEDIA | Keep the command's returned content verbatim; no abbreviating or summarizing |
Output handling for all scenarios：
- Output Markdown text (including links) verbatim, character by character
- For image handling rules, see
references/image-output.md: only process MEDIA lines or Markdown images in this output; after extracting the path from a MEDIA line, remove it, and use the message tool to send the image integrated with the text - Do not add any explanations beyond the command's returned content
Output keyword contract
The template content returned by the CLI already includes status identifiers; outputting it as-is satisfies the requirement. The following keywords are used to verify whether the output is correct, not as a requirement to add anything extra:
| Scenario | Keywords already included in the template |
|---|---|
| Activated and authorized | "Payment feature is enabled" |
| Not activated/not authorized guidance | "Enable the Alipay payment feature" + link |
| Binding successful | "Enabled successfully" / "The Alipay payment feature has been enabled successfully" |
| Binding failed | "Authorization failed" / "Please try again" |
| System error | "The wind is too strong" or server-side error text |
Do not repeatedly execute commands that have already been completed: If the current session has already executed apply-wallet and provided the authorization link, do not execute it repeatedly in subsequent turns. When the user reports that Alipay-side authorization has been completed, execute check-wallet; if it is still pending, output the result of this check-wallet as-is.
Output signal word checklist (mandatory)
The template content returned by the CLI already contains the status identifier, so output it as-is. The following is used to verify whether the output is correct:
| Step | Keywords already contained in the template |
|---|---|
| check-wallet returns authorized | "Payment function has been enabled" |
| check-wallet returns unauthorized/not activated | - |
| apply-wallet succeeds | "Enable Alipay payment function" + link |
| bind-wallet succeeds | "Enabled successfully" / "Alipay payment function has been enabled successfully" |
| bind-wallet fails | "Authorization failed" / "Please try again" |
Self-check questions (must be answered after each step is executed):
- After check-wallet is executed: Did I execute it only once? Did I immediately take the correct action based on the result?
- After apply-wallet is executed: Did I output the template content returned by the CLI as-is (including "Enable Alipay payment function" and the link)?
- After bind-wallet is executed (success): Did I output the template content returned by the CLI as-is (including "Enabled successfully")?
- After bind-wallet is executed (failure): Did I output the template content returned by the CLI as-is (including "Authorization failed")?
- Did I additionally add signal words such as "authorization link" or "binding successful" before the CLI output? (If yes, that is an error)
- Did I repeatedly execute check-wallet or apply-wallet? (If the answer is "yes", that is an error)
Gotchas (high-frequency errors, must be avoided)
-
Repeated execution of check-wallet: After executing check-wallet, immediately take action based on the result; do not execute it repeatedly
- Incorrect:
check-wallet → check-wallet → apply-wallet - Correct:
check-wallet → apply-walletorcheck-wallet → 告知已开通
- Incorrect:
-
Repeated execution of apply-wallet: apply-wallet only needs to be executed once; after returning the authorization link, wait for the user to complete authorization within Alipay
- Incorrect:
apply-wallet → apply-wallet → apply-wallet - Correct:
apply-wallet → 输出授权链接 → 等待用户反馈已完成授权 → check-wallet
- Incorrect:
-
Executing apply-wallet or bind-wallet when already authorized: When check-wallet returns code=200, message is not "Application submitted, waiting for authorization", and access_url=""
- Incorrect: Execute apply-wallet or bind-wallet
- Correct: Output template T1 as-is (including "Payment function has been enabled"), and the process ends
-
Outputting only text when applying for activation: When the user is applying for activation or needs an authorization link, outputting only the text "unauthorized" cannot help the user complete authorization
- Incorrect: Output "Your wallet is unauthorized" and then stop
- Correct: Execute apply-wallet and output template T2 as-is
-
Not calling bind-wallet after receiving the authorization code: When the user has provided the authorization code, bind-wallet should be called directly
- Incorrect: After the user enters the authorization code, only execute apply-wallet and do not execute bind-wallet
- Correct: After the user enters the authorization code, execute
bind-wallet -c <授权码>
-
After the user says "activation is complete/authorization is complete/binding is complete", continue waiting for the authorization code: The new flow supports automatic binding on the Alipay side, and check-wallet should be executed to confirm
- Incorrect: Prompt the user to enter the authorization code, or execute apply-wallet again
- Correct: Execute
check-wallet. If already bound, output as-is and end; if still pending, output the result of this check-wallet as-is
-
When already applied but not authorized and an authorization code is provided, apply-wallet first: When check-wallet returns unauthorized and the user has provided an authorization code
- Incorrect:
check-wallet(未授权) → apply-wallet → bind-wallet - Correct:
check-wallet(未授权) → bind-wallet -c <授权码>(skip apply-wallet; no need to reapply if already applied)
- Incorrect:
-
After bind-wallet succeeds, continue executing the command: After bind-wallet returns success, the flow must end immediately
- Incorrect:
bind-wallet(成功) → apply-walletorbind-wallet(成功) → check-wallet - Correct:
bind-wallet(成功) → 原样输出 → 结束
- Incorrect:
-
After bind-wallet fails, automatically reapply: After bind-wallet fails, do not automatically reapply
- Incorrect:
bind-wallet(失败) → apply-wallet - Correct:
bind-wallet(失败) → 原样输出失败信息 → 结束，等待用户主动重试
- Incorrect:
-
Skip wallet status confirmation: In this skill's standalone wallet activation, authorization, and unbinding confirmation flow, the first step must be check-wallet; this rule does not apply to the main payment flow of alipay-payment-skill
-
Add extra signal words: The template returned by the CLI already includes status markers; adding extra ones is prohibited
- After apply-wallet succeeds, the template already includes "Enable Alipay payment function"; adding an extra "authorization link" is prohibited
- After bind-wallet succeeds, the template already includes "activation successful"; adding an extra "binding successful" is prohibited
-
Truncate the URL or rewrite the CLI output: The URL and Markdown text must be preserved exactly, character for character
-
Perform local format validation on the authorization code: Pass the authorization code provided by the user directly to the CLI, and let the CLI determine its validity
-
After apply-wallet, append binding guidance on your own: After apply-wallet outputs the authorization link, only pass through the CLI output as-is; adding text not output by the CLI, such as "Please enter the authorization code to complete binding", is prohibited
-
Use this skill to intercept the main payment flow: When the user requests payment and an Alipay order or 402 material already exists, the payment command should be executed by alipay-payment-skill; do not execute apply-wallet first because you guess the wallet is not bound, and do not add text not output by the CLI, such as "authorization must be completed first" or "authorization has not yet been completed"
Boundary with alipay-payment-skill
The main trunk of the payment flow is executed by alipay-payment-skill executing submit-payment or 402-buyer-pay. Before payment, do not use this skill to replace the payment command, and do not execute check-wallet first to intercept payment because you guess the wallet is not bound.
When the user explicitly switches from a payment scenario to "activate/authorize the wallet first", or when the payment command explicitly returns that the standalone wallet flow must be entered:
- Use the
exectool to executecheck-walletonce to confirm the status - Perform the corresponding operation according to the actual status and output the template content as-is:
- code=200, message is not "Activation applied, waiting for authorization" and access_url is empty → output template T1 as-is, and the flow ends
- code=200, when the message is "Application submitted, awaiting authorization" → execute apply-wallet when the user needs an authorization link; execute bind-wallet when the user provides an authorization code
- code=500 → execute apply-wallet
- When the user reports "activation is done/authorization is done/binding is done/scanning is done", execute check-wallet once; if it is still pending, output the result of this check-wallet as-is, and do not repeatedly execute apply-wallet
- This skill does not execute
submit-payment、query-payment-status、402-buyer-payand other payment commands
Important：
- The template returned by the CLI already contains the status indicator; do not add additional signal words
- When check-wallet is already bound, the returned content is the confirmation result; do not add an additional "authorization successful"
- After bind-wallet succeeds, the template already contains "activation successful"; do not add an additional "binding successful" or "authorization successful"
Issue feedback
When encountering a problem that cannot be solved on your own (repeated activation/authorization failures, unknown error codes, unusable links, etc.), follow the process in references/feedback.md .