@kaleidorg/mind 0.8.1 → 0.10.0

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}`