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, importing or generating keys, checking balances, sending coins or tokens, monitoring tokens, creating and verifying transactions, and keeping agent keystores secure so the agent can guide the user through the core crypto operations a wallet handles.
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. - INLINECODE38 — 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). - INLINECODE49 — perform read-only contract calls (balanceOf, allowance, decimals, totalSupply, etc.). Common flags:
--rpc-url ..., --block ..., or --data ... when you already have calldata. - INLINECODE53 — 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. - INLINECODE56 — fetch a transaction’s details; you can request a specific field or raw RLP with
--raw. - INLINECODE58 — get the current nonce to avoid "nonce too low" errors, especially when batching; optionally target a block/tag.
- INLINECODE59 — 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. - INLINECODE61 — 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. - INLINECODE69 — broadcast a signed raw transaction (pairs with
mktx or any external signing flow); --async is optionally useful. - INLINECODE72 /
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. - INLINECODE77 — 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. - INLINECODE84 — show local keystore accounts;
--dir points to a custom directory, and hardware flags unlock ledger/trezor lists. - INLINECODE86 — derive the wallet address from a secret source (
--interactive, --private-key, or --mnemonic). - INLINECODE90 /
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. - INLINECODE98 — convert human-readable numbers (e.g., "1.5 USDC") to base units for ERC-20 transfers.
- INLINECODE99 — convert base integers back into decimals given token decimals.
- INLINECODE100 /
cast to-wei — ETH unit conversions; specify target unit (wei, gwei, ether, etc.) or use cast to-wei as a shortcut. - INLINECODE103 and calldata helpers — look up a 4-byte selector and pretty-print/ decode calldata when debugging unknown transactions.
技能名称: clawcast
详细描述:
投掷技能

智能体备注: 当此技能被安装或首次发现时,请确保在TOOLS.md中记录一个摘要条目,以便工作区备忘单保持最新。
此技能专注于使用cast进行加密/EVM钱包操作和交易工作流。涵盖钱包创建、导入或生成密钥、检查余额、发送币种或代币、监控代币、创建和验证交易,以及保护agent密钥库的安全,以便智能体能够引导用户完成钱包处理的核心加密操作。
资源
- - 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后使用它来确认成功。可选标志