@visa/cli 4.1.0-rc.3 → 4.1.0-rc.300

package/dist/skills/pair-visa-agent/SKILL.md

@@ -0,0 +1,453 @@
+---
+name: pair-visa-agent
+description: Set up a Visa CLI v4 agent through the single protected enrollment implementation, using the entrance this build advertises, and report its live capabilities honestly. The owner always approves in their browser. Use when the user says "pair my agent", "connect Visa", "enroll my Visa CLI", "set up my agent", or "let this agent pay".
+compatibility: Needs the `visa` CLI (`npm i -g @visa/cli@rc`) — run `node scripts/setup.mjs` to install it if missing — plus network access to the Visa authorization service. Works in OpenClaw, Hermes, Claude Code, Codex, or any Agent Skills runtime.
+allowed-tools: Bash(visa:*) Bash(visa-cli:*) Bash(node:*) Bash(npm:*) Bash(npx:*)
+metadata:
+  author: visa
+  homepage: https://visacli.sh/agents
+  version: '0.8.0'
+  # OpenClaw-namespaced extension (agentskills.io keeps `metadata` free-form, so
+  # non-standard runtime config lives here — `user-invocable` is not a standard
+  # top-level field). OpenClaw auto-installs `install[]` when `requires.bins` are
+  # missing; other runtimes (Hermes, Claude Code, …) self-provision via the
+  # bundled `scripts/setup.mjs` (see compatibility + Getting set up). @rc pinned
+  # until 4.1.0 is promoted to latest.
+  openclaw:
+    user-invocable: true
+    emoji: '🔐'
+    requires:
+      bins:
+        - visa
+    install:
+      - kind: node
+        package: '@visa/cli@rc'
+        bins:
+          - visa
+          - visa-cli
+---
+
+# Set up a Visa agent
+
+One command carries everything: this runtime's identity, the binding to **this
+device**, and the spending limits — behind a **single** owner approval in their browser.
+
+**Today, the command is run by the OWNER in their terminal.** On one-door builds that
+advertise it, an agent may instead call `agent_enroll` and hand the owner its returned
+link, or the owner runs `visa agent enroll`. These are two entrances to the exact same
+protected enrollment implementation: the same native signer, Authority routes, owner
+browser approval, and limits. Never invent or mix in a second ceremony.
+
+```
+# the human runs this:
+visa agent enroll-protected \
+  --authority-url <origin> --auth-url <origin> --url <origin> --wait
+
+   → it prints a URL and a short code
+   → the human opens the URL and enters the code at /agent/enroll/protected-agent
+   → the human approves the device and its spending limits        (one approval)
+   → the command finishes; `get_status` now reports pairing.paired: true
+```
+
+All three origins are required today; the operator supplies them. If the human does not
+know them, ask — do not guess an origin, and never construct a Visa URL yourself.
+
+Running the same command again resumes an interrupted enrolment; `--restart` replaces an
+unclaimed request with a fresh code. `--ceiling <usd>` and `--per-transaction <usd>`
+propose limits the owner confirms on the approval page.
+
+## The older ceremonies were deleted — do not call them
+
+`setup_start`, `setup_status`, `setup_resume`, `setup_cancel`, `setup_agent`,
+`enroll_agent`, `agent_connect`, `agent_connect_poll`, `agent_connect_cancel`,
+`agent_handoff_claim` and `agent_pairing_cancel` are gone, along with the `visa setup`
+group and `visa agent pair|create|verify|enroll|enroll-claim|claim|pairing-resume|connect|grant-card|grant-wallet|grant-activate|grant-claim|handoff-claim`.
+
+Calling any of them returns one refusal:
+
+```json
+{ "code": "legacy_door_removed", "kind": "caller", "fix": "visa agent enroll-protected" }
+```
+
+That code means the door no longer exists. **Relay the replacement and stop.** Do not
+retry it, do not try a variant spelling, and do not report it to the human as an outage:
+nothing was signed, paired, or paid.
+
+## What "set up" means here
+
+Each completed protected enrollment mints a **new** agent: a new server-assigned agent,
+a new device-held Ed25519 identity key, and the wallet limits the owner approved.
+
+- The runtime keeps the private Ed25519 key and sends only the public JWK.
+- The limits are the ones the owner actually approved on the page. Nothing you asked for
+  is granted until they approve it.
+- An email address, a `.visa` mesh name, and TAP bindings remain separate, later
+  configuration. Do not infer them from a finished enrolment.
+
+**Where the `agentId` comes from — read this before you quote one.** Do not invent it and
+do not read it out of the command's terminal output, which you often cannot see. Read it
+from `get_status` or `agent_capabilities` once the enrolment finishes. Never substitute a
+correlation id, a confirmation code, or an origin for an `agentId`.
+
+**Re-running the command does not repair an agent that already exists** — it creates a
+second one. To fix a capability an existing agent is missing, see "Already set up — do NOT
+enrol again" near the end.
+
+## Getting this skill
+
+The skill ships inside the public `@visa/cli` npm package. No clone of the private
+monorepo is required:
+
+```sh
+npm install -g @visa/cli@rc
+visa agent skill
+```
+
+`visa agent skill` auto-detects OpenClaw, Hermes, Claude Code, and Codex, falling back to
+the project-local `./.agents/skills`. Pass `--runtime <name>` or `--dir <path>` to choose a
+target, `--force` to overwrite, or `--print` to read without writing. Reload or restart
+the agent runtime after installation so it registers the skill.
+
+Access remains enforced by the Visa service. Installing the public package or skill does
+not authorize an account to pair.
+
+OpenClaw users receive the skill via `visa agent skill --runtime openclaw` (or through the `@visa/visa-cli-openclaw` plugin when running from source).
+
+## Getting set up
+
+1. **Install the prerelease CLI.** Run `npm install -g @visa/cli@rc`, or run the bundled
+   idempotent provisioner `node scripts/setup.mjs`. The `@latest` tag may not yet expose
+   the v4 setup tools. Installation puts `visa` and `visa-cli` on `PATH` and includes
+   `@visa/cli/dist/mcp-server/index.js`.
+2. **Mount the MCP server when the runtime supports MCP.**
+   - **OpenClaw:** run `visa agent skill --runtime openclaw` (or `visa-cli connect openclaw`)
+     to install the skill and write `mcp.servers["visa-cli"]` in `~/.openclaw/openclaw.json`.
+     (Installing `@visa/visa-cli-openclaw` from source/tarball also auto-mounts the server).
+   - **Hermes or another supported runtime:** run `visa-cli connect hermes` or
+     `visa-cli connect <runtime>`. For Hermes, the entry is written under `mcp_servers`
+     in `~/.hermes/config.yaml`.
+   - **No MCP integration:** everything below still works — the enrolment is a shell
+     command, and `--format json` output is available on the management commands.
+3. **Sign the owner in** — see "Sign in first" below.
+4. **Enrol.** Follow the core flow below.
+
+## MCP mounting examples
+
+Both runtimes use the same server entrypoint. Replace `<npm root -g>` with the output of
+`npm root -g`.
+
+OpenClaw (`~/.openclaw/openclaw.json`):
+
+```json
+{
+  "mcp": {
+    "servers": {
+      "visa-cli": {
+        "command": "node",
+        "args": ["<npm root -g>/@visa/cli/dist/mcp-server/index.js"]
+      }
+    }
+  }
+}
+```
+
+Hermes (`~/.hermes/config.yaml`). **Hermes passes ONLY this `env:` map to the MCP
+subprocess — it does NOT inherit the gateway environment.** Omitting a required variable
+(an RC access code, the right `HOME`, `PATH`) makes the server exit on every start while
+`agent_capabilities` — which reads on-disk grant state, not live tool registration — can
+still report rails as available. Always set the map explicitly:
+
+```yaml
+mcp_servers:
+  visa-cli:
+    command: node
+    args: ['<npm root -g>/@visa/cli/dist/mcp-server/index.js']
+    # Hermes does NOT inherit the gateway env. This map is the entire
+    # subprocess environment; omit VISA_RC_CODE and the server exits on boot.
+    env:
+      HOME: /home/<user> # the home that holds this runtime's .visa-cli state
+      VISA_RC_CODE: <access code>
+      PATH: /usr/local/bin:/usr/bin:/bin
+```
+
+Hermes also loads skills **per profile** from `~/.hermes/profiles/<profile>/skills/`, not
+from `~/.hermes/skills/`. `visa agent skill --runtime hermes` resolves this automatically:
+it targets the single profile when exactly one exists (or the one named by
+`HERMES_PROFILE`), and **fails loudly** on a multi-profile box instead of planting into
+the flat dir nothing reads — pass `--dir ~/.hermes/profiles/<profile>/skills` to choose.
+
+**Hermes sanitizes MCP server names when registering tools.** A server declared
+`visa-cli` in `mcp_servers:` registers its tools as `mcp__visa_cli__<tool>` — with an
+UNDERSCORE, not the declared hyphen. Anything that hardcodes `mcp__visa-cli__<tool>` gets
+`unknown tool` on every call while looking correct in review. Read tool names off the
+live registry; never derive them from the config key.
+
+In Hermes, `hermes claw migrate` can also import this skill and MCP configuration from an
+existing OpenClaw installation. See `RUNTIMES.md` for the complete runtime map.
+
+## Sign in first — the wallet is owner-bound
+
+The USDC wallet is delegated out of the owner's own wallet, so this runtime needs a live
+owner session. Establish it **before** the enrolment command runs:
+
+- [ ] Call `agent_login` (MCP, default action `"start"`) or run
+      `visa agent login --format json` (CLI). The result carries a sign-in `browserUrl`
+      and a short 6-character `confirmCode`.
+- [ ] Relay **both** to the human in your reply — the bare URL on its own line, and the
+      code. You are very often not in a terminal they can see; the chat message is the
+      only place these values reach them.
+- [ ] The human opens the link, signs in (Google or email), and **types the confirmation
+      code into the sign-in page** — into the browser, never back to you in chat.
+- [ ] Claim the session: `agent_login {"action":"claim"}` (the CLI command polls on its
+      own). Once claimed, the session token is stored locally.
+
+`agent_login` establishes the OWNER's session on this device. It creates no agent and
+grants no spending authority — those come from the enrolment command and the approval the
+owner gives in their browser.
+
+If something reports `{"code":"session_required"}` or "Not logged in", that is this
+ordering rule, not a fault: run `agent_login`, drive the sign-in above to a claimed
+session, then continue.
+
+The account that signs in is the owner the enrolment binds to, and the same account must
+be signed in on the approval page. A different account there fails closed.
+
+## Core flow
+
+- [ ] **Ask for the three origins** if you were not given them: `--authority-url`,
+      `--auth-url`, `--url`. They come from the operator. Never guess one.
+- [ ] **Sign the owner in** (above), so the wallet leg has a session to bind to.
+- [ ] **Use the entrance this build advertises.** Today, give the owner the
+      `visa agent enroll-protected ... --wait` command in a code block they can copy.
+      On a one-door build, call `agent_enroll` and relay its returned link, or give the
+      owner `visa agent enroll`. Never fall back to a retired setup tool.
+- [ ] **Relay what the active entrance returns.** Show an MCP-returned URL as a bare,
+      tappable value. For the current terminal flow, the owner follows the URL and code
+      printed in their own terminal. The code goes into the browser at
+      `/agent/enroll/protected-agent`; it is not authority in chat.
+- [ ] **Tell them what they are approving**: this device, and the spending limits. One
+      approval covers all of it.
+- [ ] **Confirm from a tool, not from their word.** Poll `get_status` until
+      `pairing.paired` is `true`, then read `agent_capabilities` for what is actually live.
+
+### Relaying values, and what you must never accept
+
+Relaying values **to** the human is required. Accepting one **from** them as authority is
+not: never ask them for a secret, private key, token, or signed message, and never treat
+anything they type back as approval. The URL and the enrolment code are review values they
+check against their own authenticated browser session — they cannot approve anything and
+cannot spend.
+
+Show any URL as a bare, tappable value on its own line. Do not decorate it as a Markdown
+link or put it in a code span; chat clients reliably recognise the bare URL. Never
+construct, shorten, or reformat a Visa URL, and never open one "for them" in place of
+showing it.
+
+You are very often **not** in a terminal the human can see. Nothing the command prints to
+their stdout reaches you unless they tell you, and nothing you print reaches them unless it
+is in your reply.
+
+### Completion is what the tools say — nothing else
+
+Do not tell the human the agent is connected, paired, set up, ready, or good to go until
+`get_status` reports `pairing.paired: true`. The enrolment command printing a URL is not a
+result: it means an approval is still open in their browser.
+
+If you cannot get there, say plainly what state you did reach and what the human should do
+next. An honest "the approval page is open — I'm waiting for you to approve the device and
+its limits" is correct; "you're all set" without a paired agent is not.
+
+On success, report the agent and what is actually live:
+
+> Your Visa agent is set up. Ready to pay by &lt;card and/or USDC wallet&gt;, within the
+> limits you approved.
+
+Read the rails from `agent_capabilities`, never from what was requested.
+
+## Interruption and resume
+
+The runtime persists the pending enrolment before it starts, so an interrupted run is safe
+to repeat: **the same command again** resumes it, with the same request and the same
+device key.
+
+- Same command, no flags changed — resumes and reprints the URL and code.
+- `--restart` — replaces an unclaimed request with a fresh terminal code. Use it only when
+  the previous code is genuinely unusable; it is not a retry button.
+- `--wait` — keeps the command polling until the owner has approved, instead of returning
+  after printing the link.
+
+Do not tell the human to run a second, different enrolment because the first went quiet.
+Two enrolments mean two agents, two identities, and a confused owner. Do not delete or edit
+local pending files to fix a transient failure, and never copy pending state between
+runtimes.
+
+## Management commands (an agent that already exists)
+
+```
+visa agent list --format json
+visa agent show <agentId> --format json
+visa agent spendability --format json    # can it spend, and what is missing
+visa agent preflight --format json       # every gate before a payment
+visa agent pause|resume|revoke <agentId>
+visa agent keychain status|repair        # this device's identity custody
+```
+
+None of these creates an identity. Prefer structured output and parse it; never scrape
+prose.
+
+## Already set up — do NOT enrol again
+
+If this device already holds an agent, a fresh enrolment is not needed and creates a
+_second, separate_ agent. Do this instead:
+
+1. **Tell the user plainly:** "This device is already set up as `<name>`." Read the name
+   from `agent_capabilities` or `visa agent list`. Start another enrolment only if they
+   explicitly want a second agent.
+2. **Report status honestly — "set up" is several separate things.** Never imply the agent
+   can spend just because it exists. Read it live from tools rather than guessing from
+   prose: `agent_capabilities` returns the DERIVED capability map, `get_status` reports
+   pairing / account / version, `visa agent spendability --format json` answers "can it
+   spend, and what is missing", and `agent_login` establishes or confirms the account
+   session.
+   - **Identity** — bound to _this user's_ account, on _this device_.
+   - **Spending** — the limits the owner approved in the browser. You **cannot** self-grant
+     either rail, and never self-mint a wallet with `wallet_init` on mainnet — it throws
+     `WalletCredentialRequiredError` until the owner's delegation lands.
+   - **Mesh (`.visa` messaging)** — separate; `visa register <name>` joins it.
+   - **Trusted (TAP)** — follows spend/provisioning; don't promise it before then.
+3. **Scope everything to the user.** The identity is bound to the account they signed in
+   with; the wallet and limits are theirs. Speak in terms of "your agent / your account /
+   the limits you approved", never a shared identity.
+
+## An existing agent is missing a capability
+
+There is no rail-add ceremony any more: `visa agent grant-card` / `grant-wallet` /
+`grant-activate` / `grant-claim` and the `agent_connect` tools were deleted, and calling
+one returns `legacy_door_removed`.
+
+What to do instead:
+
+- [ ] **Diagnose first.** `visa agent spendability --format json` and
+      `agent_capabilities` say exactly what is missing. Do not start anything before you
+      know which of identity, wallet delegation, card authority or funding is absent.
+- [ ] **If the device's identity custody is broken**, `visa agent keychain repair` fixes
+      it without minting a new agent.
+- [ ] **If the OWNER never approved that authority**, only they can add it. Say so, name
+      what is missing, and stop. Enrolling again mints a NEW agent — it does not upgrade
+      this one, and doing it silently leaves the owner with two agents and one funded
+      wallet.
+
+A policy refusal or timeout means **nothing was signed**: report it and stop; do not retry
+with a different command or a reconstructed URL. Never raise a human-approved limit
+yourself.
+
+## Spending, once a rail is live
+
+Wallet: set the policy with `wallet_policy_set` (per-transaction / daily / session USD
+caps plus optional network and merchant allow/deny lists that refuse an x402 payment
+BEFORE it is signed), then `wallet_pay`. The served wallet tools are `wallet_discover`
+(search the public x402 Bazaar), `wallet_probe` (read a challenge without paying),
+`wallet_pay` / `wallet_directory_pay` (pay, policy-enforced), `wallet_history` /
+`wallet_reconcile` (local ledger + resolve `reconciling` holds), `wallet_fund` (funding
+address + faucet), and `wallet_export` (export key material — dangerous). All spending is
+gated by the owner-approved local policy caps.
+
+Card: `start_card_mandate`, then `pay_merchant`. The first card purchase asks the owner
+for a spending mandate within the budget they already approved.
+
+The current card rail uses VIC browser checkout through `pay_merchant` after
+`start_card_mandate`; do not claim that browser checkout is unavailable before the card
+retirement change lands. On a hosted runtime, **every payment requires the owner's browser
+approval** until the protected no-tap executor lands. Enrollment, a session, or a spending
+grant does not approve a later hosted payment. Relay the hosted approval URL and wait for
+the owner's decision before reporting success or retrying.
+
+## Optional `.visa` mesh binding (separate from setup)
+
+Pairing does not register a `.visa` name, TAP key, or Subway peer. If the operator has
+separately enabled and registered those channel bindings, the mounted `visa-cli` MCP server
+may expose `subway_register`, `subway_send`, `subway_inbox`, and `subway_find`.
+
+Mesh messaging is available only on a compatible RC/dev build with `SUBWAY_MESH=visa` and
+a reachable `SUBWAY_RELAY_MULTIADDR`. If those tools or the relay are unavailable, report
+that clearly and stop. Do not imply that connecting an agent granted directory or
+messaging authority, and do not improvise another transport.
+
+## Optional agent mailbox (separate from setup)
+
+Connecting an agent does not provision an email address or inbox. If the agent needs a
+mailbox — e.g. to receive a merchant's account-signup or one-time-code email —
+connect one explicitly, from the connected runtime, with the raw CLI:
+
+```
+visa agent mail-connect <agentId>
+```
+
+This is CLI-only; no pairing step or MCP tool connects a mailbox. It requires an
+already-connected stable-agent identity on this runtime — it reads the local agent
+record and proves the Ed25519 identity to the service. It issues the stable
+agent mailbox if one does not exist, then stores an inbox-scoped credential in an
+owner-only `0600` runtime file so this runtime can read that one inbox.
+
+Be honest about scope. A mailbox grants an email address and the ability to read
+that inbox — nothing more. It is **not** identity, a wallet, spend authority, a
+card, or a `.visa` name, and it never authorizes a payment. Do not claim setup
+set up mail. Once connected, the MCP `wallet_mail_status`, `wallet_mail_read`,
+and `wallet_mail_await_otp` tools read the inbox (e.g. to await a sender-checked
+one-time code); without the scoped credential those reads fail closed. Keep the
+org-wide AgentMail key off the runtime — provisioning happens only through
+`mail-connect` under operator control.
+
+## Optional checkout profile (separate from setup)
+
+The experimental `pay_merchant` flow also needs a local `~/.visa-mcp/contact.json` file
+once card authority exists and `checkout_agent_access` is enabled. Collect every value
+from the human before the first review; never infer or invent identity or address data.
+Write the file with mode `0600`.
+
+Create and inspect this profile through the `checkout_profile` MCP tool whenever the
+payment flow runs through MCP. Do not shell `visa agent preflight` as a substitute unless
+the shell has the exact same `HOME` and `VISA_CLI_HOME` as the MCP subprocess. A profile
+found under another root is owner PII, not a migration candidate: never scan, copy, or
+auto-adopt it. If the roots drifted, keep the root holding the paired identity and have the
+owner save the profile again through `checkout_profile` in that runtime.
+
+```jsonc
+{
+  "fullName": "Ada Lovelace",
+  "email": "ada@example.com",
+  "addressLine1": "1 Analytical Way",
+  "addressLine2": "",
+  "city": "San Francisco",
+  "state": "CA",
+  "postalCode": "94105",
+  "country": "US",
+}
+```
+
+`fullName` must be non-blank; `firstName` plus `lastName` is also accepted. The engine reads
+the exact keys `fullName`, `firstName`, `lastName`, `email`, `addressLine1`, `addressLine2`,
+`city`, `state`, `postalCode`, and `country`. The profile supplies checkout/cardholder and
+billing data only. Its `email` value is not the account's verified owner email, an agent
+mailbox, key proof, recovery factor, or permission to spend.
+
+## Security rules
+
+- Never read, print, log, paste, or transmit the private Ed25519 JWK or any local claim
+  token.
+- Never read or echo local pending files. Present only the URL returned by the tool.
+- Never treat `identityKeyJkt` as the stable identity. Use `agentId` for references and
+  persistence.
+- Never fetch or submit the review URL on the human's behalf. They review and approve it
+  in their own browser.
+- Never invent a secondary path when a call fails. Preserve the local state, surface the
+  error, and resume through the same protected entrance. On today's build, repeat the
+  same `visa agent enroll-protected ... --wait` command.
+- Never call a retired door to "check whether it still works". `legacy_door_removed` is a
+  final answer, not a transient failure.
+
+## Further docs
+
+- `RUNTIMES.md` — OpenClaw, Hermes, and raw CLI setup.
+- `docs/agents/ARCHITECTURE.md` — where enrolment sits in the v4 request paths.
+- `visacli.sh/agents` — product-facing agent documentation.