@kaleidorg/mind 0.9.0 → 0.10.0

package/skills/kaleido-trading/SKILL.md

@@ -1,179 +1,35 @@
 ---
 name: kaleido-trading
-description: "Trade on KaleidoSwap — quote and execute swaps between BTC and RGB assets (USDT, XAUT). Get assets and pairs, pull an executable quote, or run/poll an atomic swap end-to-end. Triggers when the user wants a quote, to swap or trade assets, to rebalance between BTC and stablecoins, or to check the status of a swap / atomic swap."
-tools: kaleidoswap_get_assets, kaleidoswap_get_pairs, kaleidoswap_get_quote, kaleidoswap_atomic_init, kaleidoswap_atomic_execute, kaleidoswap_atomic_status, rln_get_node_info, rln_atomic_taker, rln_refresh_transfers, rln_get_asset_balance, rln_list_channels, rln_list_swaps, rln_get_swap
-triggers: quote, swap, trade, rebalance, slippage, pair, pairs, usdt, xaut, kaleidoswap, rfq, check status, order status, check the order, swap status, check my swap, atomic status
+description: "Quote and run KaleidoSwap atomic swaps between BTC and RGB assets (USDT, XAUT): pairs, assets, quotes, swap execution and swap status."
+tools: kaleidoswap_get_pairs, kaleidoswap_get_assets, kaleidoswap_get_quote, kaleidoswap_atomic_init, rln_atomic_taker, rln_get_node_info, kaleidoswap_atomic_execute, kaleidoswap_atomic_status, rln_refresh_transfers
+requires-tools: kaleidoswap_get_quote
+triggers: quote, swap, trade, pair, pairs, usdt, xaut, kaleidoswap, rfq, atomic, swap status
 metadata:
   author: kaleidoswap
-  version: "0.5.0"
+  version: "0.6.0"
 ---
-
 # KaleidoSwap trading
 
