cli-cast

Name: cli-cast
Author: PaulRBerg

241installs3forks

How to install cli-cast?

paulrberg/agent-skills/cli-cast

$npx -y skills add PaulRBerg/agent-skills --skill cli-cast

Installs into the current project.

Summary

Use for Foundry cast/on-chain actions: prepare, simulate, sign, or broadcast transactions; call contracts; sign messages; encode/decode ABI/calldata; or make RPC calls. For read-only balances/history, prefer evm-atlas.

Files · 1

View on GitHub

SKILL.md

1	# Foundry Cast CLI
2
3	Separate read, preparation, simulation, signing, and broadcast so no state-changing action is hidden inside command
4	construction.
5
6	## Resolve Chain and RPC
7
8	Resolve the target chain through `evm-atlas`. Use RouteMesh only when that chain is supported and `ROUTEMESH_API_KEY` is
9	available:
10
11	```text
12	https://lb.routeme.sh/rpc/CHAIN_ID/ROUTEMESH_API_KEY
13	```
14
15	Otherwise use the target chain's verified public RPC. Read [references/chains.md](references/chains.md) only as a
16	limited fallback when `evm-atlas` is unavailable. Never infer Ethereum when the chain is ambiguous.
17
18	## Authority Phases
19
20	### Read
21
22	Read-only calls, transaction/receipt inspection, ABI encoding/decoding, selector lookup, ENS resolution, and RPC queries
23	may run without a transaction approval. Prefer `evm-atlas` for balances, holdings, transfers, and history.
24
25	Use current `cast <command> --help` for exact syntax. Typical operations:
26
27	```sh
28	cast call "$CONTRACT" 'balanceOf(address)(uint256)' "$ACCOUNT" --rpc-url "$RPC_URL"
29	cast tx "$TX_HASH" --rpc-url "$RPC_URL"
30	cast receipt "$TX_HASH" --rpc-url "$RPC_URL"
31	cast calldata 'transfer(address,uint256)' "$TO" "$AMOUNT"
32	cast decode-calldata 'transfer(address,uint256)' "$CALLDATA"
33	```
34
35	For two or more compatible reads on one chain, batch through Multicall3 at `0xcA11bde05977b3631167028862bE2a173976CA11`.
36	Do not batch calls whose result depends on the original `msg.sender`.
37
38	### Prepare
39
40	Resolve and validate chain ID, sender, target, function signature, arguments, calldata, native value, nonce, and fee
41	assumptions without signing. Do not request or load key material during preparation.
42
43	### Simulate
44
45	Simulate the exact prepared call from the intended sender and value, then estimate gas. Use a fork or project simulation
46	when available; otherwise use read-only `cast call`, `cast estimate`, and trace facilities. A successful simulation is
47	evidence, not authorization to sign.
48
49	### Review
50
51	Before any signature or broadcast, present one concrete review containing:
52
53	- chain name and ID, RPC source, and latest block used;
54	- sender, target, function, decoded arguments, calldata, and native value;
55	- nonce, gas estimate/limit, fee assumptions, and maximum native-token cost;
56	- expected approvals, transfers, or other state changes;
57	- simulation command and outcome;
58	- selected signer and the exact signing/broadcast command with secrets redacted.
59
60	Lead the review with `### ⚠️ Transaction approval required`. Put repeated fields in a compact table, keep the exact
61	command in a fenced block, and state precisely what confirmation authorizes. Stop and require explicit user confirmation
62	of this review in a subsequent message. If any reviewed field changes, simulate again and present a revised review.
63
64	### Sign and Broadcast
65
66	Read [references/browser-signing.md](references/browser-signing.md) only after approval when a browser wallet is
67	available. Prefer browser, encrypted keystore, or hardware wallet in that order. Use an environment-backed private key
68	only when the user explicitly opts in or no safer method is available; never ask for a key in chat or print it.
69
70	`cast send` signs and broadcasts in one command. Run it only after the review approval. Signing a message or typed data
71	also requires a review of the exact payload, domain, chain binding, and intended use before approval.
72
73	After broadcast, capture the transaction hash and verify the receipt on the reviewed chain. Report status, block, gas
74	used, and the explorer link under `### ✅ Transaction confirmed` for a successful receipt or
75	`### ↩ Transaction reverted` for a mined failure. For an ambiguous outcome, lead with
76	`### ⛔ Broadcast unresolved — do not retry` and state the evidence still needed. Do not retry a failed or uncertain
77	broadcast without first checking whether the transaction exists.
78
79	## Stop Conditions
80
81	Stop before signing when the signer, sender, chain, target, decoded intent, cost ceiling, or simulation result is
82	unresolved. Stop before retrying when broadcast outcome is ambiguous. Completion requires either a verified read result,
83	an approved signature artifact, or a mined receipt matching the reviewed transaction. Never decorate or truncate
84	addresses, calldata, signatures, hashes, RPC URLs, fee values, commands, or safety wording.

