菜单
Debug RPC provider health issues for a chain. Use when alerts mention RPC failures, high latency, stale blocks, or provider errors. Diagnoses the issue and recommends fixes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Update standing fee quotes for the CROSS/moonpay warp route. Use when asked to set, update, or change fees/bps for specific chains, tokens, or directions in the MoonPay route. Also use when asked to show or read current standing quotes.
Encode and decode raw Hyperlane messages to/from packed hex bytes using the CLI. Use when you need to construct a message for testing, inspect a raw message from logs or a transaction, or decode a warp transfer body.
Helper skill for using Hyperlane CLI address conversion utilities (addressToBytes32 and bytes32ToAddress) for cross-chain message formatting
A skill that allows a user to validate that a warp route deployment will be in the expected state after applying some configuration
Simulate pending Safe (multisig) governance txs for a warp route by replaying the literal calldata onto anvil forks, self-relaying any ICA messages, then running warp check against the desired registry config. Use to verify that a not-yet-signed Safe batch produces the intended warp route config before signing.
Add a new chain to an existing warp route owned by a customer. Reads a Linear ticket, adds the new chain to the deploy.yaml, builds a customer-specific strategy file for existing chains, runs warp apply, and outputs transaction files for the customer to sign via their multisig.
| name | debug-rpc-provider |
| description | Debug RPC provider health issues for a chain. Use when alerts mention RPC failures, high latency, stale blocks, or provider errors. Diagnoses the issue and recommends fixes. |
Diagnose RPC provider health issues for a Hyperlane chain and recommend fixes.
/debug-rpc-provider <chain> [environment=mainnet3]
| Parameter | Required | Default | Description |
|---|---|---|---|
chain | Yes | - | Chain name (e.g., ethereum) |
environment | No | mainnet3 | mainnet3 or testnet4 |
MONOREPO_ROOT=$(git rev-parse --show-toplevel)
pnpm --dir "$MONOREPO_ROOT/typescript/infra" exec tsx scripts/secret-rpc-urls/debug-rpc-url-health.ts \
-e <environment> -c <chain>
Examine the output table and classify each RPC URL:
| Condition | Classification |
|---|---|
| Health = ✅, Latency < 500ms | Healthy |
| Health = ✅, Latency >= 500ms | Slow |
| Health = ⚠️ | Stale (block age 30-120s) |
| Health = ❌, has error | Dead |
| Health = ❌, chainId mismatch | Misconfigured |
Output the following structured information:
Summary: One-line description of the issue (e.g., "2 of 3 private RPCs are dead on ethereum")
Current URL status table: For each private RPC URL, show status (healthy/slow/stale/dead) and key metrics
Proposed new URL list: A concrete JSON array of the recommended new private RPC URLs. This should:
Format:
Proposed new RPC URLs for <chain> (<environment>):
["https://full-url-1", "https://full-url-2"]
Suggested action: Either:
/fix-rpc-urls to apply the proposed URL changes" if URLs need updatingIf you recommended URL changes in Step 4, end your response with the confirmation convention so the user gets an approve/reject button:
[CONFIRM: Fix RPC URLs for <chain>]
This MUST be the very last thing in your message. Do NOT run /fix-rpc-urls yourself — wait for user approval.
Note:
[CONFIRM: ...]is a Haggis-specific harness primitive — Haggis renders it as an inline approve/reject button. In other Claude Code contexts it is just text, so this skill is intended to be invoked from Haggis.
If all URLs are healthy and no changes are needed, skip this step.