-Quote and execute swaps on the KaleidoSwap maker. The model picks tools by
-name; the host binds them through whichever transport it runs over (WDK on
-mobile, HTTP/MCP/CLI on desktop).
-
-## Critical rules — these override everything else
-
-You have **no knowledge** of any price, quote, fee, pair, or order. Every
-number, pair, or quote id in your reply MUST come from a tool result returned
-in the CURRENT turn:
-
-- "What pairs are listed?" → call `kaleidoswap_get_pairs` and list them.
-- "Quote 100k sats to USDT" → call `kaleidoswap_get_quote(BTC, USDT, 100000)`,
-  then state the receive amount + fee from the result.
-
-**Calling the tool IS the answer.** Never write "the pairs are listed using
-kaleidoswap_get_pairs" or "the function returns the quote" — just call it.
-
-**Never reuse a number across turns.** If the user asks a new question, the
-previous turn's quote, price, or fee is irrelevant — fetch fresh.
-
-**Never invent a quote.** Without an `rfq_id` and a `to_asset.amount` returned
-this turn, you do not have a quote. Say so and re-quote.
-
-This skill is for tradeable pair quotes on the maker. It does NOT do generic
-"what is bitcoin worth in USD" spot prices — that's the wallet's job. If the
-user asks for a plain BTC price (not a swap), say you can quote a swap and ask
-which pair + amount.
-
-## Asset codes (canonical)
-
-KaleidoSwap is the maker for **BTC ↔ RGB asset** atomic swaps. The asset
-family is **RGB**: USDT, XAUT, and any other RGB asset the maker prices.
-The RGB assets live on the user's **RLN** (RGB Lightning Node) — NOT on
-Spark, Arkade, or any other chain.
-
-Only these codes are accepted:
-
-- `BTC` (Bitcoin, amounts always in satoshis)
-- `USDT` (Tether, the RGB asset) — **not** `USD`, **not** `tether`
-- `XAUT` (Tether Gold, the RGB asset) — **not** `XAU`, **not** `gold`
-
-When the user types `USD` they almost always mean `USDT` — confirm before
-quoting. Same for `gold` → `XAUT`. Don't silently substitute.
-
-**Do NOT trade here:**
-
-- `USDB` and any other **Spark-native token** — those are on the Spark
-  layer and trade on **Flashnet** (skill: `flashnet-swaps`), not on
-  KaleidoSwap. Route the user there instead of inventing a maker pair.
-- Tokens from external chains (Ethereum USDT, Solana, etc.). They are
-  not in the maker's catalog and the wallet does not custody them.
-
-## Tools
-
-### `kaleidoswap_get_pairs` — no args
-Use when the user asks "what can I trade", "list pairs", "what's available",
-or before quoting an unfamiliar pair.
-
-### `kaleidoswap_get_quote` — REQUIRES `amount`
-Required args: `from_asset` AND `to_asset` AND `amount`. The maker rejects a
-quote that has no amount.
-
-**If the user didn't give an amount, ASK for it. Do NOT call the tool with
-from/to alone, and do NOT make up an amount.**
-
-`amount` is in the smallest unit of `from_asset`. Use the EXACT number the user
-typed (scaled if they used "k"/"m"/"M" shorthand: 100k → 100000, 2m → 2000000).
-**Never** copy an amount from a previous turn or from these instructions.
-
-Critical unit-and-leg anchor:
-- If the user says **sats** or **satoshis** anywhere, the BTC leg is implied
-  (sats = the smallest unit of BTC). `BTC` is always `from_asset` OR `to_asset`
-  depending on the verb.
-- "X sats TO Y" → `from_asset: "BTC"`, `to_asset: "Y"`, `amount: X-as-sats`.
-- "X Y TO BTC" (Y ∈ {USDT, XAUT}) → `from_asset: "Y"`, `to_asset: "BTC"`,
-  `amount: X-in-Y-units`.
-- "buy Z of A with B" → spent = B → `from_asset: "B"`, received = A → `to_asset: "A"`,
-  `amount: <amount of B the user wants to spend>`.
-- "rate of X to Y" with NO number → no amount → ASK: "How much do you want to
-  swap?" → do NOT call the tool yet.
-
-### Reading the quote response
-
-`kaleidoswap_get_quote` returns ready-to-read display fields — **use them
-verbatim. Do NOT do any arithmetic yourself.** The response looks like:
-
-```
-{
-  "rfq_id": "<id>",
-  "from_amount_display": "100,000 BTC-sats",   ← what the user spends
-  "to_amount_display":   "0.063176 USDT",       ← what the user receives
-  "fee_display":         "0.000638 USDT",        ← the fee
-  "expires_at": <epoch>,
-  ...raw numeric fields you should ignore...
-}
-```
-
-To state the answer, copy the strings:
-- Receive amount → `to_amount_display`.
-- Fee → `fee_display`.
-- `rfq_id` is the quote handle (needed to start the atomic swap), short-lived (~60s) —
-  mention it expires soon.
-
-**Read `to_amount_display` / `fee_display` exactly as given.** Do NOT compute
-`amount ÷ 10^precision`, do NOT restate the raw `price`/`amount` integers, and
-do NOT copy the numbers from this document — they are placeholders. The only
-correct numbers are the `*_display` strings in the CURRENT tool result.
-
-A good reply: *"100,000 sats → <to_amount_display> (fee <fee_display>). Quote
-<rfq_id> is valid ~60s — want me to place it?"*
-
-### `kaleidoswap_atomic_init` 🔒 spend
-Only after `kaleidoswap_get_quote` returned an `rfq_id` THIS turn, and only when
-the user has explicitly approved the amount + direction. Starts the atomic
-swap from that quote; the rest of the chain (`rln_atomic_taker` →
-`kaleidoswap_atomic_execute` → `kaleidoswap_atomic_status`) is described
-below and in `references/atomic.md`.
-
-### `kaleidoswap_atomic_status`
-Poll after executing an atomic swap until it reaches a terminal state
-(completed / failed / expired). Pass the exact ids returned by
-`kaleidoswap_atomic_init` (or surfaced in the most recent swap summary) — never
-invent them. Report the outcome plainly.
-
-## Flow
-
-1. **Pick a pair** — skip when obvious (`BTC/USDT`, `BTC/XAUT`).
-2. **Quote** — `kaleidoswap_get_quote`. REQUIRES amount; ask if missing.
-3. **Read + present** — compute the receive amount + fee from the response (see
-   "Reading the quote response"). **Never hide cost.**
-4. **Swap** — `kaleidoswap_atomic_init` → `rln_atomic_taker` →
-   `kaleidoswap_atomic_execute`. Spend-gated by the engine; the host pauses for
-   the user.
-5. **Track** — poll `kaleidoswap_atomic_status` with the ids from
-   `kaleidoswap_atomic_init` until it terminates.
-
-## Don'ts
-
-- Don't invent prices, quotes, rfq_ids, swap ids, or access_tokens.
-- Don't reuse a number from a previous turn.
-- Don't describe how a tool works — call it.
-- Don't call `kaleidoswap_get_quote` with from/to only — ask for the amount.
-- Don't make up an amount the user didn't give.
-- Don't do unit math or restate raw integers — read the `*_display` strings.
-- Don't copy numbers from the skill docs — only the current tool result is real.
-- Don't accept `XAU` as `XAUT` or `USD` as `USDT` silently — confirm.
-- Don't retry the same failing tool call in a loop. If a call fails, read the
-  error and either ask the user, fix the args, or stop.
-- Don't claim a swap completed without polling `kaleidoswap_atomic_status`
-  and seeing a terminal state.
-
-For the full atomic-swap flow (init → whitelist on the RGB node → execute), a
-deterministic recipe drives the chain — the agentic loop is not safe to plan a
-multi-step, two-service swap on a small model. Status for atomics uses the
-`atomic_id` (or payment_hash) surfaced in the recipe summary.
-
-## Over kaleido-mcp (desktop, Claude Code)
-
-kaleido-mcp 0.3.0+ is **atomic-only**. Its quote takes `from_asset_id` / `from_layer` /
-`from_amount` (display units) and returns `amount_raw` values that
-`kaleidoswap_atomic_init` takes unchanged. The full chain is quote →
-`kaleidoswap_atomic_init` → `rln_atomic_taker` + `rln_get_node_info` →
-`kaleidoswap_atomic_execute` → poll `kaleidoswap_atomic_status` →
-`rln_refresh_transfers`. Read `references/atomic.md` before the first swap,
-and `references/assets.md` for units and precision. Always follow the
-argument names in the tool schema you were given.
-
+Amounts in `kaleidoswap_get_quote` are **display units**: `from_amount: 0.0005`
+means 0.0005 BTC (50,000 sats; 1 BTC = 100,000,000 sats). Asset ids accept a
+ticker (`BTC`, `USDT`, `XAUT`) or an `rgb:…` id.
+
+## Do
+- Quote with exactly one amount: `from_amount` to sell a fixed input,
+  `to_amount` to buy a fixed output. No amount given → ask for one.
+- Report `from_asset.amount_display`, `to_asset.amount_display` and
+  `expires_at` as given; `price` is in the maker's raw units, don't quote it.
+  The quote expires in about 60 s.
+- Executing a swap moves funds: only after the user says yes to that quote.
+  Chain: `kaleidoswap_atomic_init` (rfq_id, both asset ids, both `amount_raw`
+  values unchanged) → `rln_atomic_taker` (swapstring) → `rln_get_node_info`
+  (pubkey) → `kaleidoswap_atomic_execute` → poll `kaleidoswap_atomic_status`.
+  Details and errors: `references/atomic.md`.
+- `USD` is not `USDT` and `gold` is not `XAUT`: confirm before quoting.
+  Spark tokens such as USDB trade on Flashnet (`flashnet-swaps`), not here.
+
+## Examples
+- "Quote 0.0005 BTC to USDT" → `kaleidoswap_get_quote {"from_asset_id":"BTC","to_asset_id":"USDT","from_amount":0.0005}`
+- "Swap 100k sats into XAUT" → `kaleidoswap_get_quote {"from_asset_id":"BTC","to_asset_id":"XAUT","from_amount":0.001}`
+- "I want to receive 10 USDT, how much BTC?" → `kaleidoswap_get_quote {"from_asset_id":"BTC","to_asset_id":"USDT","to_amount":10}`
+- "Status of swap 9f2c…" → `kaleidoswap_atomic_status {"payment_hash":"9f2c…"}`

