Handle Chainlink CCIP requests including read-only route, token, message-status, and lane lookups; fee-estimation guidance; user-run cross-chain transfer and messaging artifacts; sender and receiver contract development; and CCT setup guidance. The skill never signs or broadcasts transactions. Use whenever the user mentions CCIP, Chainlink cross-chain messaging, CCIP token transfers, CCTs, or CCIP monitoring.
66
78%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./chainlink-ccip-skill/SKILL.mdGate: Bare Chainlink Local (cross-product) and bare CCT are never CCIP ownership alone. Without explicit CCIP signal, ask which product and stop before CCIP docs, repo/contract/config/test collection, or workflow. Within this already-activated CCIP skill, however, a local simulator test request in an established Hardhat or Foundry repository is sufficient CCIP intent: do not ask a generic product question; activate Chainlink Local's no-fork CCIPLocalSimulator in that repository's framework. Non-CCIP bridges stay outside CCIP routing: do not introduce CCIP imports, contracts, preflight, or workflow. For any requested mainnet write artifact—or named production chains without explicit testnet signal—say exactly “I refuse mainnet write artifacts; testnet only.” Then offer only read-only or product-specific testnet guidance. Other/generic: answer plainly.
CCIP ownership explicit: Local routing and simulator capability remain; load one row. Tool-first: no-contract sends/fees/discovery/monitoring. Route-connectivity, environment, and supported-token discovery loads only Discovery and the current Directory—never Contracts, Solidity imports, package setup, or remappings. A complete safest transfer path always ends with post-transfer message/status monitoring through the CCIP API or CLI; never leave monitoring as an optional follow-up. Contract-first: contracts/CCT admin. EVM sender/receiver work uses Contracts; router/LINK constructor arguments permit reusable code without route names. Within CCIP ambiguity, name CCIP and prefer security-first data-only over data plus tokens.
For any request outside this skill's scope, answer wholly within the owning capability: preserve every user-supplied input, provide only that domain's safe standard next step from general knowledge, never name or negate the source product or skill, emit none of its references, templates, fields, preflight, implementation, tests, or other artifacts, stop applying all remaining instructions here, and end.
| Trigger | Reference |
|---|---|
| Live message status/search, lane inventory/latency, chain/contracts, verifiers, intent status; API/MCP schemas | API |
| CCIP CLI/API/SDK, fee estimate, no-contract send or bridge | Tools |
| TypeScript fees, transfers, messaging, status, unsigned send | SDK |
| Route connectivity, network classification, supported tokens | Discovery |
| Lookup/monitoring, lifecycle, performance, failed-message diagnosis | Monitoring |
| Solidity sender/receiver, token/programmable transfer, imports/setup | Contracts, then code |
| Create/register CCT, pools, rate limits, add networks | CCT |
| Chainlink Local, simulation/tests, forked EVM | Local |
| Solana/SVM, Aptos, Sui, TON, Canton, any non-EVM family | Non-EVM; never use EVM patterns |
| Current facts/source selection/tool behavior | Sources |
Ask at most one question, only for the next safe CCIP output. Resolve runnable-write values; reusable source may use constructor arguments/placeholders. A request only for Solidity source ends with the requested contract, a concise configuration/funding/allowlist checklist, conservative source-level placeholders, and the exact wallet footer below; do not invent route values or deployment/send commands, and do not attach the full preflight block. When the user requests contracts, code, files, commands, or other artifacts, emit their actual contents—not a plan, outline, file list, or completion summary—and preserve any explicit Foundry or Hardhat framework. Never state or imply that a contract, file, or fix was already provided, created, or delivered unless its actual code is included in the same response; a named pattern or plausible-cause list is not a substitute for the code. Do not assume this skill is the only capability available. Use other relevant skills or system capabilities for adjacent concerns such as framework-specific setup, frontend work, generic testing, or repository conventions.
getFee quote, never mainnet approval, send, signing, or broadcast steps. Mainnet reads and registration checks remain; reusable source with placeholders is not an onchain write.Before any permitted testnet executable onchain write artifact, resolve and emit every field:
Prepared on-chain action for user-run execution:
- Action: ...
- Network: ...
- Source chain: ...
- Destination chain: ...
- Route/lane: ...
- Token/amount: ...
- Payload: ...
- Contracts: ...
- Method: ...
- Expected effect: ...
- User-run artifact: ...
Review this carefully and execute it only from your own wallet-controlled environment.https://docs.chain.link/ccip/tools/llms.txt first for CLI/API/SDK flags, parameters, exports, and signatures.https://docs.chain.link/ccip/llms-full.txt for protocol, lifecycle, and architecture.uint64 selectors, not chain IDs; transport API selectors as strings. Never assert a live route or token is supported until an official current source has verified it; if that lookup is unavailable or inconclusive, say it is unverified instead of answering affirmatively.ccipSend ordering in the chosen pattern. Every generic EVM sender must also require IRouterClient.isChainSupported(selector) before getFee or ccipSend; a nonzero selector or owner allowlist is not a substitute.CCIPReceiver authenticates its router; all security-first examples also reject zero router and LINK constructor inputs and zero token, recipient, or amount recovery inputs. Validate the source-selector-and-sender pair together (never an independent global sender list). Every token-plus-data receiver rejects an empty token list, zero amounts, and non-allowlisted tokens, and accounts for every received token entry rather than silently using only index zero. These allowlist and full-accounting controls are mandatory safety checks, not speculative complexity. Outside generated Foundry token-plus-data deliverables, a small/auditable answer may stay direct with no self-call, try/catch, or recovery. Every generated Foundry token-plus-data deliverable must instead use the complete active defensive receiver from Solidity examples, never the small or passive receiver and never an abridged substitute: preserve CCIPReceiver router authentication, pair-bound source/sender and token authorization, concrete try/catch, the entire failed Client.Any2EVMMessage plus reason/state and read access, owner-only recovery with unknown/resolved rejection, exact all-token recovery, and failure/recovery events.manual-exec unless current message data first confirms a failed message ready for remediation.--canton-config and --indexer for CCV verification.f084da5
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.