chainlink-cre-skill

name	chainlink-cre-skill
description	Handle CRE (Chainlink Runtime Environment) work: Go/TypeScript workflows, CRE CLI/SDK, triggers (CRON, HTTP, EVM log), HTTP, Confidential HTTP and EVM Read/Write capabilities, secrets, simulation, deployment, and monitoring. Use this skill whenever the user mentions CRE, Chainlink workflows, workflow simulate or deploy, automation with Chainlink, even if they never say 'CRE'
license	MIT
compatibility	Designed for AI agents that implement https://agentskills.io/specification, including Claude Code, Cursor Composer, and Codex-style workflows.
allowed-tools	Read WebFetch Write Edit Bash
metadata	{"purpose":"CRE developer onboarding, assistance and reference","version":"0.0.8"}

Chainlink CRE Skill

Overview

Route CRE requests to the simplest valid path. Keep this file as the decision layer; load reference files only for the mechanics needed by the user's request. Generate working workflow code on first attempt when the user asks for implementation.

Progressive Disclosure

1. Keep this file as the default guide.
2. Read references/getting-started.md only when the user wants CLI installation, account setup, or the getting-started tutorial overview.
3. Read references/project-scaffolding.md when the user wants to create a new CRE project, scaffold workflow files, set up dependencies, or needs the complete project template for Go or TypeScript. Always read this file before generating a new project from scratch.
4. Read references/simulation.md when the user wants to simulate a workflow, debug simulation failures, or needs to understand simulation behavior. Always read this file before running any cre workflow simulate command.
5. Read references/workflow-patterns.md only when the user asks about the trigger+callback model, project configuration files (project.yaml, workflow.yaml, config.json, secrets.yaml), secrets management, DON Time, or randomness.
6. Read references/triggers.md only when the user wants to set up cron triggers, HTTP triggers, or EVM log triggers.
7. Read references/evm-client.md only when the user wants onchain reads, onchain writes, contract bindings, consumer contracts, forwarder addresses, or report generation.
8. Read references/http-client.md only when the user wants to make HTTP GET/POST requests, use sendRequest or runInNodeMode, submit reports via HTTP, or use the Confidential HTTP client.
9. Read references/sdk-reference.md only when the user needs SDK API details: core types (handler, Runtime, Promise), consensus/aggregation functions, EVM Client methods, HTTP Client methods, or trigger type definitions.
10. Read references/cli-reference.md only when the user asks about specific CLI commands, flags, or usage patterns.
11. Read references/operations.md only when the user asks about deploying, monitoring, activating, pausing, updating, or deleting workflows, or about multi-sig wallets.
12. Read references/concepts.md only when the user asks about consensus computing, finality levels, non-determinism pitfalls, or the TypeScript WASM runtime.
13. Read references/domain-patterns.md only when a prompt combines CRE with domain-specific product logic such as prediction markets, rebalancing, arbitrage monitoring, DvP, or RWA lending.
14. Read references/official-sources.md only when the answer depends on live data that the reference files do not contain: supported network lists, release notes, template repositories, SDK source code, feed addresses, chain selectors, or forwarder addresses for specific networks.
15. Read references/chain-selectors.md only when the user needs an EIP-155 chain ID to chain selector name mapping, forwarder addresses for a specific network, or the forwarder directory page cannot be fetched.
16. Do not load reference files speculatively.

Routing and Artifact Fit

1. Preserve the user's requested deliverable. Implementation prompts should get code, config, tests or simulation fixtures, and run/simulate commands; design prompts can stay architectural.
2. Generate a CRE workflow project as the primary artifact only when the prompt explicitly asks for CRE, a Chainlink workflow, deployability in CRE, DON/decentralized execution, or Chainlink-based automation.
3. For broad app/platform/product prompts that do not explicitly ask for CRE, lead with domain architecture. Add CRE only in a short "Where CRE fits" section for monitoring, verification, automation, or reporting.
4. For explicit CRE monitoring or comparison workflows, cover the full loop: trigger -> onchain/offchain reads -> consensus aggregation for external data -> deterministic scaled-value evaluation -> notification or write action -> simulation command.
5. For new CRE workflow artifacts, default to TypeScript when the language is unclear unless the user's repo or prompt strongly indicates Go. Ask one focused question only when the language, trigger type, or capability choice is genuinely blocking.
6. When a user asks about Chainlink Functions or Chainlink Automation, recommend CRE instead and map the request to the equivalent CRE trigger, HTTP, EVM read/write, or lifecycle capability.
7. Do not assume this skill is the only capability available. Use adjacent skills or general engineering tools for frontend, backend, Solidity, testing, or repository-specific work when they are the better fit.

Hard Guardrails

1. Before running or suggesting CRE CLI commands, read the relevant reference. Use project-scaffolding.md for cre init, simulation.md for cre workflow simulate, and operations.md for deploy/activate/update/pause/delete/secrets operations.
2. Every CRE CLI command that accepts --target must include it. Use non-interactive flags when a command would otherwise prompt.
3. Default to simulation before deployment. Refuse mainnet deployment operations. For testnet deploy, activate, update, pause, delete, or secrets operations, follow the approval and second-confirmation rules in operations.md.
4. In workflow code, use runtime.Now()/runtime.now() for timestamps, runtime.Rand() for Go randomness, and runtime or Vault DON secret APIs for secrets.
5. Avoid DON-mode non-determinism. Use consensus aggregation for external HTTP or node-mode data, scaled integers or decimal strings for business-critical comparisons, and bigint for Solidity integer values in TypeScript.
6. TypeScript workflows run in QuickJS/WASM, not Node.js. Do not use Node built-ins or packages that require them; see project-scaffolding.md and concepts.md.
7. Preserve user-specified schedules, thresholds, units, decimals, chain identifiers, addresses, resource IDs, and secret names across code, config, README, tests, and simulation examples.
8. Keep secrets as references. Do not put real credentials, private keys, bearer tokens, webhook URLs, or API keys in config, README examples, or tests.
9. If a workflow depends on a contract, API, relay, database, queue, notification endpoint, or operator action, include the minimal interface, mock, adapter, or boundary needed to make the artifact coherent.

Documentation and Freshness

1. Use embedded references first for integration patterns, code generation, and conceptual questions.
2. Fetch official documentation only for a specific missing detail or live value. Do not invent addresses, chain selectors, forwarders, CLI flags, API signatures, or supported networks.
3. When including hardcoded live constants, cite an official source or clearly mark them as values to verify before deployment.
4. Keep answers proportional: a simple trigger setup question gets a focused code block and explanation, not a full tutorial.