package/skills/kaleido-trading/references/assets.md

@@ -40,10 +40,10 @@ Read precision from the API; the table is illustrative.
 
 | Tool | Units |
 |---|---|
-| `kaleidoswap_get_quote` (kaleido-mcp) | display (`0.001` BTC, `65.0` USDT) |
-| `kaleidoswap_atomic_init` (kaleido-mcp) | raw: pass `quote.*.amount_raw` unchanged |
-| `kaleidoswap_get_quote` (in-app contract) | sats for BTC, asset units otherwise |
-| `rln_send_asset` / `rln_create_rgb_invoice` (kaleido-mcp) | display units |
+| `kaleidoswap_get_quote` | display (`0.001` BTC, `65.0` USDT) |
+| `kaleidoswap_atomic_init` | raw: pass `quote.*.amount_raw` unchanged |
+| `rln_send_asset` / `rln_create_rgb_invoice` / `rln_issue_asset` | display units |
+| `rln_list_assets` / `rln_get_asset_balance` balances | raw: divide by 10^precision |
 
 ## Mapping user words
 

package/skills/kaleido-trading/references/atomic.md

@@ -1,13 +1,11 @@
-# Atomic swap over kaleido-mcp
+# Atomic swap
 
 Every KaleidoSwap swap settles as an atomic HTLC swap between the maker and
