selat-discovery

SELAT — discover, then pay (self-custody)

This is a concise DRIVER written for the plugin. The published @selat-ai/selat-discovery SKILL.md (bundled inside @selat-ai/selat-cli) remains the source of truth for exact subcommand flags, output shapes, and any commands added after the pinned CLI version. Where they conflict, the published skill wins. The command surface below was verified against @selat-ai/[email protected] and @selat-ai/[email protected].

SELAT is a capability layer for AI agents. It does two things a flat capability index doesn't: it checks vetted skills first, and it pays from the user's own wallet — SELAT never sees a private key or holds the user's funds.

The runner: how to invoke selat

All SELAT actions go through the selat runner (the published @selat-ai/selat-cli, which bundles the discovery skill and the selat-pay engine). Resolve it in this order:

1. Plain selat — the SessionStart hook puts it on PATH (immediately on hosts that persist hook env; in new shells elsewhere).
2. If bare selat doesn't resolve, use the $SELAT_RUNNER env var (an absolute path to the shim), where the host exports it.
3. If neither resolves, SELAT isn't available in this environment — tell the user rather than improvising. Do not hand-roll x402 requests or paste private keys.

Verify with selat doctor (read-only diagnostics: skill, PATH, Circle auth, Agent Wallet, config).

Setup is the user's, not yours (self-custody)

Payments settle from the user's own Circle Agent Wallet (Circle MPC). SELAT never holds keys or balance. So:

• Free discovery needs no wallet — selat search, selat skill list, and selat doctor run with zero setup. Lead with those; show the user what's available first.
• Only when the user wants to actually call/pay for a result and selat doctor reports the wallet/config is missing: ask the user and wait before selat init, a Circle OTP, or any spend. Do not auto-run selat init. After they agree, it installs the Circle CLI, then prompts for the user's Circle email + a 6-digit OTP (relay those — the user authenticates; in a chat-only harness the OTP necessarily passes through the chat — keep it out of logs and summaries, and never store it). On a non-interactive host (no usable TTY) or an account with several agent wallets, pass selat init --email <addr> --wallet <n|address> so it doesn't block on the email/wallet prompts — --wallet takes a 1-based index from the list init prints, a 0x address, or new (also settable via SELAT_WALLET); without it a multi-wallet account stops at Wallet to use [1-N/new], which a non-TTY shell can't answer. Don't run selat init before it's needed, pre-install Circle CLI, or improvise circle commands. selat fund and any paid call still need explicit approval and an armed session budget (selat budget start); selat freeze is the kill switch — never auto-fund or auto-pay.
• A --raw-key dev mode exists but is not for production — do not steer users to it.
• Before any spend, surface the cost and get the user's go-ahead. Spending limits are set via selat setup-policy (recommended before deposits > $20); funding via selat fund. Both are user-driven money actions — never run them unprompted.
• Funding is two movements: (1) top up the agent wallet address with USDC, then (2) selat fund deposits it into Gateway. For movement (1) there are two paths: a crypto transfer to the wallet address, or fiat via selat fund --onramp [--address 0x…] (selat-cli 0.15.17+) — it mints a Circle Onramp browser link, chain-scoped so purchases can't strand. The user picks the amount inside the widget — never ask for an amount before launching, and never treat the mint as a spend (nothing moves until the user completes the purchase in their browser; relay the printed URL into chat). To onramp a wallet other than the configured payer, pass --address 0x… — never rewrite the configured wallet to retarget funding. Never use circle wallet fund --method fiat for fiat: that opens Transak, a different, unscoped onramp. After funding, refer only to "the Gateway balance" — one number, spendable on any supported chain; never enumerate per-chain balances to the user. Verify it with circle gateway balance --all, or the Gateway line in selat doctor — never the wallet's on-chain address balance. A deposit moves USDC from the address into Gateway, so the on-chain balance dropping (even to 0) is by design, not lost money. Deposits take ~5–10 min to settle; a fresh 0 Gateway reading usually means "still settling" — don't tell the user funds are lost. If circle wallet balance and an on-chain read disagree, say "a fresh transfer can take a minute to be readable — let's re-check" — never speculate that Circle "holds" funds off-chain (reads just lag; that speculation manufactures a custodial misconception). When selat fund prints a QR image path, send that image to the user directly in chat harnesses — never just relay a file path the user can't open.