@zeroxyz/cli 0.0.22 → 0.0.24

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@zeroxyz/cli",
-	"version": "0.0.22",
+	"version": "0.0.24",
 	"type": "module",
 	"bin": {
 		"zero": "dist/index.js",

package/skills/zero/SKILL.md

@@ -33,7 +33,13 @@ Run these commands in order. Do not skip steps.
 
 **Step 1 — Install:** `npm i -g @zeroxyz/cli`
 
-**Step 2 — Initialize wallet:** `zero init` — generates a new wallet. Save the printed address. Or, to use an existing wallet: `zero wallet set <privateKey>` (0x-prefixed hex private key).
+**Step 2 — Provide a wallet.** Pick one path:
+
+- **New wallet (persistent):** `zero init` — generates a wallet and writes it to `~/.zero/config.json`. Save the printed address.
+- **Existing wallet (persistent):** `zero wallet set <privateKey>` — 0x-prefixed hex. Writes to `~/.zero/config.json`. Refuses to overwrite an existing wallet without `--force`.
+- **Existing wallet (ephemeral, e.g. CI):** set `ZERO_PRIVATE_KEY=0x...` in the environment. The CLI reads it at runtime and writes nothing to disk.
+
+**Prefer `zero init` or `zero wallet set` for local/interactive use** so the wallet persists across shells. Use `ZERO_PRIVATE_KEY` only when persisting to disk is undesirable — CI jobs, containers, one-off scripts, or secrets-manager-injected environments.
 
 **Step 3 — Fund wallet:** `zero wallet fund` — opens browser to add USDC (Base). For manual transfer: `zero wallet fund --manual`.
 
@@ -41,7 +47,7 @@ Run these commands in order. Do not skip steps.
 
 ### Setup Rules
 
-- If `ZERO_PRIVATE_KEY` is set in the environment, the CLI uses that key instead of the one from `zero init`.
+- Precedence: `ZERO_PRIVATE_KEY` (env) > `~/.zero/config.json`. If the env var is set, it wins even when a config file exists — useful for overriding on a single invocation (`ZERO_PRIVATE_KEY=0x... zero wallet balance`).
 - Wallet must be funded with USDC on Base before calling paid capabilities.
 
 ## After Setup
@@ -105,7 +111,9 @@ zero fetch https://api.example.com/expensive --max-pay 0.50
 
 ### Rules
 
-- Always discover capabilities with `zero search` + `zero get` before calling; never guess endpoint URLs or schemas.
+- **Always `zero search` fresh, every time.** Never reuse a capability URL, slug, schema, or price from an earlier turn, prior conversation, training data, or memory. Capabilities churn constantly — endpoints go offline, prices change, schemas evolve, and rankings shift as reviews accumulate. A capability that worked yesterday may be dead, repriced, or outranked today. Searching again costs nothing and is the only way to get current trust scores and availability.
+- **Always `zero get` before `zero fetch`.** Even if you "know" the URL, re-fetch the full details to confirm the URL, method, required headers, body schema, and current price. Do not reconstruct a fetch call from memory.
+- Never guess endpoint URLs or schemas.
 - Use `--max-pay` before potentially expensive requests.
 - Review capabilities after every paid call. The review signal feeds search ranking — skipping reviews means your next search is less informed.
 - Before ending a multi-call task, run `zero runs --unreviewed` and review anything you missed.
@@ -117,6 +125,14 @@ zero config                              # view current config
 zero config --set lowBalanceWarning=2.0  # warn when balance drops below $2
 ```
 
+## Reporting a Zero Platform Bug
+
+`zero bug-report "<what broke>"` exists for **Zero platform issues** — bad search ranking, indexed URL is wrong, billing was off, CLI itself misbehaved. **Only use it when the user explicitly asks** ("file a bug", "report a bug to Zero"). Never substitute it for `zero review` — capability quality (good/bad result, accuracy, value) always belongs in a review.
+
+```bash
+zero bug-report "Search ranked the wrong API first for BTC price"
+```
+
 ## Examples
 
 ### Translate text