-the user's RGB Lightning Node (RLN). There is no deposit or order flow on
-kaleido-mcp 0.3.0+. If either side fails, nothing settles. Typical end-to-end
+the user's RGB Lightning Node (RLN). There is no deposit or order flow. If either side fails, nothing settles. Typical end-to-end
 time: 2–15 s.
 
-These are kaleido-mcp's argument names. In-app wallets that bind the
-`@kaleidorg/mind` KaleidoSwap contract use the simpler `from_asset` /
-`to_asset` / `amount` quote and run the chain through a recipe instead.
+The argument names are the same in kaleido-mcp and in the `@kaleidorg/mind`
+KaleidoSwap contract.
 
 ## Steps
 
@@ -58,7 +56,7 @@ and is not an order id.
 
 The swap needs outbound capacity on the asset you send and inbound capacity on
 the asset you receive. If either side is short, `atomic_execute` fails. Buy a
-channel first (skill: `kaleido-lsps`).
+channel first (skill: `channel-manager`).
 
 ## Reading the result
 

package/skills/merchant-finder/SKILL.md

@@ -1,117 +1,34 @@
 ---
 name: merchant-finder
-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."
+description: "Find places that accept Bitcoin (shops, restaurants, cafes, bars, ATMs) near the user or in a named city, from live BTC Map data."
 tools: find_merchant_locations, search_knowledge
-triggers: merchant, merchants, shop, shops, store, stores, restaurant, restaurants, cafe, cafes, bar, bars, atm, atms, accept, accepts, accepting, nearby, near me, around me, where can i spend, pizza, pizz, food, coffee, eat, dinner, lunch, bitcoin map, btcmap
+requires-tools: find_merchant_locations
+triggers: merchant, merchants, shop, shops, store, restaurant, restaurants, cafe, cafes, coffee, bar, bars, atm, atms, near me, nearby, where can i spend, accept bitcoin, pizza, food, eat, btcmap, bitcoin map
 metadata:
   author: kaleidoswap
-  version: "0.3.0"
+  version: "0.4.0"
   homepage: "https://btcmap.org"
 ---
-
 # Merchant finder
 
