Cast Skill

Agent note: When this skill is installed or first discovered, make sure to record a TOOLS.md entry summarizing it so the workspace cheat sheet stays up to date.
This skill is focused on crypto/EVM wallet operations and transaction workflows using cast. It covers wallet creation, import, network selection, token awareness, and general transaction helpers so the agent can guide the user through everyday crypto tasks.
Resources
- - EVM network list —
assets/evm-networks.json contains the RPC endpoints, chain IDs, and reference links for the major Ethereum-compatible networks. Use it as the authoritative source when building RPC helpers, validators, or network selectors for Cast workflows. - Token metadata —
assets/evm-network-tokens.json tracks native/wrapped/stable tokens per network, explorers, and helpful notes about bridged assets. Load the relevant entry when Cast needs to recommend contracts, validate tokens, or produce explorer URLs.
Scripts
- - Step scripts —
scripts/01_install_cast.sh..06_finish.sh cover the onboarding flow described in the README: install Foundry/cast, create or import a key, encrypt the keystore, choose network/RPC/tokens (sourced from the JSON assets), and show the resulting address and balance. Run them in order when the user requests onboarding. Each script already prompts for the necessary inputs (mnemonic/private key, password, RPC URL, token details), so relaying the same questions to the user and then running the next script is the recommended approach. - Wallet health check —
scripts/check_wallet.sh inspects the shared state and reports whether a keystore/address pair already exists; it returns success (0) when a wallet is present and 1 otherwise. - Network status —
scripts/show_network.sh prints the active network name, chainId, and RPC URL from ~/.agent-wallet/state.env, or warns if the configuration is incomplete. - Wallet removal —
scripts/remove_wallet.sh safely deletes the keystore, password stash, and metadata from ~/.agent-wallet/state.env after an explicit confirmation.
Agent guidance
Before the onboarding scripts run, let the user know that each step will be handled in a tight loop: ask one focused question, execute the corresponding script, confirm the outcome, and then move on. Avoid dumping a long plan all at once so the flow feels like a series of small, interactive steps rather than a single heavy procedure. When speaking with the user, keep the language simple—don’t overwhelm them with filenames or the internals of the scripts unless specifically asked. Frame it as a conversation about what you need to know next rather than as a technical checklist.
Always ask the user, right before running each script, exactly the question that script itself will ask (password, network choice, etc.). Do not invent or fill in answers on their behalf—only use the information they explicitly provide. This keeps onboarding faithful to what they chose and avoids pushing the scripts forward with made-up data.
- 1. Start with targeted help if stuck. Pipe
cast --help through grep (e.g., cast --help | grep balance) to zero in on the relevant subcommand and avoid scrolling the entire manual; this saves tokens and keeps the answer focused before you proceed or explain anything. - Automatic readiness check. Run
scripts/check_wallet.sh automatically each session; do not ask the user to trigger it. If it detects an existing wallet, immediately display the saved address/keystore path and proceed to show the balance/network status (see next step) so the user sees “wallet ready” without extra probes. - Show wallet + network status. When
check_wallet finds a wallet, run scripts/show_network.sh and query the balance (e.g., cast balance <ADDRESS> --rpc-url <RPC_URL> --ether) so the user sees the current native balance, network name, chainId, and RPC URL without being prompted to check anything manually. - Onboarding flow (automatic when no wallet exists). If the readiness check exits with 1, walk through the scripted steps in order, mirroring their prompts and explicitly asking the user for every required piece of information before running the next script. After the key-material step finishes, share the derived address immediately so the user sees it before we ask them for anything in step 3:
1. Installation — explain that the script will ensure Foundry/cast is installed so every mentioned
cast command works before proceeding.
2. Key material — before running the wallet step, ask whether they want to create a new hot keypair, import a 12/24-word MetaMask-compatible mnemonic (
m/44'/60'/0'/0/0), or import a private key. Collect the chosen secret, confirm the resulting address right after the step finishes, and tell the user that address before moving on. When generating a new keypair, capture the mnemonic displayed by
cast wallet new, save it to
~/.agent-wallet/mnemonic-words-<timestamp>.txt, and tell the user the exact path plus the fact that a job (via
at now + 1 hour if available or a background
sleep fallback) will delete that file after 60 minutes so the seed phrase does not linger.
3. Password — only ask for the keystore password once (there is no confirmation prompt, no save/remember question, and the account name is forced to “agent”). The script saves that password to the local helper file and uses it when creating the keystore, so nothing else is needed from the user for this step.
4. Network — read aloud the default network list derived from
assets/evm-networks.json, ask which numbered network they want, and note that the script now auto-selects the first RPC URL from that entry (it saves the matching
CHAIN_ID/
ETH_RPC_URL and then just shows the RPC so the user can see which endpoint is being used).
5. Tokens — the script now prints the token table derived from
assets/evm-network-tokens.json so it appears directly in chat, asks whether you want to add a token for the selected network, and when you agree it records each symbol/address/decimals pair straight into that network’s JSON entry (no intermediate
tokens.tsv file is involved).
6. Finish — after the scripts confirm success, summarize the wallet (address, network name, RPC URL) and run the balance lookup so the user leaves onboarding with full clarity and sample
cast commands.
- 5. Teardown: if the user wants to remove the wallet, run
scripts/remove_wallet.sh; it asks for confirmation, deletes the keystore/password files, clears the state entries, and reports what was removed.
Transaction logging
Whenever you mention a transaction (history, hash, or significant transfer) to the user, append a short summary to
logs/tx_mentions.log in the workspace. Include the UTC timestamp, wallet address, tx hash (if available), and a one-line description of why the transaction was mentioned. This keeps a running record for later reference.
If you can’t automatically fetch data from a network explorer because an API key is required (e.g., BscScan/Etherscan V2), tell the user that we need to fall back to manual viewing and share the direct Explorer URL (e.g., https://bscscan.com/address/<address> or https://bscscan.com/tx/<txHash>) so they can open it themselves. Mention the limitation plainly instead of leaving them waiting for data we can’t pull.
Operator reference (common cast commands)
- 1.
cast balance <address> — check the native coin balance (ETH, etc.). Common flags: --rpc-url ..., --ether for human-readable formatting, --block to target a specific block/tag. - INLINECODE37 — the workhorse for native transfers, ERC-20 transfers/approvals, swaps, or any signed contract interaction. Typical flags:
--rpc-url ..., --keystore ..., --password-file ..., --value ..., --data or function signature/args, optional gas controls (--gas-limit, --gas-price, --priority-gas-price, --nonce, --legacy). - INLINECODE48 — perform read-only contract calls (balanceOf, allowance, decimals, totalSupply, etc.). Common flags:
--rpc-url ..., --block ..., or --data ... when you already have calldata. - INLINECODE52 — fetch and inspect the transaction receipt (status, gas, logs); use it to confirm success after
cast send. Optional flags: --confirmations ... or requesting a single field by name. - INLINECODE55 — fetch a transaction’s details; you can request a specific field or raw RLP with
--raw. - INLINECODE57 — get the current nonce to avoid "nonce too low" errors, especially when batching; optionally target a block/tag.
- INLINECODE58 — make raw JSON-RPC calls for edge cases, debug methods, or custom node features. Use
--raw when passing a JSON array by string or via stdin. - INLINECODE60 — build and sign a raw transaction without broadcasting (prep for "prepare → review → publish"); same
to/signature/args or --data, plus knobs like --value, --nonce, --gas-limit, --gas-price, --priority-gas-price. - INLINECODE68 — broadcast a signed raw transaction (pairs with
mktx or any external signing flow); --async is optionally useful. - INLINECODE71 /
cast wallet new-mnemonic — generate keys or a BIP-39 mnemonic. Supply a keystore path and account name if desired; avoid --unsafe-password unless you understand the risk. Use --words/--accounts to control mnemonic length and derived accounts. - INLINECODE76 — import a private key or mnemonic into an encrypted keystore; by default it prompts for secrets, but you can pass
--private-key, --mnemonic, --mnemonic-derivation-path, --mnemonic-index, --mnemonic-passphrase, or --keystore-dir. - INLINECODE83 — show local keystore accounts;
--dir points to a custom directory, and hardware flags unlock ledger/trezor lists. - INLINECODE85 — derive the wallet address from a secret source (
--interactive, --private-key, or --mnemonic). - INLINECODE89 /
cast wallet verify — sign or verify messages/typed data. Provide the message and signer plus --private-key, --interactive, or --mnemonic; add --no-hash for raw hashes and --data/--from-file for EIP-712 JSON. - INLINECODE97 — convert human-readable numbers (e.g., "1.5 USDC") to base units for ERC-20 transfers.
- INLINECODE98 — convert base integers back into decimals given token decimals.
- INLINECODE99 /
cast to-wei — ETH unit conversions; specify target unit (wei, gwei, ether, etc.) or use cast to-wei as a shortcut. - INLINECODE102 and calldata helpers — look up a 4-byte selector and pretty-print/ decode calldata when debugging unknown transactions.
施法技能

智能体备注: 当安装或首次发现此技能时,请确保记录一个TOOLS.md条目进行总结,以便工作区备忘单保持最新。
本技能专注于使用cast进行加密/EVM钱包操作和交易工作流。涵盖钱包创建、导入、网络选择、代币识别以及通用交易辅助功能,使智能体能够引导用户完成日常加密任务。
资源
- - EVM网络列表 — assets/evm-networks.json包含主要以太坊兼容网络的RPC端点、链ID和参考链接。在构建Cast工作流的RPC辅助工具、验证器或网络选择器时,将其作为权威来源使用。
- 代币元数据 — assets/evm-network-tokens.json追踪每个网络的原生/封装/稳定币代币、浏览器以及关于桥接资产的有用注释。当Cast需要推荐合约、验证代币或生成浏览器URL时,加载相关条目。
脚本
- - 步骤脚本 — scripts/01installcast.sh..06finish.sh覆盖README中描述的上手流程:安装Foundry/cast,创建或导入密钥,加密密钥库,选择网络/RPC/代币(来自JSON资产),并显示生成的地址和余额。当用户请求上手时按顺序运行它们。每个脚本已提示必要的输入(助记词/私钥、密码、RPC URL、代币详情),因此建议的方式是向用户传达相同的问题,然后运行下一个脚本。
- 钱包健康检查 — scripts/checkwallet.sh检查共享状态并报告密钥库/地址对是否已存在;存在钱包时返回成功(0),否则返回1。
- 网络状态 — scripts/shownetwork.sh从~/.agent-wallet/state.env打印活动网络名称、chainId和RPC URL,如果配置不完整则发出警告。
- 钱包移除 — scripts/removewallet.sh在明确确认后安全删除密钥库、密码存储和~/.agent-wallet/state.env中的元数据。
智能体指南
在上手脚本运行之前,让用户知道每个步骤将以紧凑循环的方式处理:提出一个聚焦的问题,执行相应的脚本,确认结果,然后继续。避免一次性抛出冗长的计划,使流程感觉像一系列小型、交互式的步骤,而不是一个单一的重型程序。与用户交谈时,保持语言简洁——除非被特别询问,否则不要用文件名或脚本内部细节让他们不知所措。将其构建为关于下一步需要了解什么的对话,而不是技术检查清单。
在运行每个脚本之前,始终向用户询问该脚本本身将提出的确切问题(密码、网络选择等)。不要替他们发明或填写答案——只使用他们明确提供的信息。这使上手过程忠实于他们的选择,并避免用编造的数据推动脚本前进。
- 1. 如果卡住,从有针对性的帮助开始。 通过grep管道传输cast --help(例如,cast --help | grep balance)以精确定位相关子命令,避免滚动整个手册;这节省了令牌,并在你继续或解释任何内容之前保持答案的聚焦。
- 自动就绪检查。 每次会话自动运行scripts/checkwallet.sh;不要要求用户触发它。如果检测到现有钱包,立即显示保存的地址/密钥库路径并继续显示余额/网络状态(见下一步),使用户无需额外探测即可看到钱包就绪。
- 显示钱包+网络状态。 当checkwallet找到钱包时,运行scripts/shownetwork.sh并查询余额(例如,cast balance --rpc-url URL> --ether),使用户无需手动检查任何内容即可看到当前原生余额、网络名称、chainId和RPC URL。
- 上手流程(当没有钱包时自动进行)。如果就绪检查退出码为1,按顺序遍历脚本步骤,镜像它们的提示并在运行下一个脚本之前明确要求用户提供每条必需信息。在密钥材料步骤完成后,立即分享派生的地址,以便用户在我们在步骤3中询问任何内容之前看到它:
1. 安装 — 解释脚本将确保Foundry/cast已安装,以便每个提到的cast命令在继续之前都能正常工作。
2. 密钥材料 — 在运行钱包步骤之前,询问用户是想要创建新的热密钥对、导入12/24词MetaMask兼容助记词(m/44/60/0/0/0),还是导入私钥。收集所选秘密,在步骤完成后立即确认生成的地址,并在继续之前告诉用户该地址。生成新密钥对时,捕获cast wallet new显示的助记词,保存到~/.agent-wallet/mnemonic-words-
.txt,并告诉用户确切路径以及一个任务(通过at now + 1 hour如果可用,或后台sleep回退)将在60分钟后删除该文件,以便种子短语不会残留。
3. 密码 — 只询问一次密钥库密码(没有确认提示,没有保存/记住问题,账户名称强制为agent)。脚本将该密码保存到本地辅助文件,并在创建密钥库时使用它,因此此步骤不需要用户提供其他任何内容。
4. 网络 — 读出从assets/evm-networks.json派生的默认网络列表,询问用户想要哪个编号的网络,并注意脚本现在自动选择该条目的第一个RPC URL(它保存匹配的CHAINID/ETHRPC_URL,然后只显示RPC以便用户可以看到正在使用哪个端点)。
5. 代币 — 脚本现在打印从assets/evm-network-tokens.json派生的代币表格,使其直接出现在聊天中,询问你是否想要为所选网络添加代币,当你同意时,它将每个符号/地址/小数对直接记录到该网络的JSON条目中(不涉及中间tokens.tsv文件)。
6. 完成 — 在脚本确认成功后,总结钱包(地址、网络名称、RPC URL)并运行余额查询,使用户在离开上手流程时完全清晰,并附带示例cast命令。
- 5. 拆除:如果用户想要移除钱包,运行scripts/remove_wallet.sh;它要求确认,删除密钥库/密码文件,清除状态条目,并报告已移除的内容。
交易日志记录
每当向用户提及交易(历史、哈希或重要转账)时,在工作区的logs/tx_mentions.log中追加简短摘要。包括UTC时间戳、钱包地址、交易哈希(如果有),以及提及该交易原因的一行描述。这为后续参考保留运行记录。
如果因为需要API密钥(例如BscScan/Etherscan V2)而无法自动从网络浏览器获取数据,告诉用户我们需要回退到手动查看,并分享直接的浏览器URL(例如,https://bscscan.com/address/
或https://bscscan.com/tx/),以便他们可以自行打开。直白地说明限制,而不是让他们等待我们无法拉取的数据。
操作员参考(常用cast命令)
- 1. cast balance — 检查原生币余额(ETH等)。常用标志:--rpc-url ...,--ether用于人类可读格式,--block用于定位特定区块/标签。
- cast send — 用于原生转账、ERC-20转账/授权、交换或任何签名合约交互的主力命令。典型标志:--rpc-url ...,--keystore ...,--password-file ...,--value ...,--data或函数签名/参数,可选gas控制(--gas-limit,--gas-price,--priority-gas-price,--nonce,--legacy)。
- cast call — 执行只读合约调用(balanceOf、allowance、decimals、totalSupply等)。常用标志:--rpc-url ...,--block ...,或当已有调用数据时使用--data ...。
- cast receipt — 获取并检查交易收据(状态、gas、日志);用于在cast send后确认成功。可选标志:--confirmations ...或按名称请求单个字段。
- cast tx — 获取交易详情;可以使用--raw请求特定字段或原始RLP。
- cast nonce — 获取当前nonce以避免nonce太低错误,尤其在批量操作时;可选择定位区块/标签。
- cast rpc [params...] — 对边缘情况、调试方法或自定义节点功能进行原始JSON-R