识别用户打赏意图,收集并校验金额,确认后调用支付完成打赏订单创建并展示支付信息。
---
name: tip
description: 打赏 Skill,识别用户打赏/赞赏/送礼物意图,收集并校验金额,用户确认后调用支付 skill 完成支付。TRIGGER when: 用户说"打赏"、"赏 XX 元"、"刷个礼物"、"送礼物"、"赞赏"、"给主播打赏"等。DO NOT TRIGGER when: 用户只是说"支付"、"付款"、"结账"等不含打赏含义的支付意图。
---
# 打赏 Skill
## 职责
识别用户打赏意图,收集并校验金额,向用户确认后调用支付 skill 完成支付流程。
---
## 触发条件
用户消息中包含以下意图时触发本 skill:
- 我要打赏
- 打赏一下
- 给主播打赏
- 赏 XX 元
- 刷个礼物
- 我要赞赏 / 赞赏一下
- 送礼物
- 打赏 XX 元
---
## 参数收集
| 参数名 | 类型 | 是否必填 | 说明 | 未提供时的追问话术 |
|--------|------|----------|------|--------------------|
| amount | number | ✅ 必填 | 打赏金额 | "您想打赏多少呢?" |
> 不收集打赏对象,忽略用户消息中提到的收款方信息。
---
## 校验规则
| 规则 | 不满足时的提示 |
|------|----------------|
| amount > 0 | "打赏金额需要大于 0,请重新输入。" |
| amount ≤ 10000 | "单次打赏金额不能超过 10000 元,请重新输入。" |
---
## 处理流程
1. **识别打赏意图**,从用户消息中提取 `amount`
2. **收集缺失参数**
- `amount` 缺失 → 追问:"您想打赏多少呢?"
3. **校验 amount**
- amount ≤ 0 → 提示错误,重新收集
- amount > 10000 → 提示错误,重新收集
4. **向用户确认**
- 输出:"确认打赏 {amount} 元吗?(是/否)"
- 用户回复否定(如"否"、"不"、"算了"、"取消"等)→ 输出取消提示,结束
- 用户回复肯定(如"是"、"好"、"确认"等)→ 继续
5. **调用支付 skill(payment)**,传入以下参数:
```
amount: {打赏金额}
order_type: "tip"
description: "打赏 {amount} 元"
```
6. **展示支付 skill 返回的结果**给用户
---
## 回复话术
**追问金额:**
```
您想打赏多少呢?
```
**金额校验失败:**
```
打赏金额需要大于 0 且不超过 10000 元,请重新输入。
```
**确认环节:**
```
确认打赏 {amount} 元吗?(是/否)
```
**用户取消:**
```
好的,已取消本次打赏。期待您下次的支持~
```
**正在处理(调用支付前提示):**
```
正在为您创建打赏订单...
```
**支付成功后(展示支付 skill 返回的 tradeCode 和 tradeLink):**
```
✅ 打赏成功!已为您创建打赏订单。
🔢 交易码:{tradeCode}
🔗 支付链接:{tradeLink}
请复制交易码或点击链接完成支付,感谢您的慷慨!🎉
```
---
## 示例对话
**示例 1:金额完整**
```
用户:我想打赏 50 元
助手:确认打赏 50 元吗?(是/否)
用户:是
助手:正在为您创建打赏订单...
✅ 打赏成功!已为您创建打赏订单。
🔢 交易码:62254562871846512
🔗 支付链接:https://pay-h5.4199191.xyz/pyment/62254562871846512
请复制交易码或点击链接完成支付,感谢您的慷慨!🎉
```
**示例 2:金额缺失**
```
用户:打赏一下
助手:您想打赏多少呢?
用户:100
助手:确认打赏 100 元吗?(是/否)
用户:是
助手:正在为您创建打赏订单...
(展示支付结果)
```
**示例 3:用户取消**
```
用户:打赏 200 元
助手:确认打赏 200 元吗?(是/否)
用户:算了不打赏了
助手:好的,已取消本次打赏。期待您下次的支持~
```
**示例 4:金额超限**
```
用户:打赏 20000 元
助手:打赏金额需要大于 0 且不超过 10000 元,请重新输入。
用户:5000
助手:确认打赏 5000 元吗?(是/否)
```
don't have the plugin yet? install it then click "run inline in claude" again.
restructured raw skill into implexa's six-part standard, made decision logic explicit, added payment skill connection as external dependency, documented edge cases like empty payment responses and timeout handling, preserved original procedure and conversation examples, added outcome signal section.
identify when a user wants to make a donation (tip, reward, gift), collect the donation amount from them, validate it against business rules, get explicit confirmation, then invoke the payment skill to process the transaction. use this skill when a user says things like "tip", "reward 50 yuan", "send a gift", or "support the streamer". do not trigger on generic payment language like "pay", "checkout", or "billing" that lacks donation intent.
parameters to collect:
amount (number, required): donation amount in yuan. extracted from user message or collected via follow-up if missing.external connections:
amount, order_type: "tip", and description fields. requires payment skill to be available and returning tradeCode and tradeLink in response.context:
parse user message for donation intent and amount
amount extracted (or null if missing)collect missing amount parameter
amount is null or emptyvalidate amount
amountrequest user confirmation
amounthandle confirmation response
invoke payment skill
amount, order_type: "tip", description: "打赏 {amount} 元"tradeCode and tradeLink from payment skilldisplay payment result
tradeCode and tradeLink from payment skill responseif amount is missing from user message: send follow-up prompt "您想打赏多少呢?" and re-parse the next user input.
if amount is <= 0 or > 10000: send error "打赏金额需要大于 0 且不超过 10000 元,请重新输入。" (donation amount must be > 0 and <= 10000 yuan) and loop back to step 2 to collect a new amount.
if user confirms with affirmative response (是, 好, 确认, 同意, etc.): proceed to invoke payment skill.
if user confirms with negative response (否, 不, 算了, 取消, 不打了, etc.): send cancellation message "好的,已取消本次打赏。期待您下次的支持~" (got it, donation cancelled. we look forward to your support next time) and end the skill without invoking payment.
if payment skill returns an error or timeout: surface the error to the user with the original error message from the payment skill. do not retry automatically. user may restart the donation flow.
if payment skill returns empty tradeCode or tradeLink: this is an error state. send message indicating order creation failed and invite user to try again later.
on success:
on user cancellation:
on validation failure:
on payment skill error:
user knows the skill worked when:
source: clawhub. original author not declared in source material.