-Discover places that accept Bitcoin payments — cafés, restaurants, bars, shops,
-and ATMs. **Live BTC Map data only** — when the host has not injected a fetcher
-or cannot resolve a location, the tool returns `{success:false, error}`; relay
-that error to the user verbatim instead of inventing places.
-
-## Critical rules (read first)
-
-1. **Never answer from memory.** You have NO knowledge of any merchant. Every
-   place, name, address and distance in your reply MUST come from a
-   result returned by the merchant search tool in the CURRENT turn. Use the
-   merchant search tool for every place question, even if a similar one
-   was answered earlier — do NOT reuse a previous answer. Never invent a
-   merchant. Do not mention the exact name of the tool in your text reply
-   to the user.
-2. **List, don't pick.** A "where can I…" / "find merchants" question is a
-   LIST question. Show every merchant the tool returned (cap at the first ~5
-   if there are many), ONE LINE EACH. Never collapse a list of 10 to one
-   example. The host's "keep replies short" guidance applies to prose, not to
-   a list the user explicitly asked for.
-3. **Prefer minimal arguments; use understanding when mapping.** When the user
-   speaks naturally, map their words to the available fields intelligently but
-   conservatively. When in doubt, pass FEWER fields rather than guessing. The
-   tool and the live data (plus any RAG hits you also fetch) are the source of
-   truth — your job is to get the right starting call and then reason over
-   what comes back.
-
-## Using your understanding (the model is meant to help here)
-
-- Translate vague or natural language into the best minimal call:
-  - "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.
-  - "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`.
-  - "ATMs or shops that take lightning" → `query: "atm"` or separate calls, or put "atm shop lightning" in `query`.
-  - "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.
-  - **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.
-
-- 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.
-
-- 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.
-
-- 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.
-
-## How to call the tool
-
-1. **Start with the merchant search tool.** Map the user's words to fields using the guidance above. The schema accepts:
-
-   - `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.
-
-   - `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.
-
-   - `near_address` — city / neighborhood / address when the user named a place instead of (or in addition to) "near me". The host will geocode it.
-
-   - `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.
-
-   - `limit` — only when the user named a count (1–20).
-
-   Positive examples (using understanding):
-   - "where can I spend btc near me" → use the tool with `{}`
-   - "where can I spend sats in turin" → use the tool with `{ near_address: "Turin" }`   ← generic spend → minimal args, no query, no category
-   - "where can I spend btc in Lugano" → use the tool with `{ near_address: "Lugano" }`
-   - "cafes in Lisbon" → use the tool with `{ category: "cafe", near_address: "Lisbon" }`
-   - "pizza places in Switzerland that take bitcoin" → use the tool with `{ query: "pizza", near_address: "Switzerland" }`
-   - "lightning bars in NYC, within 2 km" → use the tool with `{ category: "bar", near_address: "New York", radius_km: 2 }`
-   - "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)
-   - "ATMs or shops that take sats in the center" → first use the tool with `query: "atm shop"` + appropriate near_address; then reason over results.
-
-   Things that are still wrong (schema or data reasons):
-   - `category: "merchant"` or `"place"` (invalid per schema).
-   - `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).
-   - Guessing a tiny `radius_km` the user never mentioned (results will be empty).
-   - Inventing a `category` (like "shop") for a completely generic "where can I spend sats" query — use no category and let the data speak.
-   - Adding constraints the user did not name when a minimal call would have returned more relevant places.
-
-   **Real bad example that causes zero results**:
-   - "where can I spend sats in turin" → bad: use query "sats" + category "shop"
-     ( "sats" in query + guessed category over-filters everything; correct is just the near_address or nothing).
-
-2. **Present the results.** Each row carries:
-   - `name`, `category`, `address`
-   - `distance_m` when present — show in metres or km
-   - `accepts_bitcoin` / `accepts_lightning` — relevant because Lightning is
-     fastest for small payments
-   - `phone`, `website`, `opening_hours` when present — surface if asked or relevant
-
-3. **Handling failures.** If the tool returns `{success:false, error}`, relay
-   the error as-is and stop. Common cases:
-   - "Merchant search is unavailable…" → the host has no BTC Map adapter.
-   - "Could not locate \"X\"…" → geocoding failed; ask the user for a nearby
-     city or check the spelling.
-   - "Could not determine your location…" → no `near_address` was passed and
-     the device has no GPS / default location.
-
-   Do NOT retry with invented data, and do NOT pretend you know merchants in
-   the area. There is no offline fallback — a failure means no data.
-
-## Reply style
-
-- **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.
-- One line per merchant (example):
-  `Name — category, address (X m away, accepts: lightning, onchain)`.
-- If zero merchants: say so plainly. Suggest widening radius or trying a `near_address`. Do not invent alternatives.
-- When `precise_location` is false for a "near me" result, mention the fallback area that was used.
-- After showing the list you are free to reason, rank, or ask a clarifying follow-up using the data + conversation context.
-
-**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.
+Every place in a reply comes from `find_merchant_locations` in this turn. The
+data is already Bitcoin-only.
+
+## Do
+- Pass the fewest arguments that express the request:
+  - `near_address` when the user names a place; omit it for "near me".
+  - `category` only for a clear venue type: `restaurant`, `cafe`, `bar`,
+    `shop`, `grocery`, `lodging`, `atm`.
+  - `query` for a food or name ("pizza", "coffee"). Never "sats", "btc",
+    "bitcoin" or "spend".
+  - `radius_km` / `limit` only when the user gave a distance or count.
+- List the results, one line each: name, category, address, distance, and
+  whether Lightning is accepted. Up to about 8.
+- `{success:false, error}` → relay the error and stop.
+- `search_knowledge` may add background from a loaded merchant corpus.
+
+## Examples
+- "Where can I spend sats in Turin?" → `find_merchant_locations {"near_address":"Turin"}`
+- "Cafes in Lisbon" → `find_merchant_locations {"category":"cafe","near_address":"Lisbon"}`
+- "Pizza near me that takes bitcoin" → `find_merchant_locations {"query":"pizza"}`
+- "Bitcoin ATMs within 2 km" → `find_merchant_locations {"category":"atm","radius_km":2}`

