@kaleidorg/mind 0.4.0 → 0.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/funnel.d.ts +19 -0
- package/dist/funnel.d.ts.map +1 -1
- package/dist/funnel.js +48 -10
- package/dist/funnel.js.map +1 -1
- package/dist/index.d.ts +5 -2
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +10 -3
- package/dist/index.js.map +1 -1
- package/dist/kaleidoswap/contract.d.ts +3 -3
- package/dist/kaleidoswap/contract.d.ts.map +1 -1
- package/dist/kaleidoswap/contract.js +16 -4
- package/dist/kaleidoswap/contract.js.map +1 -1
- package/dist/knowledge/bitcoin-copilot.d.ts.map +1 -1
- package/dist/knowledge/bitcoin-copilot.js +102 -0
- package/dist/knowledge/bitcoin-copilot.js.map +1 -1
- package/dist/knowledge/btc-map.d.ts +14 -17
- package/dist/knowledge/btc-map.d.ts.map +1 -1
- package/dist/knowledge/btc-map.js +66 -266
- package/dist/knowledge/btc-map.js.map +1 -1
- package/dist/lsps1/contract.d.ts.map +1 -1
- package/dist/lsps1/contract.js +28 -10
- package/dist/lsps1/contract.js.map +1 -1
- package/dist/recipe/buy-asset-channel.d.ts +26 -0
- package/dist/recipe/buy-asset-channel.d.ts.map +1 -0
- package/dist/recipe/buy-asset-channel.js +112 -0
- package/dist/recipe/buy-asset-channel.js.map +1 -0
- package/dist/recipe/kaleidoswap-atomic.d.ts +26 -18
- package/dist/recipe/kaleidoswap-atomic.d.ts.map +1 -1
- package/dist/recipe/kaleidoswap-atomic.js +101 -63
- package/dist/recipe/kaleidoswap-atomic.js.map +1 -1
- package/dist/recipe/kaleidoswap-channel-order.d.ts +35 -0
- package/dist/recipe/kaleidoswap-channel-order.d.ts.map +1 -0
- package/dist/recipe/kaleidoswap-channel-order.js +493 -0
- package/dist/recipe/kaleidoswap-channel-order.js.map +1 -0
- package/dist/recipe/kaleidoswap-price.d.ts +21 -0
- package/dist/recipe/kaleidoswap-price.d.ts.map +1 -0
- package/dist/recipe/kaleidoswap-price.js +57 -0
- package/dist/recipe/kaleidoswap-price.js.map +1 -0
- package/dist/recipe/runner.d.ts +7 -1
- package/dist/recipe/runner.d.ts.map +1 -1
- package/dist/recipe/runner.js +115 -29
- package/dist/recipe/runner.js.map +1 -1
- package/dist/recipe/swap.d.ts +26 -1
- package/dist/recipe/swap.d.ts.map +1 -1
- package/dist/recipe/swap.js +108 -13
- package/dist/recipe/swap.js.map +1 -1
- package/dist/recipe/types.d.ts +25 -1
- package/dist/recipe/types.d.ts.map +1 -1
- package/dist/skills/registry.d.ts +33 -1
- package/dist/skills/registry.d.ts.map +1 -1
- package/dist/skills/registry.js +45 -1
- package/dist/skills/registry.js.map +1 -1
- package/package.json +1 -1
- package/skills/README.md +3 -0
- package/skills/kaleido-lsps/SKILL.md +101 -43
- package/skills/kaleido-trading/SKILL.md +81 -31
- package/skills/merchant-finder/SKILL.md +96 -66
- package/skills/rgb-lightning-node/SKILL.md +108 -0
- package/skills/wallet-assistant/SKILL.md +32 -21
- package/src/funnel.ts +66 -11
- package/src/index.ts +14 -2
- package/src/kaleidoswap/contract.test.ts +7 -2
- package/src/kaleidoswap/contract.ts +27 -5
- package/src/knowledge/bitcoin-copilot.ts +111 -0
- package/src/knowledge/btc-map.test.ts +53 -96
- package/src/knowledge/btc-map.ts +72 -287
- package/src/lsps1/contract.ts +32 -14
- package/src/recipe/buy-asset-channel.test.ts +148 -0
- package/src/recipe/buy-asset-channel.ts +118 -0
- package/src/recipe/kaleidoswap-atomic.test.ts +134 -61
- package/src/recipe/kaleidoswap-atomic.ts +112 -66
- package/src/recipe/kaleidoswap-channel-order.test.ts +333 -0
- package/src/recipe/kaleidoswap-channel-order.ts +548 -0
- package/src/recipe/kaleidoswap-price.ts +68 -0
- package/src/recipe/recipe.test.ts +61 -5
- package/src/recipe/runner.ts +128 -31
- package/src/recipe/swap.ts +109 -13
- package/src/recipe/types.ts +25 -1
- package/src/skills/registry.ts +52 -1
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"registry.js","sourceRoot":"","sources":["../../src/skills/registry.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;
|
|
1
|
+
{"version":3,"file":"registry.js","sourceRoot":"","sources":["../../src/skills/registry.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAMH,yEAAyE;AACzE,MAAM,CAAC,MAAM,mBAAmB,GAAG,sBAAsB,CAAC;AAE1D;;;;;;;;;;;GAWG;AACH,oEAAoE;AACpE,SAAS,OAAO,CAAC,CAAS;IACxB,MAAM,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,CAAC;IACnB,IAAI,CAAC,CAAC,CAAC,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,EAAE,CAAC;QACrF,OAAO,CAAC,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC;IACxB,CAAC;IACD,OAAO,CAAC,CAAC;AACX,CAAC;AAED,MAAM,UAAU,UAAU,CAAC,QAAgB,EAAE,UAA6B;IACxE,MAAM,EAAE,GAAG,QAAQ,CAAC,KAAK,CAAC,0CAA0C,CAAC,CAAC;IACtE,MAAM,IAAI,GAA2B,EAAE,CAAC;IACxC,IAAI,IAAI,GAAG,QAAQ,CAAC;IACpB,IAAI,EAAE,EAAE,CAAC;QACP,IAAI,GAAG,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;QACnB,KAAK,MAAM,IAAI,IAAI,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC;YAC7C,0EAA0E;YAC1E,0EAA0E;YAC1E,MAAM,CAAC,GAAG,IAAI,CAAC,KAAK,CAAC,uCAAuC,CAAC,CAAC;YAC9D,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;gBAAE,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,CAAC,GAAG,OAAO,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC;QAChE,CAAC;IACH,CAAC;IACD,MAAM,IAAI,GAAG,CAAC,CAAU,EAAE,EAAE,CAC1B,CAAC;QACC,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,MAAM,CAAC,OAAO,CAAC;QACnD,CAAC,CAAC,SAAS,CAAC;IAEhB,IAAI,CAAC,IAAI,CAAC,IAAI;QAAE,MAAM,IAAI,KAAK,CAAC,wCAAwC,CAAC,CAAC;IAE1E,8DAA8D;IAC9D,MAAM,KAAK,GAAG,IAAI,GAAG,CAAC,CAAC,MAAM,EAAE,aAAa,EAAE,OAAO,EAAE,UAAU,CAAC,CAAC,CAAC;IACpE,MAAM,QAAQ,GAA2B,EAAE,CAAC;IAC5C,KAAK,MAAM,CAAC,CAAC,EAAE,CAAC,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,IAAI,CAAC;QAAE,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC;YAAE,QAAQ,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC;IAE9E,OAAO;QACL,IAAI,EAAE,IAAI,CAAC,IAAI;QACf,WAAW,EAAE,IAAI,CAAC,WAAW,IAAI,EAAE;QACnC,YAAY,EAAE,IAAI,CAAC,IAAI,EAAE;QACzB,KAAK,EAAE,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC;QACvB,QAAQ,EAAE,IAAI,CAAC,IAAI,CAAC,QAAQ,CAAC;QAC7B,QAAQ,EAAE,MAAM,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,SAAS;QAC7D,UAAU,EAAE,UAAU,IAAI,UAAU,CAAC,MAAM,CAAC,CAAC,CAAC,UAAU,CAAC,CAAC,CAAC,SAAS;KACrE,CAAC;AACJ,CAAC;AAED,0DAA0D;AAC1D,MAAM,SAAS,GAAG,IAAI,GAAG,CAAC;IACxB,KAAK,EAAE,KAAK,EAAE,KAAK,EAAE,KAAK,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM;IAC1E,MAAM,EAAE,KAAK,EAAE,KAAK,EAAE,KAAK,EAAE,KAAK,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE,KAAK;IAC3E,MAAM,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM;CAC/D,CAAC,CAAC;AAEH,qDAAqD;AACrD,SAAS,QAAQ,CAAC,CAAS;IACzB,OAAO,CAAC,CAAC,OAAO,CAAC,qBAAqB,EAAE,MAAM,CAAC,CAAC;AAClD,CAAC;AAED;;;;;GAKG;AACH,SAAS,cAAc,CAAC,KAAa,EAAE,OAAe;IACpD,MAAM,CAAC,GAAG,OAAO,CAAC,WAAW,EAAE,CAAC,IAAI,EAAE,CAAC;IACvC,IAAI,CAAC,CAAC;QAAE,OAAO,KAAK,CAAC;IACrB,OAAO,IAAI,MAAM,CAAC,MAAM,QAAQ,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;AACxD,CAAC;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,eAAe,GAAkB;IAC5C,MAAM,CAAC,KAAK,EAAE,MAAM;QAClB,MAAM,CAAC,GAAG,KAAK,CAAC,WAAW,EAAE,CAAC;QAC9B,MAAM,KAAK,GAAG,IAAI,GAAG,CACnB,CAAC,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAChE,CAAC;QACF,IAAI,IAAI,GAAiB,IAAI,CAAC;QAC9B,IAAI,SAAS,GAAG,CAAC,CAAC;QAClB,KAAK,MAAM,KAAK,IAAI,MAAM,EAAE,CAAC;YAC3B,MAAM,QAAQ,GAAG,GAAG,KAAK,CAAC,WAAW,IAAI,CAAC,KAAK,CAAC,QAAQ,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,WAAW,EAAE,CAAC;YAC1F,MAAM,QAAQ,GAAG,QAAQ,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC;YACxF,IAAI,KAAK,GAAG,CAAC,CAAC;YACd,KAAK,MAAM,CAAC,IAAI,QAAQ;gBAAE,IAAI,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC;oBAAE,KAAK,IAAI,CAAC,CAAC;YACvD,qEAAqE;YACrE,qEAAqE;YACrE,qDAAqD;YACrD,KAAK,MAAM,CAAC,IAAI,KAAK,CAAC,QAAQ,IAAI,EAAE;gBAAE,IAAI,cAAc,CAAC,CAAC,EAAE,CAAC,CAAC;oBAAE,KAAK,IAAI,CAAC,CAAC;YAE3E,qEAAqE;YACrE,uEAAuE;YACvE,mCAAmC;YACnC,IAAI,2GAA2G,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;gBACxH,MAAM,SAAS,GAAG,CAAC,KAAK,CAAC,WAAW,GAAG,GAAG,GAAG,CAAC,KAAK,CAAC,QAAQ,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC,WAAW,EAAE,CAAC;gBAC7F,IAAI,iGAAiG,CAAC,IAAI,CAAC,SAAS,CAAC;oBAAE,KAAK,IAAI,GAAG,CAAC;YACtI,CAAC;YAED,IAAI,KAAK,GAAG,SAAS,EAAE,CAAC;gBACtB,SAAS,GAAG,KAAK,CAAC;gBAClB,IAAI,GAAG,KAAK,CAAC;YACf,CAAC;QACH,CAAC;QACD,+DAA+D;QAC/D,OAAO,SAAS,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,IAAI,CAAC;IACtC,CAAC;CACF,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,UAAU,4BAA4B,CAC1C,UAA8B,EAC9B,QAA2D,EAAE;IAE7D,mEAAmE;IACnE,oEAAoE;IACpE,iEAAiE;IACjE,kEAAkE;IAClE,kEAAkE;IAClE,KAAK,UAAU,CAAC,CAAC,gDAAgD;IACjE,OAAO,eAAe,CAAC;AACzB,CAAC;AAED,MAAM,OAAO,aAAa;IACP,MAAM,GAAY,EAAE,CAAC;IACrB,QAAQ,CAAgB;IAEzC,YAAY,SAAkB,EAAE,EAAE,WAA0B,eAAe;QACzE,IAAI,CAAC,MAAM,GAAG,CAAC,GAAG,MAAM,CAAC,CAAC;QAC1B,IAAI,CAAC,QAAQ,GAAG,QAAQ,CAAC;IAC3B,CAAC;IAED,GAAG,CAAC,KAAY;QACd,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;QACxB,OAAO,IAAI,CAAC;IACd,CAAC;IAED,uEAAuE;IACvE,WAAW,CAAC,QAAgB,EAAE,UAA6B;QACzD,OAAO,IAAI,CAAC,GAAG,CAAC,UAAU,CAAC,QAAQ,EAAE,UAAU,CAAC,CAAC,CAAC;IACpD,CAAC;IAED,yEAAyE;IACzE,UAAU;QACR,OAAO,IAAI,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,EAAE,CAC/B,CAAC,CAAC,CAAC,UAAU,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,EAAE,GAAG,CAAC,EAAE,KAAK,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,CAC3D,CAAC;IACJ,CAAC;IAED,yEAAyE;IACzE,SAAS,CAAC,IAAY,EAAE,KAAc;QACpC,MAAM,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,eAAe,EAAE,EAAE,CAAC,CAAC;QAC/C,KAAK,MAAM,CAAC,IAAI,IAAI,CAAC,MAAM,EAAE,CAAC;YAC5B,IAAI,KAAK,IAAI,CAAC,CAAC,IAAI,KAAK,KAAK;gBAAE,SAAS;YACxC,MAAM,GAAG,GAAG,CAAC,CAAC,CAAC,UAAU,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,IAAI,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC,CAAC;YACjF,IAAI,GAAG;gBAAE,OAAO,GAAG,CAAC;QACtB,CAAC;QACD,OAAO,SAAS,CAAC;IACnB,CAAC;IAED,IAAI;QACF,OAAO,CAAC,GAAG,IAAI,CAAC,MAAM,CAAC,CAAC;IAC1B,CAAC;IAED,GAAG,CAAC,IAAY;QACd,OAAO,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC,CAAC;IAClD,CAAC;IAED,8DAA8D;IAC9D,MAAM,CAAC,KAAa;QAClB,OAAO,IAAI,CAAC,QAAQ,CAAC,MAAM,CAAC,KAAK,EAAE,IAAI,CAAC,MAAM,CAAC,CAAC;IAClD,CAAC;IAED;;;;OAIG;IACH,OAAO,CAAC,IAAY,EAAE,KAAmB;QACvC,IAAI,CAAC,KAAK;YAAE,OAAO,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC;QAEpC,IAAI,MAAM,GAAG,GAAG,IAAI,wBAAwB,KAAK,CAAC,IAAI,KAAK,KAAK,CAAC,YAAY,EAAE,CAAC,IAAI,EAAE,CAAC;QAEvF,2EAA2E;QAC3E,6DAA6D;QAC7D,MAAM,IAAI,GAAG,KAAK,CAAC,UAAU,IAAI,EAAE,CAAC;QACpC,IAAI,IAAI,CAAC,MAAM,EAAE,CAAC;YAChB,MAAM,KAAK,GAAG,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YACjD,MAAM;gBACJ,mEAAmE,KAAK,IAAI;oBAC5E,+CAA+C,mBAAmB,cAAc;oBAChF,2BAA2B,IAAI,CAAC,CAAC,CAAE,CAAC,IAAI,+BAA+B,CAAC;QAC5E,CAAC;QAED,wEAAwE;QACxE,MAAM,YAAY,GAAG,KAAK,CAAC,KAAK;YAC9B,CAAC,CAAC,IAAI,CAAC,MAAM;gBACX,CAAC,CAAC,CAAC,GAAG,KAAK,CAAC,KAAK,EAAE,mBAAmB,CAAC;gBACvC,CAAC,CAAC,KAAK,CAAC,KAAK;YACf,CAAC,CAAC,SAAS,CAAC;QACd,OAAO,EAAE,MAAM,EAAE,YAAY,EAAE,CAAC;IAClC,CAAC;CACF"}
|
package/package.json
CHANGED
package/skills/README.md
CHANGED
|
@@ -75,5 +75,8 @@ Then per query: `const skill = registry.select(query)` →
|
|
|
75
75
|
tools (in-process WDK on mobile, MCP on desktop).
|
|
76
76
|
- **merchant-finder/** — find Bitcoin-accepting merchants via BTC Map. Live
|
|
77
77
|
data when the host injects a fetch + location; bundled offline list otherwise.
|
|
78
|
+
Intentionally model-leveraging (updated playbook + pluggable selectors) for
|
|
79
|
+
natural language understanding of vague location queries, context use,
|
|
80
|
+
post-processing results, and hybrid RAG.
|
|
78
81
|
- **paid-data/** — fetch L402-paywalled resources via `fetch_paid_resource`.
|
|
79
82
|
- **kaleido-trading/** — prices, quotes, atomic swaps, LSP channels.
|
|
@@ -1,56 +1,114 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: kaleido-lsps
|
|
3
|
-
description: "Buy inbound Lightning channel capacity from a Lightning Service Provider (LSPS1). Quote, estimate fees,
|
|
4
|
-
tools: lsp_get_info, lsp_get_network_info, lsp_estimate_fees, lsp_create_order, lsp_get_order
|
|
5
|
-
triggers: inbound, liquidity, channel order, lsp, lsps1, receive limit, can't receive, open channel
|
|
3
|
+
description: "Buy inbound Lightning channel capacity from a Lightning Service Provider (LSPS1). Quote a channel, estimate fees, place a channel order, and check order status. Triggers when the user wants inbound liquidity, says they can't receive a payment, needs a channel, asks about LSP fees, or wants to check the status of a channel order / LSP order."
|
|
4
|
+
tools: lsp_get_info, lsp_get_network_info, lsp_estimate_fees, lsp_create_order, lsp_get_order, rln_get_node_info, rln_pay_invoice
|
|
5
|
+
triggers: inbound, liquidity, channel order, lsp, lsps1, receive limit, can't receive, open channel, channel from, check status, order status, check the order, channel status, lsp status, check my channel
|
|
6
6
|
metadata:
|
|
7
7
|
author: kaleidoswap
|
|
8
|
-
version: "0.
|
|
8
|
+
version: "0.2.0"
|
|
9
9
|
---
|
|
10
10
|
|
|
11
11
|
# Lightning channel orders (LSPS1)
|
|
12
12
|
|
|
13
13
|
Buy inbound Lightning channel capacity from a Lightning Service Provider when
|
|
14
|
-
the user can't receive a payment
|
|
15
|
-
|
|
16
|
-
KaleidoSwap maker by default
|
|
14
|
+
the user can't receive a payment, wants a bigger receive limit, or just wants
|
|
15
|
+
to open a new channel from the LSP. The host binds these to whichever LSP it
|
|
16
|
+
talks to — the KaleidoSwap maker by default. Tool names are LSP-agnostic
|
|
17
|
+
(`lsp_*`), so the same skill works against any LSPS1-compliant LSP.
|
|
17
18
|
|
|
18
|
-
## Critical rules
|
|
19
|
+
## Critical rules — these override everything else
|
|
19
20
|
|
|
20
|
-
You have **no knowledge of LSP fees, channel sizes, or order
|
|
21
|
-
number, capacity, fee,
|
|
22
|
-
returned in the CURRENT turn. Never quote a fee from
|
|
23
|
-
order completed without calling `lsp_get_order`.
|
|
24
|
-
previous turn.
|
|
21
|
+
You have **no knowledge** of LSP capabilities, fees, channel sizes, or order
|
|
22
|
+
status. Every number, capacity, fee, order id, or invoice in your reply MUST
|
|
23
|
+
come from a tool result returned in the CURRENT turn. Never quote a fee from
|
|
24
|
+
memory. Never claim an order completed without calling `lsp_get_order`.
|
|
25
|
+
Never reuse a number from a previous turn.
|
|
25
26
|
|
|
26
27
|
**Calling the tool IS the answer.** Don't write "the LSP info is fetched with
|
|
27
|
-
`lsp_get_info`" — call it.
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
-
|
|
56
|
-
|
|
28
|
+
`lsp_get_info`" — call it. Don't reveal tool names in your reply; describe
|
|
29
|
+
what you're doing in plain language.
|
|
30
|
+
|
|
31
|
+
If a tool needs a required argument the user didn't give (e.g. `client_pubkey`
|
|
32
|
+
when creating an order — get it from `rln_get_node_info`), resolve it via the
|
|
33
|
+
appropriate read tool. Don't ask the user for a pubkey.
|
|
34
|
+
|
|
35
|
+
## Asset codes
|
|
36
|
+
|
|
37
|
+
The same conventions as trading apply:
|
|
38
|
+
- `BTC` (sats) — the default for "inbound liquidity" / "channel capacity".
|
|
39
|
+
- `USDT` / `XAUT` — for RGB asset channels (uses `asset_id` + `lsp_asset_amount`).
|
|
40
|
+
|
|
41
|
+
## Tools and the flow
|
|
42
|
+
|
|
43
|
+
### Step 1 — `lsp_get_info`
|
|
44
|
+
No args. Returns the LSP's `OrderOptions` (min/max channel size, min/max
|
|
45
|
+
expiry, etc.) and the `assets` list. **Call it once before estimating** so you
|
|
46
|
+
can validate the user's request against the LSP's limits.
|
|
47
|
+
|
|
48
|
+
If the user wants 1M sats inbound but `max_initial_lsp_balance_sat` is 500k,
|
|
49
|
+
say so plainly and offer the maximum — don't push through and let the maker
|
|
50
|
+
reject it.
|
|
51
|
+
|
|
52
|
+
### Step 2 — `lsp_estimate_fees` (read-only)
|
|
53
|
+
Required args: `lsp_balance_sat`, `client_balance_sat`, `channel_expiry_blocks`.
|
|
54
|
+
|
|
55
|
+
Defaults you can use silently if the user didn't specify:
|
|
56
|
+
- `client_balance_sat: 0` (pure inbound order — most common)
|
|
57
|
+
- `channel_expiry_blocks: 4320` (~30 days)
|
|
58
|
+
|
|
59
|
+
Returns `{setup_fee, capacity_fee, duration_fee, total_fee}` — surface
|
|
60
|
+
`total_fee` to the user and the breakdown when relevant.
|
|
61
|
+
|
|
62
|
+
### Step 3 — `rln_get_node_info`
|
|
63
|
+
No args. Returns `{pubkey, ...}`. **Pubkey is required by `lsp_create_order` —
|
|
64
|
+
fetch it deterministically. Never invent a pubkey.**
|
|
65
|
+
|
|
66
|
+
### Step 4 — `lsp_create_order` 🔒 spend
|
|
67
|
+
Required args: `client_pubkey` (from step 3), `lsp_balance_sat`. The maker
|
|
68
|
+
also expects `client_balance_sat`, `required_channel_confirmations`,
|
|
69
|
+
`funding_confirms_within_blocks`, `channel_expiry_blocks`, `announce_channel`
|
|
70
|
+
— the host adapter fills sensible defaults (1, 6, 4320, true) when the user
|
|
71
|
+
didn't specify, so just pass the values the user actually named.
|
|
72
|
+
|
|
73
|
+
Returns:
|
|
74
|
+
- `order_id`
|
|
75
|
+
- `access_token` (save it — required for `lsp_get_order`)
|
|
76
|
+
- `payment.bolt11.invoice` — Lightning invoice to pay
|
|
77
|
+
- `payment.bolt11.order_total_sat` — the sats that need to flow
|
|
78
|
+
- `payment.onchain.address` — optional on-chain fallback
|
|
79
|
+
- `order_state: "CREATED"`
|
|
80
|
+
|
|
81
|
+
### Step 5 — Pay the invoice with `rln_pay_invoice`
|
|
82
|
+
Hand the `payment.bolt11.invoice` to `rln_pay_invoice`. This is a separate
|
|
83
|
+
spend gate at the wallet contract; the user confirms paying the LSP.
|
|
84
|
+
|
|
85
|
+
### Step 6 — `lsp_get_order` (poll)
|
|
86
|
+
**Args: `order_id`, `access_token` (BOTH required — never omit either).**
|
|
87
|
+
`order_state` progresses `CREATED → CHANNEL_OPENING → COMPLETED` (or `FAILED`).
|
|
88
|
+
Poll until terminal. Always pass the exact order_id and access_token from the
|
|
89
|
+
previous `lsp_create_order` result (or from the summary that listed them).
|
|
90
|
+
Report the outcome plainly with the new channel id from `channel.channel_id` if present.
|
|
91
|
+
|
|
92
|
+
## Don'ts
|
|
93
|
+
|
|
94
|
+
- Don't invent capacity, fees, pubkeys, order_ids, or invoices.
|
|
95
|
+
- Don't reuse a number from a previous turn — re-estimate when parameters
|
|
96
|
+
change (different size or expiry).
|
|
97
|
+
- Don't describe how a tool works — call it.
|
|
98
|
+
- Don't pay a Lightning invoice without confirming the amount + LSP — the
|
|
99
|
+
spend gate at `rln_pay_invoice` shows the user the destination.
|
|
100
|
+
- Don't claim an order completed without polling `lsp_get_order` with BOTH
|
|
101
|
+
`order_id` and `access_token` and seeing `order_state: COMPLETED`.
|
|
102
|
+
- Never call `lsp_get_order` with only the access_token or only the order_id.
|
|
103
|
+
Always extract the exact values from the previous turn's summary (the one that
|
|
104
|
+
said "order_id=... access_token=...") and pass them as separate arguments.
|
|
105
|
+
- Don't ask the user for their node pubkey — fetch it from `rln_get_node_info`.
|
|
106
|
+
|
|
107
|
+
## When the deterministic recipe handles it
|
|
108
|
+
|
|
109
|
+
For requests like "I need 500k inbound" or "buy a channel from the LSP", the
|
|
110
|
+
`kaleidoswap-channel-order` recipe drives the whole chain (get_info →
|
|
111
|
+
estimate_fees → get_node_info → create_order → pay_invoice) with a single
|
|
112
|
+
confirmation gate showing the real fee. Use the agentic flow here only when
|
|
113
|
+
the recipe didn't fire — typically for read-only questions ("what does the
|
|
114
|
+
LSP offer?") or partial flows ("estimate fees for 200k inbound").
|
|
@@ -1,11 +1,11 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: kaleido-trading
|
|
3
|
-
description: "Trade on KaleidoSwap — quote and execute swaps between BTC and RGB assets (USDT, XAUT). Get assets and pairs, pull an executable quote, place a market order, or track an atomic swap end-to-end. Triggers when the user wants a
|
|
4
|
-
tools:
|
|
3
|
+
description: "Trade on KaleidoSwap — quote and execute swaps between BTC and RGB assets (USDT, XAUT). Get assets and pairs, pull an executable quote, place a market order, or track an atomic swap end-to-end. Triggers when the user wants a quote, to swap or trade assets, or to rebalance between BTC and stablecoins."
|
|
4
|
+
tools: kaleidoswap_get_assets, kaleidoswap_get_pairs, kaleidoswap_get_quote, kaleidoswap_get_nodeinfo, kaleidoswap_place_order, kaleidoswap_get_order_status, kaleidoswap_get_order_history
|
|
5
5
|
triggers: quote, swap, trade, rebalance, slippage, pair, pairs, usdt, xaut, kaleidoswap, rfq
|
|
6
6
|
metadata:
|
|
7
7
|
author: kaleidoswap
|
|
8
|
-
version: "0.
|
|
8
|
+
version: "0.4.0"
|
|
9
9
|
---
|
|
10
10
|
|
|
11
11
|
# KaleidoSwap trading
|
|
@@ -20,10 +20,9 @@ You have **no knowledge** of any price, quote, fee, pair, or order. Every
|
|
|
20
20
|
number, pair, or quote id in your reply MUST come from a tool result returned
|
|
21
21
|
in the CURRENT turn:
|
|
22
22
|
|
|
23
|
-
- "What's the BTC price?" → call `get_price` and state the number it returns.
|
|
24
23
|
- "What pairs are listed?" → call `kaleidoswap_get_pairs` and list them.
|
|
25
24
|
- "Quote 100k sats to USDT" → call `kaleidoswap_get_quote(BTC, USDT, 100000)`,
|
|
26
|
-
then state the receive amount +
|
|
25
|
+
then state the receive amount + fee from the result.
|
|
27
26
|
|
|
28
27
|
**Calling the tool IS the answer.** Never write "the pairs are listed using
|
|
29
28
|
kaleidoswap_get_pairs" or "the function returns the quote" — just call it.
|
|
@@ -31,9 +30,14 @@ kaleidoswap_get_pairs" or "the function returns the quote" — just call it.
|
|
|
31
30
|
**Never reuse a number across turns.** If the user asks a new question, the
|
|
32
31
|
previous turn's quote, price, or fee is irrelevant — fetch fresh.
|
|
33
32
|
|
|
34
|
-
**Never invent a quote.** Without
|
|
33
|
+
**Never invent a quote.** Without an `rfq_id` and a `to_asset.amount` returned
|
|
35
34
|
this turn, you do not have a quote. Say so and re-quote.
|
|
36
35
|
|
|
36
|
+
This skill is for tradeable pair quotes on the maker. It does NOT do generic
|
|
37
|
+
"what is bitcoin worth in USD" spot prices — that's the wallet's job. If the
|
|
38
|
+
user asks for a plain BTC price (not a swap), say you can quote a swap and ask
|
|
39
|
+
which pair + amount.
|
|
40
|
+
|
|
37
41
|
## Asset codes (canonical)
|
|
38
42
|
|
|
39
43
|
Only these codes are accepted:
|
|
@@ -52,47 +56,93 @@ Use when the user asks "what can I trade", "list pairs", "what's available",
|
|
|
52
56
|
or before quoting an unfamiliar pair.
|
|
53
57
|
|
|
54
58
|
### `kaleidoswap_get_quote` — REQUIRES `amount`
|
|
55
|
-
Required args: `from_asset` AND `to_asset` AND `amount`. The maker rejects
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
**If the user didn't give an amount, ASK for it. Do
|
|
59
|
-
from/to alone.**
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
-
|
|
66
|
-
|
|
59
|
+
Required args: `from_asset` AND `to_asset` AND `amount`. The maker rejects a
|
|
60
|
+
quote that has no amount.
|
|
61
|
+
|
|
62
|
+
**If the user didn't give an amount, ASK for it. Do NOT call the tool with
|
|
63
|
+
from/to alone, and do NOT make up an amount.**
|
|
64
|
+
|
|
65
|
+
`amount` is in the smallest unit of `from_asset`. Use the EXACT number the user
|
|
66
|
+
typed (scaled if they used "k"/"m"/"M" shorthand: 100k → 100000, 2m → 2000000).
|
|
67
|
+
**Never** copy an amount from a previous turn or from these instructions.
|
|
68
|
+
|
|
69
|
+
Critical unit-and-leg anchor:
|
|
70
|
+
- If the user says **sats** or **satoshis** anywhere, the BTC leg is implied
|
|
71
|
+
(sats = the smallest unit of BTC). `BTC` is always `from_asset` OR `to_asset`
|
|
72
|
+
depending on the verb.
|
|
73
|
+
- "X sats TO Y" → `from_asset: "BTC"`, `to_asset: "Y"`, `amount: X-as-sats`.
|
|
74
|
+
- "X Y TO BTC" (Y ∈ {USDT, XAUT}) → `from_asset: "Y"`, `to_asset: "BTC"`,
|
|
75
|
+
`amount: X-in-Y-units`.
|
|
76
|
+
- "buy Z of A with B" → spent = B → `from_asset: "B"`, received = A → `to_asset: "A"`,
|
|
77
|
+
`amount: <amount of B the user wants to spend>`.
|
|
78
|
+
- "rate of X to Y" with NO number → no amount → ASK: "How much do you want to
|
|
79
|
+
swap?" → do NOT call the tool yet.
|
|
80
|
+
|
|
81
|
+
### Reading the quote response
|
|
82
|
+
|
|
83
|
+
`kaleidoswap_get_quote` returns ready-to-read display fields — **use them
|
|
84
|
+
verbatim. Do NOT do any arithmetic yourself.** The response looks like:
|
|
85
|
+
|
|
86
|
+
```
|
|
87
|
+
{
|
|
88
|
+
"rfq_id": "<id>",
|
|
89
|
+
"from_amount_display": "100,000 BTC-sats", ← what the user spends
|
|
90
|
+
"to_amount_display": "0.063176 USDT", ← what the user receives
|
|
91
|
+
"fee_display": "0.000638 USDT", ← the fee
|
|
92
|
+
"expires_at": <epoch>,
|
|
93
|
+
...raw numeric fields you should ignore...
|
|
94
|
+
}
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
To state the answer, copy the strings:
|
|
98
|
+
- Receive amount → `to_amount_display`.
|
|
99
|
+
- Fee → `fee_display`.
|
|
100
|
+
- `rfq_id` is the quote handle (needed to place the swap), short-lived (~60s) —
|
|
101
|
+
mention it expires soon.
|
|
102
|
+
|
|
103
|
+
**Read `to_amount_display` / `fee_display` exactly as given.** Do NOT compute
|
|
104
|
+
`amount ÷ 10^precision`, do NOT restate the raw `price`/`amount` integers, and
|
|
105
|
+
do NOT copy the numbers from this document — they are placeholders. The only
|
|
106
|
+
correct numbers are the `*_display` strings in the CURRENT tool result.
|
|
107
|
+
|
|
108
|
+
A good reply: *"100,000 sats → <to_amount_display> (fee <fee_display>). Quote
|
|
109
|
+
<rfq_id> is valid ~60s — want me to place it?"*
|
|
67
110
|
|
|
68
111
|
### `kaleidoswap_place_order(quote_id)` 🔒 spend
|
|
69
|
-
Only after `kaleidoswap_get_quote` returned
|
|
70
|
-
|
|
112
|
+
Only after `kaleidoswap_get_quote` returned an `rfq_id` THIS turn, and only when
|
|
113
|
+
the user has explicitly approved the amount + direction. Pass the `rfq_id` as
|
|
114
|
+
`quote_id`.
|
|
115
|
+
|
|
116
|
+
**Save the `order_id` AND `access_token` from the result** — you will need both
|
|
117
|
+
for polling status later.
|
|
71
118
|
|
|
72
|
-
### `kaleidoswap_get_order_status(order_id)`
|
|
73
|
-
Poll after placing an order.
|
|
119
|
+
### `kaleidoswap_get_order_status(order_id, access_token)`
|
|
120
|
+
Poll after placing an order. **Pass both the order_id and the access_token**
|
|
121
|
+
(saved from place_order). Report status plainly — pending, settling,
|
|
74
122
|
completed, failed.
|
|
75
123
|
|
|
76
124
|
## Flow
|
|
77
125
|
|
|
78
126
|
1. **Pick a pair** — skip when obvious (`BTC/USDT`, `BTC/XAUT`).
|
|
79
|
-
2. **Quote** — `kaleidoswap_get_quote`. REQUIRES amount.
|
|
80
|
-
3. **
|
|
81
|
-
|
|
82
|
-
fees out of the message.
|
|
127
|
+
2. **Quote** — `kaleidoswap_get_quote`. REQUIRES amount; ask if missing.
|
|
128
|
+
3. **Read + present** — compute the receive amount + fee from the response (see
|
|
129
|
+
"Reading the quote response"). **Never hide cost.**
|
|
83
130
|
4. **Place** — spend-gated by the engine. The host pauses for the user.
|
|
84
|
-
5. **Track** — poll `kaleidoswap_get_order_status` until it terminates.
|
|
131
|
+
5. **Track** — poll `kaleidoswap_get_order_status(order_id, access_token)` (use both values saved from place_order) until it terminates.
|
|
85
132
|
|
|
86
133
|
## Don'ts
|
|
87
134
|
|
|
88
|
-
- Don't invent prices, quotes,
|
|
135
|
+
- Don't invent prices, quotes, rfq_ids, or order_ids.
|
|
89
136
|
- Don't reuse a number from a previous turn.
|
|
90
137
|
- Don't describe how a tool works — call it.
|
|
91
138
|
- Don't call `kaleidoswap_get_quote` with from/to only — ask for the amount.
|
|
139
|
+
- Don't make up an amount the user didn't give.
|
|
140
|
+
- Don't do unit math or restate raw integers — read the `*_display` strings.
|
|
141
|
+
- Don't copy numbers from the skill docs — only the current tool result is real.
|
|
92
142
|
- Don't accept `XAU` as `XAUT` or `USD` as `USDT` silently — confirm.
|
|
93
143
|
- Don't retry the same failing tool call in a loop. If a call fails, read the
|
|
94
144
|
error and either ask the user, fix the args, or stop.
|
|
95
145
|
|
|
96
|
-
For the atomic-swap flow (
|
|
97
|
-
|
|
98
|
-
|
|
146
|
+
For the full atomic-swap flow (init → whitelist on the RGB node → execute), a
|
|
147
|
+
deterministic recipe drives the chain — the agentic loop is not safe to plan a
|
|
148
|
+
multi-step, two-service swap on a small model.
|
|
@@ -1,87 +1,117 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: merchant-finder
|
|
3
|
-
description: "Find Bitcoin-accepting merchants near the user using live BTC Map data and the device's real location. Triggers when the user asks where to spend Bitcoin, for a shop, store, restaurant, cafe, bar, or ATM that accepts Bitcoin, or for merchants nearby."
|
|
4
|
-
tools: find_merchant_locations
|
|
5
|
-
triggers: merchant, merchants, shop, shops, store, stores, restaurant, restaurants, cafe, cafes, bar, bars, atm, atms, accept, accepts, accepting, nearby, near me, around, place, places, spend, find, pizza, food, coffee, bitcoin map, btcmap
|
|
3
|
+
description: "Find Bitcoin-accepting merchants near the user using live BTC Map data and the device's real location. Triggers when the user asks where to spend Bitcoin, buy pizza/food with sats or bitcoin, eat at restaurants/cafes paying with sats, for a shop, store, restaurant, cafe, bar, or ATM that accepts Bitcoin, or for merchants nearby or in a city like turin."
|
|
4
|
+
tools: find_merchant_locations
|
|
5
|
+
triggers: merchant, merchants, shop, shops, store, stores, restaurant, restaurants, cafe, cafes, bar, bars, atm, atms, accept, accepts, accepting, nearby, near me, around, place, places, spend, find, pizza, pizz, food, coffee, eat, dinner, lunch, buy, bitcoin map, btcmap
|
|
6
6
|
metadata:
|
|
7
7
|
author: kaleidoswap
|
|
8
|
-
version: "0.
|
|
8
|
+
version: "0.3.0"
|
|
9
9
|
homepage: "https://btcmap.org"
|
|
10
10
|
---
|
|
11
11
|
|
|
12
12
|
# Merchant finder
|
|
13
13
|
|
|
14
14
|
Discover places that accept Bitcoin payments — cafés, restaurants, bars, shops,
|
|
15
|
-
and ATMs. Live BTC Map data when the host
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
-
|
|
64
|
-
|
|
65
|
-
-
|
|
66
|
-
|
|
15
|
+
and ATMs. **Live BTC Map data only** — when the host has not injected a fetcher
|
|
16
|
+
or cannot resolve a location, the tool returns `{success:false, error}`; relay
|
|
17
|
+
that error to the user verbatim instead of inventing places.
|
|
18
|
+
|
|
19
|
+
## Critical rules (read first)
|
|
20
|
+
|
|
21
|
+
1. **Never answer from memory.** You have NO knowledge of any merchant. Every
|
|
22
|
+
place, name, address and distance in your reply MUST come from a
|
|
23
|
+
result returned by the merchant search tool in the CURRENT turn. Use the
|
|
24
|
+
merchant search tool for every place question, even if a similar one
|
|
25
|
+
was answered earlier — do NOT reuse a previous answer. Never invent a
|
|
26
|
+
merchant. Do not mention the exact name of the tool in your text reply
|
|
27
|
+
to the user.
|
|
28
|
+
2. **List, don't pick.** A "where can I…" / "find merchants" question is a
|
|
29
|
+
LIST question. Show every merchant the tool returned (cap at the first ~5
|
|
30
|
+
if there are many), ONE LINE EACH. Never collapse a list of 10 to one
|
|
31
|
+
example. The host's "keep replies short" guidance applies to prose, not to
|
|
32
|
+
a list the user explicitly asked for.
|
|
33
|
+
3. **Prefer minimal arguments; use understanding when mapping.** When the user
|
|
34
|
+
speaks naturally, map their words to the available fields intelligently but
|
|
35
|
+
conservatively. When in doubt, pass FEWER fields rather than guessing. The
|
|
36
|
+
tool and the live data (plus any RAG hits you also fetch) are the source of
|
|
37
|
+
truth — your job is to get the right starting call and then reason over
|
|
38
|
+
what comes back.
|
|
39
|
+
|
|
40
|
+
## Using your understanding (the model is meant to help here)
|
|
41
|
+
|
|
42
|
+
- Translate vague or natural language into the best minimal call:
|
|
43
|
+
- "coffee near the station", "grab a bite", "something to eat" → `query: "coffee"` or `"food"` / `"pizza"` (or leave descriptive terms in `query`); consider `category: "cafe"` or `"restaurant"` only when it clearly fits one of the allowed values.
|
|
44
|
+
- "near me for lunch" or "around here" → start with empty or just a broad `query`; let the device location do the work. You may infer a reasonable city from prior turns ("you mentioned Lugano earlier") and pass `near_address`.
|
|
45
|
+
- "ATMs or shops that take lightning" → `query: "atm"` or separate calls, or put "atm shop lightning" in `query`.
|
|
46
|
+
- "the cheaper ones", "with websites", "open late", "good for dinner" → use the tool first (possibly broad), then in the same or follow-up turn use the returned list + any other context/memory to filter, rank or describe. Do not fabricate entries.
|
|
47
|
+
- **Critical for currency terms**: "where can I spend sats in turin", "bitcoin merchants in X", "places that accept crypto" are generic spend requests. **Do not** put "sats", "btc", "bitcoin", "spend" into `query` or invent a `category` (e.g. "shop"). Use only `near_address` (or empty). Putting currency words in query almost always returns zero results because the data source already only contains Bitcoin-accepting places.
|
|
48
|
+
|
|
49
|
+
- Multi-turn and post-processing: After the merchant search tool returns a list you may (and should) reason over it: rank by distance or relevance to the user's phrasing, surface `phone`/`website`/`opening_hours` when present, note accepts_lightning, suggest next actions ("want directions or to check one?"), or combine with `search_knowledge` / memory results if merchants have been ingested for the area.
|
|
50
|
+
|
|
51
|
+
- Hybrid live + RAG: If a `search_knowledge` tool is available and a merchant corpus is loaded, you can use both the live finder (for freshness + distance) and search for background on an area or previously-seen places. Present live results as the actionable list.
|
|
52
|
+
|
|
53
|
+
- Context is fair game for *formulating the call or summarizing results* (e.g. previous city mentioned, user's preference for Lightning). It is never a substitute for calling the tool for the actual current list of places.
|
|
54
|
+
|
|
55
|
+
## How to call the tool
|
|
56
|
+
|
|
57
|
+
1. **Start with the merchant search tool.** Map the user's words to fields using the guidance above. The schema accepts:
|
|
58
|
+
|
|
59
|
+
- `query` — free-text the user effectively named or implied (e.g. "coffee", "pizza", "food", "tapas", "atm"). Good place for terms that don't match a strict category. **Omit entirely** for generic "spend sats", "where can I spend", "merchants", "places to spend bitcoin", or "accept crypto". **Never** put "sats", "sat", "bitcoin", "btc", "crypto", "spend", or similar currency/verb terms here — the data source is already Bitcoin-only and this will usually return zero results.
|
|
60
|
+
|
|
61
|
+
- `category` — **exactly one** of the allowed values when it fits cleanly: `restaurant`, `cafe`, `bar`, `shop`, `grocery`, `lodging`, `atm`. Leave empty otherwise. **For any generic "spend sats / where can I spend bitcoin / merchants in X" request, leave category empty.** Do not guess a category just because the user wants to spend. Generic nouns like "merchant", "place", "store" belong in `query` (or omitted), never as the category.
|
|
62
|
+
|
|
63
|
+
- `near_address` — city / neighborhood / address when the user named a place instead of (or in addition to) "near me". The host will geocode it.
|
|
64
|
+
|
|
65
|
+
- `radius_km` — only when the user gave a specific distance ("within 2 km"). Default (5 km) is already reasonable for a city; the backend applies a sensible bound.
|
|
66
|
+
|
|
67
|
+
- `limit` — only when the user named a count (1–20).
|
|
68
|
+
|
|
69
|
+
Positive examples (using understanding):
|
|
70
|
+
- "where can I spend btc near me" → use the tool with `{}`
|
|
71
|
+
- "where can I spend sats in turin" → use the tool with `{ near_address: "Turin" }` ← generic spend → minimal args, no query, no category
|
|
72
|
+
- "where can I spend btc in Lugano" → use the tool with `{ near_address: "Lugano" }`
|
|
73
|
+
- "cafes in Lisbon" → use the tool with `{ category: "cafe", near_address: "Lisbon" }`
|
|
74
|
+
- "pizza places in Switzerland that take bitcoin" → use the tool with `{ query: "pizza", near_address: "Switzerland" }`
|
|
75
|
+
- "lightning bars in NYC, within 2 km" → use the tool with `{ category: "bar", near_address: "New York", radius_km: 2 }`
|
|
76
|
+
- "coffee near the station" or "grab a bite around here" → use the tool with `{ query: "coffee" }` or `{ query: "food" }` (let location come from device or prior context)
|
|
77
|
+
- "ATMs or shops that take sats in the center" → first use the tool with `query: "atm shop"` + appropriate near_address; then reason over results.
|
|
78
|
+
|
|
79
|
+
Things that are still wrong (schema or data reasons):
|
|
80
|
+
- `category: "merchant"` or `"place"` (invalid per schema).
|
|
81
|
+
- `query: "sats"`, `"btc"`, `"bitcoin"`, or any currency/spend verb (the dataset is already Bitcoin-only; these filters return nothing or almost nothing useful. "Spend sats" is a generic merchant request, not a filter term).
|
|
82
|
+
- Guessing a tiny `radius_km` the user never mentioned (results will be empty).
|
|
83
|
+
- Inventing a `category` (like "shop") for a completely generic "where can I spend sats" query — use no category and let the data speak.
|
|
84
|
+
- Adding constraints the user did not name when a minimal call would have returned more relevant places.
|
|
85
|
+
|
|
86
|
+
**Real bad example that causes zero results**:
|
|
87
|
+
- "where can I spend sats in turin" → bad: use query "sats" + category "shop"
|
|
88
|
+
( "sats" in query + guessed category over-filters everything; correct is just the near_address or nothing).
|
|
67
89
|
|
|
68
90
|
2. **Present the results.** Each row carries:
|
|
69
91
|
- `name`, `category`, `address`
|
|
70
92
|
- `distance_m` when present — show in metres or km
|
|
71
93
|
- `accepts_bitcoin` / `accepts_lightning` — relevant because Lightning is
|
|
72
94
|
fastest for small payments
|
|
73
|
-
- `phone`, `website`, `opening_hours` when present — surface if asked
|
|
95
|
+
- `phone`, `website`, `opening_hours` when present — surface if asked or relevant
|
|
74
96
|
|
|
75
|
-
3. **
|
|
76
|
-
|
|
97
|
+
3. **Handling failures.** If the tool returns `{success:false, error}`, relay
|
|
98
|
+
the error as-is and stop. Common cases:
|
|
99
|
+
- "Merchant search is unavailable…" → the host has no BTC Map adapter.
|
|
100
|
+
- "Could not locate \"X\"…" → geocoding failed; ask the user for a nearby
|
|
101
|
+
city or check the spelling.
|
|
102
|
+
- "Could not determine your location…" → no `near_address` was passed and
|
|
103
|
+
the device has no GPS / default location.
|
|
104
|
+
|
|
105
|
+
Do NOT retry with invented data, and do NOT pretend you know merchants in
|
|
106
|
+
the area. There is no offline fallback — a failure means no data.
|
|
77
107
|
|
|
78
108
|
## Reply style
|
|
79
109
|
|
|
80
|
-
-
|
|
110
|
+
- **List, don't fabricate.** Show the merchants the tool actually returned (first ~5–8 is fine for long lists), one line each. You may add a short prose lead or helpful follow-up ("These are sorted by distance. The first two have websites.") but the names, categories, addresses and distances must come from the tool result in this turn.
|
|
111
|
+
- One line per merchant (example):
|
|
81
112
|
`Name — category, address (X m away, accepts: lightning, onchain)`.
|
|
82
|
-
- If
|
|
83
|
-
|
|
84
|
-
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
fallback location was used so they know it's not their actual GPS.
|
|
113
|
+
- If zero merchants: say so plainly. Suggest widening radius or trying a `near_address`. Do not invent alternatives.
|
|
114
|
+
- When `precise_location` is false for a "near me" result, mention the fallback area that was used.
|
|
115
|
+
- After showing the list you are free to reason, rank, or ask a clarifying follow-up using the data + conversation context.
|
|
116
|
+
|
|
117
|
+
**Remember**: the live merchant search tool (plus any RAG merchant documents you also search) are the only sources of place information. Your value is excellent intent → arg mapping on the way in, and helpful reasoning / presentation on the way out. Do not name the tool in your user-facing reply.
|