People who liked this also viewed

6 picks

Type

cli-cast

241installs3forks

View on GitHub

How to install cli-cast?

paulrberg/agent-skills/cli-cast

$npx -y skills add PaulRBerg/agent-skills --skill cli-cast

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Foundry Cast CLI
2
3	Separate read, preparation, simulation, signing, and broadcast so no state-changing action is hidden inside command
4	construction.
5
6	## Resolve Chain and RPC
7
8	Resolve the target chain through `evm-atlas`. Use RouteMesh only when that chain is supported and `ROUTEMESH_API_KEY` is
9	available:
10
11	```text
12	https://lb.routeme.sh/rpc/CHAIN_ID/ROUTEMESH_API_KEY
13	```
14
15	Otherwise use the target chain's verified public RPC. Read [references/chains.md](references/chains.md) only as a
16	limited fallback when `evm-atlas` is unavailable. Never infer Ethereum when the chain is ambiguous.
17
18	## Authority Phases
19
20	### Read
21
22	Read-only calls, transaction/receipt inspection, ABI encoding/decoding, selector lookup, ENS resolution, and RPC queries
23	may run without a transaction approval. Prefer `evm-atlas` for balances, holdings, transfers, and history.
24
25	Use current `cast <command> --help` for exact syntax. Typical operations:
26
27	```sh
28	cast call "$CONTRACT" 'balanceOf(address)(uint256)' "$ACCOUNT" --rpc-url "$RPC_URL"
29	cast tx "$TX_HASH" --rpc-url "$RPC_URL"
30	cast receipt "$TX_HASH" --rpc-url "$RPC_URL"
31	cast calldata 'transfer(address,uint256)' "$TO" "$AMOUNT"
32	cast decode-calldata 'transfer(address,uint256)' "$CALLDATA"
33	```
34
35	For two or more compatible reads on one chain, batch through Multicall3 at `0xcA11bde05977b3631167028862bE2a173976CA11`.
36	Do not batch calls whose result depends on the original `msg.sender`.
37
38	### Prepare
39
40	Resolve and validate chain ID, sender, target, function signature, arguments, calldata, native value, nonce, and fee
41	assumptions without signing. Do not request or load key material during preparation.
42
43	### Simulate
44
45	Simulate the exact prepared call from the intended sender and value, then estimate gas. Use a fork or project simulation
46	when available; otherwise use read-only `cast call`, `cast estimate`, and trace facilities. A successful simulation is
47	evidence, not authorization to sign.
48
49	### Review
50
51	Before any signature or broadcast, present one concrete review containing:
52
53	- chain name and ID, RPC source, and latest block used;
54	- sender, target, function, decoded arguments, calldata, and native value;
55	- nonce, gas estimate/limit, fee assumptions, and maximum native-token cost;
56	- expected approvals, transfers, or other state changes;
57	- simulation command and outcome;
58	- selected signer and the exact signing/broadcast command with secrets redacted.
59
60	Lead the review with `### ⚠️ Transaction approval required`. Put repeated fields in a compact table, keep the exact
61	command in a fenced block, and state precisely what confirmation authorizes. Stop and require explicit user confirmation
62	of this review in a subsequent message. If any reviewed field changes, simulate again and present a revised review.
63
64	### Sign and Broadcast
65
66	Read [references/browser-signing.md](references/browser-signing.md) only after approval when a browser wallet is
67	available. Prefer browser, encrypted keystore, or hardware wallet in that order. Use an environment-backed private key
68	only when the user explicitly opts in or no safer method is available; never ask for a key in chat or print it.
69
70	`cast send` signs and broadcasts in one command. Run it only after the review approval. Signing a message or typed data
71	also requires a review of the exact payload, domain, chain binding, and intended use before approval.
72
73	After broadcast, capture the transaction hash and verify the receipt on the reviewed chain. Report status, block, gas
74	used, and the explorer link under `### ✅ Transaction confirmed` for a successful receipt or
75	`### ↩ Transaction reverted` for a mined failure. For an ambiguous outcome, lead with
76	`### ⛔ Broadcast unresolved — do not retry` and state the evidence still needed. Do not retry a failed or uncertain
77	broadcast without first checking whether the transaction exists.
78
79	## Stop Conditions
80
81	Stop before signing when the signer, sender, chain, target, decoded intent, cost ceiling, or simulation result is
82	unresolved. Stop before retrying when broadcast outcome is ambiguous. Completion requires either a verified read result,
83	an approved signature artifact, or a mined receipt matching the reviewed transaction. Never decorate or truncate
84	addresses, calldata, signatures, hashes, RPC URLs, fee values, commands, or safety wording.

People who liked this also viewed

6 picks

Type