package/skills/paid-data/SKILL.md

@@ -1,65 +1,32 @@
 ---
 name: paid-data
-description: Fetch premium or paywalled data behind an HTTP 402 Lightning payment (L402 or MPP, the Machine Payments Protocol) — paid feeds, pay-per-call APIs, unlockable resources — without signing up or holding an API key. Also finds paid APIs in the public 402index registry. Triggers when the user wants premium, paid, gated or unlockable data, or asks for a paid API.
-tools: fetch_paid_resource, search_paid_apis, mpp_request_challenge, mpp_parse_challenge_header, mpp_submit_credential, rln_mpp_pay, spark_mpp_pay, l402_request_challenge, l402_fetch_resource
-triggers: premium, paid, l402, mpp, 402, feed, subscription, unlock, paywall, pay per call, paid api, gated
+description: "Fetch data behind an HTTP 402 Lightning paywall (L402 or MPP): paid feeds, pay-per-call APIs, unlockable resources, and finding paid APIs in the 402index registry."
+tools: fetch_paid_resource, search_paid_apis, mpp_request_challenge, mpp_parse_challenge_header, rln_mpp_pay, spark_mpp_pay, mpp_submit_credential, l402_request_challenge, l402_fetch_resource
+triggers: premium, paid, l402, mpp, 402, paywall, pay per call, paid api, gated, unlock
 metadata:
   author: kaleidoswap
-  version: "0.2.0"
+  version: "0.3.0"
 ---
-
 # Paid data
 
