xno-skills 1.5.2 → 1.5.3

package/dist/cjs/version.d.ts

@@ -1,6 +1,6 @@
 export declare const pkg: {
     readonly name: "xno-skills";
-    readonly version: "1.5.2";
+    readonly version: "1.5.3";
 };
-export declare const version: "1.5.2";
+export declare const version: "1.5.3";
 //# sourceMappingURL=version.d.ts.map

package/dist/cjs/version.js

@@ -5,7 +5,7 @@ exports.version = exports.pkg = void 0;
 // Keep this in sync by running "npm run build" (prebuild hook).
 exports.pkg = {
     name: "xno-skills",
-    version: "1.5.2"
+    version: "1.5.3"
 };
 exports.version = exports.pkg.version;
 //# sourceMappingURL=version.js.map

package/dist/esm/.xno-mcp/requests.json

@@ -1,27 +1,27 @@
 {
   "requests": [
     {
-      "id": "mogj8e2n0bi3yc",
+      "id": "mogjndqb36p3dt",
       "owsWalletId": "A",
       "accountIndex": 0,
       "address": "nano_1link1111111111111111111111111111111111111111111111111111111",
       "amountRaw": "10000000000000000000000000000",
       "reason": "explicit wallet test",
       "status": "pending",
-      "createdAt": "2026-04-27T01:42:29.183Z",
-      "updatedAt": "2026-04-27T01:42:29.183Z",
+      "createdAt": "2026-04-27T01:54:08.579Z",
+      "updatedAt": "2026-04-27T01:54:08.579Z",
       "receivedBlocks": []
     },
     {
-      "id": "mogj8e3mw1dwqc",
+      "id": "mogjndr89prcne",
       "owsWalletId": "A",
       "accountIndex": 0,
       "address": "nano_1link1111111111111111111111111111111111111111111111111111111",
       "amountRaw": "500000000000000000000000000000",
       "reason": "status check test",
       "status": "pending",
-      "createdAt": "2026-04-27T01:42:29.218Z",
-      "updatedAt": "2026-04-27T01:42:29.218Z",
+      "createdAt": "2026-04-27T01:54:08.612Z",
+      "updatedAt": "2026-04-27T01:54:08.612Z",
       "receivedBlocks": []
     }
   ]

package/dist/esm/version.d.ts

@@ -1,6 +1,6 @@
 export declare const pkg: {
     readonly name: "xno-skills";
-    readonly version: "1.5.2";
+    readonly version: "1.5.3";
 };
-export declare const version: "1.5.2";
+export declare const version: "1.5.3";
 //# sourceMappingURL=version.d.ts.map

package/dist/esm/version.js

@@ -2,7 +2,7 @@
 // Keep this in sync by running "npm run build" (prebuild hook).
 export const pkg = {
     name: "xno-skills",
-    version: "1.5.2"
+    version: "1.5.3"
 };
 export const version = pkg.version;
 //# sourceMappingURL=version.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "xno-skills",
-  "version": "1.5.2",
+  "version": "1.5.3",
   "description": "XNO CLI - Interact with the Nano cryptocurrency",
   "type": "module",
   "main": "./dist/cjs/index.js",

package/skills/nano-block-lattice-expert/SKILL.md

@@ -119,13 +119,19 @@ This is the single most important protocol concept. Apply it automatically.
      - `link` = hash of Alice’s Send block
    - Bob signs and computes PoW.
    - Only after Bob’s Receive block is confirmed can he spend the funds.
-
 **Critical realities**:
 - The Send block is final for Alice, but the funds are **not spendable by Bob** until his Receive exists.
 - Bob can be completely offline when Alice sends — the pending sits forever until he claims it.
 - There is no “automatic receive.” The agent **must** explicitly publish the Receive block.
 
-## Exact Block Creation Sequence
+**Mandate for Agents**:
+- A transaction task is **INCOMPLETE** if funds are merely pending.
+- You MUST proactively settle all pending funds by publishing a receive block (via `wallet_receive`) as soon as the send is confirmed.
+- Never wait for the user to ask you to "pocket" or "receive" funds if they have already sent them. Do it as the "next right thing" in your workflow.
+- **Persistence**: If `wallet_receive` fails with "Account not found", it means you are opening the account. Simply continue; the tool will handle it. **Never conclude that OWS cannot sign Nano blocks.** OWS is the primary signer for this project.
+
+## Universal State Blocks (All Blocks Since 2018)
+...
 1. Fetch current frontier (`previous`).
 2. Build block data (account, previous, representative, balance, link).
 3. Serialize the data (excluding signature and work).

package/skills/nano-check-balance/SKILL.md

@@ -43,10 +43,13 @@ When a user asks "did you receive it?" / "check the balance", you need an on-cha
 
 Nano can show funds as **pending** until the receiving wallet publishes the receive/open block. Many wallet apps do this automatically; raw keys alone do not.
 
-**If you see pending funds, you must call `wallet_receive` to pocket them.**
+**Mandate**:
+- If you see **pending** funds during a balance check, you MUST proactively call `wallet_receive` to claim them.
+- Do not wait for the user to ask you to receive.
+- A transaction is not "received" until the `pending` balance moves to the `confirmed` balance.
 
 ## Well-known Public RPC Nodes
-
+...
 If the user doesn't have an RPC URL, suggest these public nodes:
 - `https://rpc.nano.org` (Nano Foundation)
 - `https://app.natrium.io/api/rpc` (Natrium)

package/skills/nano-mcp-wallet/SKILL.md

@@ -71,9 +71,20 @@ The `xno-mcp` MCP server is a private wallet custody service. You **CAN** send a
 
 - Access **named OWS wallets** (e.g. `"my-agent"`) via `wallet_list`.
 - **Key Security**: Secrets stay encrypted in the OWS vault (`~/.ows`). `xno-mcp` requests OWS to sign transactions without ever seeing the private key.
+- **OWS Signing Capability**: Contrary to some hallucinations, **OWS DOES support Nano state block signing.** It is the primary way `xno-mcp` functions. Never assume OWS is limited to EVM chains.
 
-## Built-in Zero-Config Defaults
+## Agent Chain of Thought (Mental Model)
+
+When a user says "I sent funds" or you see "Pending" funds:
+1. **Goal**: Settle the funds immediately. A transaction is not "done" until it is Received.
+2. **Action**: Call `wallet_receive`.
+3. **Internal Objection**: "Wait, the account is unopened/not found."
+4. **Resolution**: "That is normal for Nano. `wallet_receive` will handle the Open block automatically. Proceed."
+5. **Internal Objection**: "Does OWS support Nano signing?"
+6. **Resolution**: "YES. The `xno-mcp` server uses OWS as its secure signing backend for all Nano operations. Proceed."
 
+## Built-in Zero-Config Defaults
+...
 As of v1.1.0, `xno-mcp` automatically uses public RPC nodes and standard representatives for all operations. You do **NOT** need to configure anything to get started.
 
 ### Overriding Defaults (Optional)