-Servers gate a resource behind an HTTP 402 Lightning challenge; you pay the
-invoice and present the proof. L402 is the Lightning-only subset of MPP. Tell
-the user what was paid and what came back.
-
-Use whichever tools you have:
-
-## In-app: one call
-
-`fetch_paid_resource({ url })` fetches, pays small invoices automatically
-(capped by the host) and returns the data. Anything above the cap is declined;
-report that instead of retrying.
-
-## Over kaleido-mcp: three steps
-
-```
-1. mpp_request_challenge({ url })
-   → { challenge_id, invoice, amount_sats, intent, expires_at, macaroon? }
-
-2. rln_mpp_pay({ invoice, challenge_id, macaroon? })     ← pays from the RGB Lightning Node
-   (or spark_mpp_pay with the same arguments, from the Spark wallet; better for
-    tiny amounts where Lightning routing may fail)
-   → { paid, payment_hash, preimage?, credential: "<JSON string>" }
-
-3. mpp_submit_credential({ url, credential })            ← pass credential verbatim
-   → { ok, status, data, receipt }
-```
-
-Finish all three before `expires_at` (~60 s); a credential is single-use, so
-restart from step 1 if it expires. Keep the `receipt` as proof of payment.
-
-- **Discovery:** `search_paid_apis({ query, protocol?, health: "healthy" })`
-  lists registered endpoints with their price; pick a healthy one, then run the
-  flow on its `url`.
-- **Own fetch:** with a `WWW-Authenticate` header already in hand, use
-  `mpp_parse_challenge_header({ url, www_authenticate })` instead of step 1.
-- **Legacy L402-only servers:** `l402_request_challenge` /
-  `l402_fetch_resource`. Prefer the `mpp_*` tools; they handle both.
-- **Sessions:** `intent: "session"` challenges allow pay-once, then cheap
-  repeat calls. Not every server offers them; fall back to `charge`.
-
-| Error | Meaning | Fix |
-|---|---|---|
-| `Expected HTTP 402` | URL is not payment-gated | Fetch it normally |
-| `payment failed` | Route or balance problem | Check balances; try `spark_mpp_pay` |
-| `401 after submit` | Bad or reused credential | Redo steps 1–3 |
-| `challenge expired` | Too slow between steps | Restart from step 1 |
-
-## Rules
-
-1. Show `amount_sats` before paying; ask for a yes above 1,000 sats.
-2. Only pay challenges for URLs the user asked for.
-3. Stop after two failures in a row and report; don't loop.
-4. Dry run: report the price and what you would fetch; never pay.
+A server answers 402 with a Lightning invoice; you pay it and present the proof.
+Use whichever tools are available.
+
+## Do
+- In-app: `fetch_paid_resource` with the `url` pays small invoices (capped by the host)
+  and returns the data. A declined payment is the answer; don't retry.
+- kaleido-mcp, three steps before `expires_at` (~60 s):
+  1. `mpp_request_challenge` (`url`) → `challenge_id`, `invoice`, `amount_sats`.
+  2. `rln_mpp_pay` (`invoice`, `challenge_id`) (or `spark_mpp_pay`, same args) →
+     `credential`.
+  3. `mpp_submit_credential` (`url`, `credential`) with the credential unchanged.
+- Show `amount_sats` before paying; ask for a yes above 1,000 sats. Pay only
+  for URLs the user asked for. Stop after two failures.
+- Find APIs: `search_paid_apis` (`query`, `health: "healthy"`), then run the flow on
+  the chosen `url`.
+
+## Examples
+- "Get the premium feed at https://api.example.com/feed" → `mpp_request_challenge {"url":"https://api.example.com/feed"}`
+- "Pay that challenge" → `rln_mpp_pay {"invoice":"<invoice>","challenge_id":"<challenge_id>"}`
+- "Any paid weather APIs?" → `search_paid_apis {"query":"weather","health":"healthy"}`
+- In-app → `fetch_paid_resource {"url":"https://api.example.com/feed"}`

package/skills/portfolio-manager/SKILL.md

@@ -1,67 +1,33 @@
 ---
 name: portfolio-manager
-description: "Keep a BTC / USDT / XAUT portfolio near its target allocation. Read live balances and prices, detect drift versus targets, and (when allowed) rebalance via an atomic swap on KaleidoSwap. Triggers when the user asks to rebalance, check allocation, review the portfolio, or optimize holdings — and is the skill the scheduled 'rebalance' loop runs."
-tools: rln_get_balances, rln_list_assets, kaleidoswap_get_pairs, kaleidoswap_get_quote, kaleidoswap_atomic_init, kaleidoswap_atomic_execute, kaleidoswap_atomic_status, get_price, get_market_data
-triggers: rebalance, allocation, portfolio, drift, optimize, target, weighting, holdings
+description: "Portfolio across BTC, USDT and XAUT: holdings and allocation, drift versus targets, rebalancing and recurring DCA buys through KaleidoSwap atomic swaps. Runs the scheduled rebalance, DCA and daily summary tasks."
+tools: rln_get_balances, rln_list_assets, get_price, get_market_data, kaleidoswap_get_pairs, kaleidoswap_get_quote, kaleidoswap_atomic_init, rln_atomic_taker, rln_get_node_info, kaleidoswap_atomic_execute, kaleidoswap_atomic_status
+requires-tools: kaleidoswap_get_quote
+triggers: portfolio, allocation, rebalance, drift, target, weighting, holdings, dca, dollar cost average, recurring buy, average in, accumulate, daily summary
 metadata:
   author: kaleidoswap
-  version: "0.1.0"
+  version: "0.2.0"
 ---
-
 # Portfolio manager
 
-Keep the holdings near their target weights across **BTC**, **USDT**, and
-**XAUT**. You fetch everything live — never assume a balance, price, or target.
-
-## Critical rules — these override everything else
-
-- **Read before you act.** Get balances (`rln_get_balances`) and prices
-  (`get_price`) every run. Never reuse a number from a previous turn.
-- **Respect `dry_run`.** When `dry_run` is true you describe the rebalance you
-  *would* make — you do NOT call `kaleidoswap_atomic_init`/`_execute`. This is
-  non-negotiable.
-- **Respect fund safety.** Never propose a swap that breaches the BTC reserve or
-  stop-loss floor passed in the task parameters. The host's risk gate is the
-  final word, but don't even suggest a breach.
-- **Below-minimum drift = do nothing.** If every asset is within the drift
-  threshold, say so and stop. Churn is a cost, not a feature.
-
-## How to think about a rebalance
-
-1. **Snapshot.** `rln_get_balances` → BTC sats + each RGB asset (raw units).
-2. **Value it.** Convert each holding to a common denomination using
-   `get_price`. Do NOT do arithmetic free-hand on raw RGB units — use the
-   display fields the tools return; only convert sats↔USD with the live BTC
-   price.
-3. **Compare to targets.** Targets come in the task parameters (e.g.
-   `BTC 70 / USDT 20 / XAUT 10`). Compute each asset's current weight and its
-   drift = current − target.
-4. **Decide.** If the largest drift exceeds the threshold, the over-weight asset
-   sells into the most under-weight asset. One swap per run — smallest trade
-   that brings the worst drift back inside the band.
-5. **Quote.** `kaleidoswap_get_quote(from, to, amount)` for that single leg.
-6. **Execute** (only when `dry_run` is false and the size is within limits): the
-   atomic swap recipe drives `kaleidoswap_atomic_init` → `_execute`; then poll
-   `kaleidoswap_atomic_status`.
-
-## Asset codes (canonical)
-
-`BTC` (satoshis), `USDT` (not `USD`), `XAUT` (not `XAU`/gold).
-
-## Scheduled (background) runs
-
-When run by the `rebalance` loop, after deciding, return STRICT JSON only:
-
-```
-{"task":"rebalance","timestamp":"<ISO8601>","action":"rebalance|noop","dry_run":<bool>,"reason":"<why>","details":{"from":"<asset>","to":"<asset>","amount":"<n>","drift":{}}}
-```
-
-`action` is `noop` when within band. Put the human explanation in `reason`.
-
-## Don'ts
-
-- Don't invent prices, quotes, or balances — call the tool.
-- Don't rebalance on noise — honor the drift threshold.
-- Don't place more than one swap per run.
-- Don't breach the reserve / stop-loss, ever.
-- Don't execute anything when `dry_run` is true.
+Holdings: BTC from `rln_get_balances`, RGB assets (with balances, raw units ÷
+10^precision) from `rln_list_assets`. Prices from `get_price`. Targets, budget,
+reserve and `dry_run` come from the task parameters or the user.
+
+## Do
+- Value each holding in one currency, compute weight and drift = weight −
+  target. Inside the threshold → no trade.
+- Rebalance: one swap per run, the smallest that brings the worst drift back
+  inside the band, from the over-weight asset into the most under-weight one.
+- DCA: buy the fixed slice every run; never catch up missed runs; skip when
+  BTC minus the slice would fall below the reserve.
+- Quote with `kaleidoswap_get_quote` (display units). Execute only when
+  `dry_run` is false and within limits, via the atomic chain in the
+  `kaleido-trading` skill.
+- Scheduled runs: `action` is `rebalance`, `buy`, `skip` or `noop`; put the
+  explanation in `reason`.
+
+## Examples
+- "Show my allocation" → `rln_get_balances {}` then `rln_list_assets {}` then `get_price {"asset":"BTC"}`
+- "DCA 0.0002 BTC into USDT" → `kaleidoswap_get_quote {"from_asset_id":"BTC","to_asset_id":"USDT","from_amount":0.0002}`
+- "Sell 50 USDT back to BTC" → `kaleidoswap_get_quote {"from_asset_id":"USDT","to_asset_id":"BTC","from_amount":50}`